Re: Debian systemd survey
Lucas Nussbaum wrote:
> I went through the various init systems threads again during the last
> few days. My understanding of the consensus so far is the following:
>
> - Both systemd and upstart bring many useful features, and are a
> clear improvement over sysvinit.
Yes, both are an improvement over sysvinit.
> It is not clear which one of systemd
> or upstart is the best on the technical level. Many of the differences
> have grounds in differences of philosophy, which can easily be seen as
> pros or cons.
I think this is false, both as a description of fact and as a
description of claimed consensus view. Systemd has advanced
significantly further than upstart, and this is more a technical reality
than a matter of opinion like something such as preferred GUI behavior;
this is better compared to whether Linux or MINIX was a more promising
platform for future development in the 1990s. There is a lack of
consensus, rather than a consensus that it's a matter of opinion or
philosophy with no clear technical arguments.
> - It is also hard to say which one is best on the development/support
> community level. Upstart is strongly supported by Canonical, which is
> an organization with which we are quite used to work with. However,
> contributions to Upstart are subject to the Canonical contributor
> agreement. Systemd has already been adopted by most of the other
> major distributions.
A related point which I think is very important is the effect of
Debian's decision on the larger community. Having Linux distributions
permanently split in systemd and upstart camps would have major costs
for the overall Linux community. Systemd is already guaranteed to live,
but Debian could succeed in killing upstart, both by making it costly
for Ubuntu to maintain and by having a working systemd setup that Ubuntu
could easily switch to. Maintaining and extending such a split between
distros should be seen as a big negative, regardless of how upstart
would work internally within Debian.
> - Neither systemd nor upstart are likely to be ported to kfreebsd soon,
> as they both rely on many Linux-specific features and interfaces.
IMO essentially irrelevant distractions such as effects on marginal
systems like kFreeBSD shouldn't be brought up at all.
> As Debian, we have two different problems:
> 1. We need to decide which init systems we want to support, and how.
> 2. We need to decide which init system should be the default.
>
> 1. Deciding which init systems we want to support, and how
> ----------------------------------------------------------
> I'm not talking about shipping them inside Debian (we already do that),
> but about providing the necessary service config files (upstart job
> files / systemd service files) so that users actually benefit from
> switching to systemd or upstart.
The above seems as if it's based on a somewhat inaccurate view of what
the "actual benefits" are. Systemd offers better functionality than
sysvinit (both what users can do on their systems, and APIs offered to
the rest of the system) even if some services don't have native service
files.
> We don't need to select a single init system at this point, and it would
> make sense to try to support all of sysvinit, upstart and systemd, at
> least for some time.
I don't think it's at all obvious that it would make sense to support
more than systemd and the minimum level of sysvinit necessary for update
support. From distro point of view, much of the "actual benefit" of
converting scripts to service files is that service files are much
easier to maintain and less buggy; trying to seriously maintain other
forms for longer than necessary loses this benefit.
Implementing support would of course teach maintainers something about
the different systems, but large scale conversions and serious
fit-for-use maintenance of all three systems sounds like a rather costly
way to compare; it's unlikely to reveal much you couldn't already see
from other distros and smaller tests on Debian. Though perhaps it'd help
motivate a larger amount of people to learn enough to be capable of
informed discussion and decisions (even if the information to be learned
is already available without that effort).
Reply to: