Re: Proposal - preserve freedom of choice of init systems
Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Proposal - preserve freedom of choice of init systems"):
> > So if someone packages a new init system that is not compatible with
> > existing init scripts (e.g. if it does not support /etc/init.d/* as a
> > fallback), then it won't be able to start any service.
> This point was dealt with in the TC discussion on this same text.
> Packages are not required to support all init systems; they must not
> require "a specific" init system.
> Since in practice there is only one hegemonic init system, this is
> sufficient to ensure our commitment to diversity.
What does that really "ensure" in practice? The reason why pretty much
everyone is by now either already using systemd or moving to it is not
that upstream software would not work with anything else, but that
systemd offers better functionality than any current alternatives. This
resolution would not help make the alternatives any more plausible.
Upstart was the closest contender, but it was already clearly worse than
systemd, and after the announced Ubuntu move to systemd it probably
won't have much of a future. Whether OpenRC will be worth anything is
still an open question. The most likely practical result of this
resolution would be that people are forced to write some unreliable and
buggy init scripts for degraded functionality under the obsolete
sysvinit in order to fulfill the letter of the "multiple-init" support
requirement at a minimal level. That would only be a waste of resources
and would not help with any positive diversity.
If systemd "hegemony" becomes a problem, there is a much better
open-source answer: fork systemd. Systemd has obviously done a lot of
things better than its competitors, and even if you disagree with some
parts, it's the best available starting point. Insisting that you must
throw *all* currently systemd-specific features out in the name of
diversity would be idiotic - it'd be like insisting that Debian must
have various distro-specific non-FHS paths just for the sake of
If someone forks systemd, then most applications that require systemd
functionality will presumably continue working with the fork, and the
fork will fulfill the "multiple init" requirement. If nobody forks
systemd, then apparently people don't consider systemd hegemony to cause
that many problems - or at least not enough that they'd be willing to do
actual work to address them.
Of course, forking also gives a way to fulfill the requirements of this
proposal: create and package a fork of systemd with some minimal
changes, and now everything works with at least two init systems - the
original systemd and the mostly identical fork. If you want to argue
that the result would not be a credible independent project and could be
ignored, then IMO the long-term credibility of the current alternative
inits could be questioned too.