Re: Tentative summary of the amendments
On 24 October 2014 23:16, <josh@joshtriplett.org> wrote:
> I'd personally be interested in your non-devil's-advocate reasons for caring, because
> those seem likely to be solvable.
I, personally, love the init part of systemd - the part that starts
services (either on startup or on events).
>> and there is no
>> need to hardlock them into the init system too.
>
> I really wish you'd stop asserting this. You, and others, would
> *prefer* that they're not part of the init system. That opinion (and it
> is an opinion) on design and architecture is not universal, and there
> are quite a few documented and frequently reiterated reasons to
> integrate such features into an init system.
Let me rephrase that - my opinion is that it would have been almost as
easy to design and implement the IPC parts of systemd in such a way
that they could be used independently from the init system part. In a
way where users could mix and match the parts that they want to use in
a particular system. I know of ability to compile out some parts, as
far as I understand that still does not allow to, for example, run
logind from a bash shell. And, from what I hear, it is highly unlikely
that patches to that effect would be accepted upstream.
> On the contrary, you gain a great deal of flexibility, without having to
> write any extra support for it. Want to run another instance on another
> port? Add another .socket unit. And note that you can do so in a
> systemd --user instance if you want, or ephemerally via systemd-run or
> systemd-activate. Easy to start a debug version that way too.
We need to do a lot of work on updating Debian Policy and Debian
Reference. I am learning new features of systemd with every week of
these discussions. I still don't like the tightly integrated design,
but that in itself is just an irrelelvant opinion.
>> Applications have never
>> been calling init system before. Try the same assumption with: bash,
>> Metacity, gnome-shell. "When you application is started, it might be
>> started by gnome-shell, in that case you may give gnome-shell an
>> indication about your startup animation, but you may be started by
>> something else, in that case you should still start, but it is fine
>> not to provide the correct startup animation."
>
> Talking about "startup animation" dismisses features and integration as
> trivial frivolities. Since you mentioned gnome-shell and metacity,
> let's talk about an analogous situation to the systemd case. Formerly,
> in GNOME 2, you could run a "panel applet" on top of gnome-panel, and
> run gnome-panel within any desktop environment and window manager you
> liked. Neither gnome-panel nor those applets exist in GNOME 3
Even though those were clearly understood to be plugins of the panel
and not actual applications, there was quite passionate discussion
about both porting them to Gnome 3 and about making a freedesktop.org
common ground specification. Basically system notification area came
out of that as far as I rememeber.
> I think your analogy paints an unrealistically nostalgic and idyllic
> picture of life before systemd, as though there were a pile of equally
> capable init systems sitting around and a pile of software that all
> happily ran on all of them, until systemd came along and made everyone's
> life miserable by being entirely too useful.
Sounds about right.
> You're also implying that, out of a clear blue sky, the TC would declare
> a new default, as though they weren't asked specifically to decide an
> already contentious issue caused by a huge number of people *wanting* to
> support a new init system and being FUDded away from doing so.
Actually I am suggesting that TC would make a trivial decision on what
is to be the *default* architecture, while other people would choose
to understand that this decision means that all other architectures no
longer matter.
> Finally, you're suggesting that code already exists that would be
> "cleaned up" and removed, and assuming that's the only reason to limit
> architecture (or init system) support. The common case here, however,
> would be *new* code to implement some new feature, depending on some new
> support provided by (for instance) a new service.
That is exactly what I am suggesting - the reason for the clean up
would be to reduce maintenance burden and add new features by using
features easily available on the default architecture (both perfectly
fine reasons), but the side effect is loss of support for other
architectures (which is no longer considered to be important by the
upstream or maintainers).
--
Best regards,
Aigars Mahinovs mailto:aigarius@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#
Reply to: