Bug#727708: init system thoughts
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:
> > Colin Watson <cjwatson@debian.org> writes:
> > > Basically, systemd would be more compelling to me if it tried to do
> > > less. I don't expect to persuade systemd advocates of this, as I think
> > > it amounts to different basic views of the world, but the basic approach
> > > here is probably the single biggest factor influencing my position.
> >
> > 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. Using systemd as init in no
way requires using them. Thus their existence cannot cause any technical
problems for the use of systemd in Debian (beyond possibly needing to do
the trivial disabling).
If some other components that Debian does want to use start to depend on
those services, such that disabling them is not easy, then this problem
would exist regardless of the chosen init, and is again not a reason for
favor upstart.
> 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.
There is no technical reason to prefer upstart here. Given your
preferences, systemd can do at least as well (after disabling the
service). Given B's preferences, systemd can do better (after enabling
the service). The only benefit that choosing upstart would give you here
is that it'd let you automatically win your argument with B: "we already
chose upstart, so enabling the systemd service is not an available
choice any more".
Reply to: