Bug#727708: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)

[Thorsten Glaser <tg@mirbsd.de>]

Okay,

and here’s the reasoning for “sticking to an antiquated” init system:

I fully believe that Debian should be as flexible as possible
when meeting users’ needs. There is already a big downstream
running on Upstart, and I believe that, given the assumption
that we need to decide on one/the init system, there is indeed
market for another big Debian downstream that runs on systemd
and offers GNOME after it has, by Neil’s suggestion (and, if
we decide to only support one init and it’s not systemd, that
*is* the logical outcome, *and* one I fully support), been
removed from Debian. This will cause “the market” to work and
make for some healthy competition, while accepting the goodies
from both downstreams to flow back into Debian if they’re good
enough (i.e. do not prevent sysvinit from working). This appears
to work pretty well with Ubuntu already, with early hostilities
(on both sides) having been overcome.

I believe that sysvinit allows for the most flexibility for
users and porters, and imposes the least on package maintainers
unwilling to write init scripts for more than one system. Both
newcomers support running packages from initscripts, whereas
it’s their way or the highway for the respective native scripts,
which may be added to Debian to be used by Debian users running
a nōn-default configuration (meaning with upstart of systemd as
init, which would presumably still be doable by users, but not
by packages, leading to the GNOME removal), and, of course, by
the aforementioned downstreams.

There needs to be said that sysvinit is the one closest to Unix
principles by not being as “integrative” (cf. modular), not
insisting on its own, proprietary binary logging format, and
other things. There may be a place for FLOS, but a Universal OS
is not it.

Additionally, sysvinit, at this point in time, is the only system
working universally across Debian thanks to the Hurd GSoC by Justus
Winter, whose Planet posts I read amazedly. I believe we should
solidify its status in Debian, as diversity is a good thing, and
the newcomers are not as portable (even if a GNU/kFreeBSD port of
upstart was begone). Downstreams may want to limit their set of
architectures for arbitrary reasons, so they would not have the
same constraints of being universal.

Finally, sysvinit is “the thing to expect” in the GNU/Linux
world, despite attempts from two big and a very small number
of smaller GNU/Linux vendors. Keep the principle of least
surprise and accept that sysvinit is the most universal one,
the one people coming from other GNU/Linux systems and even
some Unicēs will know, expect, or at least (if they’ve been
at Fedora before) know something about, and one which even
BSD people can accept and understand. It’s widespread, and
a good common denominator.

So I believe that, if we need to choose a default right now,
it must be sysvinit, and this must be a reliable outcome, i.e.
we commit to this and don’t arbitrarily change our mind later.
I believe that, should this question be forced first, GNOME
needs to be removed from Debian and welcomed as a downstream.

That being said, I would support upstart over systemd alone
for the fact that it doesn’t appear to do such “land grabs”,
is open for improvement (such as the kFreeBSD port) and not
as hostile as some of the people behind systemd/GNOME have
shown themselves to be, over and over again; I believe that
the fact of it being mainly driven by a company is not a big
problem (if needs be, fork it), especially as they have shown
themselves capable of doing large-scale projects in a mostly
technically sound manner, and be somewhat more consistent in
the implementation, as opposed to the perceived “a big change
every other week” of the other newcomer systemd.

bye,
//mirabilos
-- 
<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo      │  fault (core dumped)
<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh