Bug#727708: init system thoughts
On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
> On Wed, 2014-01-01 at 17:17 +0000, Colin Watson wrote:
> > On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> > > On the other hand even when using upstart as an init replacement, we'll
> > > continue to use large chunks of systemd (logind, other dbus
> > > services). I personally think "less is more" would only be a convincing
> > > argument if we actually would not need the aditional features.
>
> I think this counterargument, while valid, misses the major flaw in the
> "would be more compelling if it tried to do less" claim:
>
> You can simply not install any of these additional services if you don't
> want them. This is completely trivial to do.
It is indeed technically trivial, but I invite you to review your own
responses to the binfmt-support thread to see why it isn't socially
trivial.
To put it another way, it will help to be careful with pronouns. The
"you" in your sentence necessarily doesn't refer to me (as the person
objecting to the presence of certain features in this case), but to the
Debian systemd maintainers.
It's also not, in general, "trivial" to do something if it involves a
massive argument, even if the patch would end up being a one-liner.
Social costs are costs too.
> > I'm referring to features that I don't think we'll need, not to logind
> > et al. So far I feel that the debates about those seem to be a bit
> > circular and go something like this:
> >
> > A: This feature of systemd conflicts with something else; I'd rather
> > we didn't use it.
> > B: You can disable that, you know.
> > A: OK, let's disable it.
> > B: But you shouldn't disable it because that would make Debian systemd
> > less compatible with systemd on other distributions.
> > A: ...
>
> Here B first correctly points out that the feature can be disabled if
> desired, and thus the situation cannot be worse than with upstart - you
> can do at least as well with systemd as you could with upstart. Then you
> (A) have a disagreement with B about whether disabling the feature is
> the _best_ way to handle the situation: B thinks that gaining
> compatibility with other distributions is a bigger plus, and that
> changing to the systemd way is an actual win over current situation,
> rather than just neutral like the the upstart and disabling with systemd
> cases.
Perhaps this is the fundamental disagreement. I do not necessarily
consider compatibility as an end in itself. Where Debian is already
better than other distributions, we should remain better, not stick to a
lowest common denominator for the sake of compatibility.
I'm specifically referring here to cases where Debian already has a
superior implementation of a given feature. And to answer the strawman
that several people have directed my way, I obviously have no objection
to enabling features in the case where they're the best implementation
available. But it looks as though the default is to rank compatibility
above quality of behaviour; that is certainly the impression I get from
the e-mails I've received.
--
Colin Watson [cjwatson@debian.org]
Reply to: