Bug#727708: Init systems: arguments for the CTTE

[Josselin Mouette <joss@debian.org>]

Hi,

since this is the time to submit arguments before the CTTE can discuss
things internally and hopefully reach a decision, I’d like to say a few
words.

It won’t be a surprise if I say systemd should be the default init
systems for the Linux architectures for jessie and, unless another
solution arises, the only supported option for jessie+1.

I say this as a systems engineer, because systemd is great software. I’m
not going to list all systemd features, but there are many of them I
want to see on my production servers. In addition, the command-line
interface is awesome, and the unit file description is straightforward.

I say this as a package maintainer, too. Systemd is becoming a de facto
standard in Linux distributions (at least Fedora, SuSE and Arch), and is
getting excellent upstream support in many packages. So far, only Gentoo
uses OpenRC (and it doesn’t have most of the features I’d like to have),
and only Ubuntu uses Upstart. Therefore using OpenRC would mean
maintaining many patches on our own, and using Upstart would mean that
our upstream would become Ubuntu.

        As a side note, I think upstart’s CLA dismisses it as software
        of choice for our core system. 
        I know it’s not the only important piece of software in Debian
        with a CLA. I still stand on this point. I have experienced a
        real world CUPS nightmare because of Apple’s CLA, and I would be
        all for ditching CUPS as default too if we had a decent
        alternative.

Finally, I say this as one of the GNOME packages’ maintainers. GNOME in
jessie will need systemd as the init system to work with all its
features, just like it needs the network configuration to be handled by
NetworkManager. While it is (and can remain) possible, just like in the
NM case, to install it without systemd and lose functionality, I think
it is unreasonable to ask for a default GNOME installation without it.

Some people have argued this functionality can be reimplemented on top
of Upstart or OpenRC. These people should be ready to show the code and
to commit on maintaining it in the long term before it can be considered
as a possible alternative.

Finally, a word about kFreeBSD. I know systemd and upstart have not been
ported to kFreeBSD (and despite claims that upstart developers would
accept patches, so far they don’t exist). However, we are talking about
a major feature leap for Linux, and having kFreeBSD interfere in the
decision would be unfair to Linux users. 

My gut feeling is that, despite the original enthusiasm I shared,
kFreeBSD was branded a release architecture too soon, or at least for a
too broad set of packages. Most packages have never been tested on
non-linux, and a large portion of those does not work. A possible
approach would be to restrict these architectures to a defined set of
packages and maintain OpenRC or insserv scripts for these packages. In
all cases, this should be worked on after reaching a decision for the
Linux init system.

Thanks for reading,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-