
Debian committee members vote for systemd as init system - waffle_ss
https://lists.debian.org/debian-ctte/2014/02/msg00294.html
======
jordigh
For a fun retelling of the events (I think this only works on Firefox):

[http://aceattorney.sparklin.org/jeu.php?id_proces=57684](http://aceattorney.sparklin.org/jeu.php?id_proces=57684)

~~~
lmm
It works perfectly in chrome. I don't know what's with the obnoxious yellow
banner - I thought firefox people were against the "best viewed in internet
explorer" attitude.

~~~
forgottenpass
I didn't know there was a block of "firefox people", or that everyone
developing for firefox was a member and shared the opinions they have.

Where's their mailing list/forum?

------
Spittie
Those are the votes for systemd:

[https://lists.debian.org/debian-
ctte/2014/02/msg00294.html](https://lists.debian.org/debian-
ctte/2014/02/msg00294.html)

[https://lists.debian.org/debian-
ctte/2014/02/msg00283.html](https://lists.debian.org/debian-
ctte/2014/02/msg00283.html)

[https://lists.debian.org/debian-
ctte/2014/02/msg00297.html](https://lists.debian.org/debian-
ctte/2014/02/msg00297.html)

[https://lists.debian.org/debian-
ctte/2014/02/msg00282.html](https://lists.debian.org/debian-
ctte/2014/02/msg00282.html)

For anyone wondering, 4 votes are enough because Bdale's vote (the chairman of
the Technical Committee) count as two votes in case of a draw.

EDIT: see this
([https://news.ycombinator.com/item?id=7203479](https://news.ycombinator.com/item?id=7203479))
comment below - if the other 4 members of the TC vote F, then systemd would
not win.

~~~
mjn
Fwiw, the only other vote that's been cast so far, which is in the other
direction (3 people haven't yet voted): [https://lists.debian.org/debian-
ctte/2014/02/msg00288.html](https://lists.debian.org/debian-
ctte/2014/02/msg00288.html)

~~~
kbar13
To be fair he is also the Ubuntu developer and upstart maintainer on the
committee

~~~
dfc
What is there to be or to not "be fair" about? mjn's comment was a value
neutral statement of fact. There was nothing prejudicial in his comment.

~~~
asdfaoeu
He's referring to Steve Langasek not min.

~~~
dfc
What was "unfair"?

------
kashchei
I have to remind everyone that the author of systemd is Lennart Poettering,
the guy behind Pulseaudio. I think, this is one "feature" that should outweigh
all supposed benefits of this program.

For those unfamiliar with Pulseaudio development, it's a third-generation
audio subsystem (after OSS and ALSA with JACK forming two previous ones, and
ESD being the beginning of the third) that is famous for overcomplicated, non-
human-writable barely human-readable configuration procedure, development
marred with huge number of bugs that ruined audio on Linux until recently, and
suffering from immense number of internal interfaces and system being
presented as a huge monolithic piece of software that can not be used in a
modular manner except as modules that only talk among themselves.

systemd seems to suffer from the same problems, plus it tries to "integrate"
init, udev and syslog into a single "product", with arcane internal interfaces
and formats -- just as non-human-writable as Pulseaudio.

~~~
oblio
I find hard to read such comments and think that they are valuable
contributions anymore.

First of all, Pulseaudio was not the biggest success, true, but can't someone
learn from their mistakes? Both are also living, moving software products that
continue to improve, as you said, "development marred with huge number of bugs
that ruined audio on Linux until recently" \- key words: "until recently".

Secondly, about the technical aspects:

[http://0pointer.de/blog/projects/the-biggest-
myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html)

[http://www.freedesktop.org/wiki/Software/systemd/](http://www.freedesktop.org/wiki/Software/systemd/)
-> "The systemd for Administrators Blog Series"

Lennard Poettering said it better than I ever will.

~~~
kashchei
Also: just saying that something is a myth does not make it any less true. The
whole point is that systemd (and Pulseaudio) is anti-Unix because its author
does not understand Unix design, how would his opinion be of any value in this
matter?

~~~
oblio
I find his arguments quite compelling and honestly, at this stage saying "the
author does not understand Unix" just sounds silly.

Judging by his work and his writings, Lennart probably sleeps with a copy of
"The Unix Programming Environment" or other such classic under his pillow. He
probably knows Unix 10x better than you or me (feel free to point me to your
resume/bio if my assumption is wrong :) ).

Just say that you don't agree with his design.

That's fine and it's acceptable. It also turns this debate into something kind
of like Linux versus Minix. Working code (his) wins for now ;)

------
jtchang
Can anyone give a quick rundown of the different init systems?

For the most part it can get confusing for a non day to day system
administrator when I am trying to get a program to "run on boot". Between
rc.local, init.d, run levels, etc. sometimes it is just frustrating.

~~~
mjn
I know less about the new Linux ones, but a brief summary of the two big
"traditional" ones:

Linux systems traditionally use "SysV Init", the init system from AT&T UNIX
System V (1983). It's the one that has: 1) run levels; and 2) a pile of shell
scripts in /etc/init.d that run on run-level changes. Run levels probably make
most sense if you think of Ye Olde Mainframe booting: first it initializes
core services, then it enters multi-user mode, then it initializes network
services, then (optionally) it enters full application mode. These are
supposed to be discrete, semantically meaningful boot levels that you could
purposely initiate: boot to runlevel 1, boot to runlevel 2, drop back to
runlevel 1. Dependencies are handled by a mixture of those runlevels, and
scripts that are run in alphabetical order _within_ run levels. That ordering
(unlike runlevels) is not supposed to be meaningful to the sysop, but just
necessity-based: some stuff depends on other services already being started,
even if conceptually you want them all "at once". The convention is to prefix
startup-script filenames with numbers that effectively serve as priorities
within a runlevel.

BSD systems traditionally use their own "BSD init". There are no runlevels,
though there is still a separate "single-user mode" for maintenance. In
classic BSD startup was just one very large shell script in /etc/rc. In later
versions it was augmented by an /etc/rc.local script that allowed local
modifications to be made without mucking with the main script. Modern BSDs
(starting with NetBSD, later adopted by the others) modularized it, with an
/etc/rc.d directory (base system) and /usr/local/etc/rc.d/ directory (ports).
This differs from SysV init in that it still has no run levels, and rather
than explicit ordering via filename sorting, has dependency-resolution
ordering via semantic comments at the top of each script that are parsed and
resolved by rcorder(8)
([http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8](http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8)).
Afaik this system, originating in NetBSD, was the first dependency-based
startup system on a free Unix (I believe commercial Unixes like Solaris also
moved to dependency-based init in the 2000s).

Many Linux vendors have decided that SysV Init is not such a nice system
nowadays, because it involves maintaining fairly complex scripts with edge
cases that have to be handled in every script through error-prone boilerplate,
and an explicit global startup ordering: all programs that can be installed on
Debian and need startup must be assigned an integer that fully specifies their
position in the startup sequence relative to all other programs that might
also be installed. Runlevels as a mechanism also seem pretty unhelpful for
most uses people have nowadays. Instead there is a hope for some kind of
dependency-based startup. But the big disagreement is over what to replace it
with. It is also complicated by other changes that are happening in parallel
and which are caught up in it. For example, Linux's 'cgroups' resource-control
mechanism has long been in the kernel, but not widely used by userspace tools,
and there are moves to sort out this situation by essentially letting the init
system also own resource assignments, which would more tightly couple those
components. This is probably where the big philosophical differences come in.

~~~
weland
Whoa! You aren't bashing any of them and the explanation is 100% correct! WHAT
HAS THE INTERNETS COME TO?

Congratulations on a very well-written summary!

~~~
sp332
Not so loud, they'll hear you!

------
kudu
I'm very doubtful as to whether it was within the Technical Committee's role
to rule on this. After all, there is nearly a consensus on the fact that
systemd is the superior init system. The question of whether certain kernels
should have more features by default at the expense of portability is a matter
of policy, and not a technical decision.

------
qwoeiu
OpenRC is the only sysvinit alternative that even tries to comply with unix
way and yet (judging from Ace Attorney retelling at least) sadly it is totally
ignored by Debian devs.

~~~
agumonkey
it was mentioned a few times, missing documentation was probably a deal
breaker

------
dfc
Can an HN mod change the title? The committee has not voted in favor of
systemd (yet).

------
_wmd
I wonder how long upstart will survive in Ubuntu after the next Debian stable

~~~
nixgeek
Probably a while, Ubuntu isn't too prone to changing things just because
Debian (upstream) decided to do something.

~~~
shimon_e
Do you think ubuntu will be hiring package maintainers to rewrite all the init
scripts so it can continue importing debian packages into universe?

~~~
viraptor
But they already do. I'm not sure where the big change is.

------
forgottenpass
What happened to the last vote? I saw some criticism that Ian jumped the gun
by calling for votes when he did and putting two issues on at once but haven't
read the archive in the meantime.

Pretty unfortunate it took this long. Even as a casual observer it's looked
like they'd eventually pick systemd a month ago. Hopefully this vote is the
last one.

~~~
JoshTriplett
> What happened to the last vote?

Steve Langasek objected to the wording of the "tight coupling" and "loose
coupling" options, and several others on the committee decided to vote Further
Discussion first in response to that. It turns out that Steve (upstart
maintainer) and Russ (primary systemd advocate on the committee) both agree
fairly closely on that issue, in that the committee really shouldn't be ruling
on that question in that way.

~~~
rodgerd
It seems like that's the fundamental split between Ian and Everyone Else.
Russ, Bdale, Steve, and Colin all want to make sure that people don't start
creating unreasonable dependency chains ("I want the functionality provided by
logind for my DE, therefore I will require systemd as the init system") when
alternatives are available ("I need the functionality provided by logind so I
require that and let systemd or the Canonical fork of logind provide it").

Ian is speccing it out so that nothing may ever rely on capabilities provided
by a init implementation unless the Debian developers add that functionality
to every possible init system in the archive. That is a very odd position, to
put it mildly (you couldn't e.g. ship a GUI tool to manage upstart. You'd have
to rewrite it to support systemd, as well).

------
jiggy2011
Not a surprise, was there a compelling reason for upstart at all?

~~~
ash
Upstart was created before systemd.

Edit: Upstart was a great sysvinit replacement, at least during those years
before systemd appeared.

~~~
dschulz
That's not compelling.

~~~
vacri
The 'compelling' reason was "sysv has a ton of problems". Upstart was an
earlier attempt to resolves those problems - whether it does those well or not
doesn't mean that there wasn't a compelling reason to create it.

------
hayksaakian
Could somebody explain like I'm five?

~~~
aoxfordca
I second... Wannabe hacker and don't understand

~~~
gpcz
A Linux operating system has a core program called a kernel, which has the job
of creating and maintaining an environment where other programs can run. Other
programs include the login prompt, the shell that lets you execute programs,
etc. However, there is a chicken-and-the-egg problem: once the environment is
running, how do you run the first program? This is solved by having the Linux
kernel run a program called "init" as the first program, which manages
everything else (bringing up services, executing the login prompt, etc). There
are multiple versions of this "init" program with different features and
idiosyncrasies -- the Debian committee voted to use one called systemd rather
than some competitors. Switching versions of init requires system
administrators to relearn how to do many things, so the committee spent a lot
of time weighing a lot of factors before making this decision.

------
auvrw
ran across this link, which might be helpful for people familiar sysvinit but
not systemd

[http://0pointer.de/blog/projects/systemd-for-
admins-3.html](http://0pointer.de/blog/projects/systemd-for-admins-3.html)

tl;dc: systemd replaces the bash scripts you're used to grepping through with
unix .conf files that fit on the screen.

------
herokusaki
Did Debian at any point consider launchd?

~~~
mateuszf
Doesn't work on Linux.

~~~
schwarze_pest
Launchd works on Linux (and xBSD) -- in the sense, that it can be ported
without much effort. Systemd in contrast only works on Linux because it relies
heavily on kernel features like cgroups.

~~~
CameronNemo
The code is shitty and there is no sysvinit script compatibility.

------
e12e
Did anyone see if runit was ever considered? Perhaps it was considered a
better alternative to just stick with sysv vs changing to runit?

------
miga
Since it is vote in a technical discussion, I wouldn't be so sure, until
everybody voices their opinion. After all, insight into merits and flaws of
each system may change.

And that's what technical (sub)committees are for.

PS I would vote for "further discussion" in a very Debian style.

------
dschiptsov
Now they should start to pray so it will never segfault.)

------
undoware
I usually just put everything in inittab. ;D

------
qwoeiu
fucking bureaucrats

------
pekk
So when are they going to vote on whether to switch to RPM?

~~~
raikage
When RedHat decides to switch to DEB

~~~
SEJeff
And why would Reshat want to move to a clearly inferior solution? Next you'll
say they want to replace the super simple kickstart with preseed. Blasphemy I
say!

~~~
FooBarWidget
To be fair, it did take me 15 minutes to write my first RPM. Documentation is
pretty good.

Writing my first Debian package, on the other hand, took me a day.
Documentation is horrible. All tutorials are outdated. All the documents throw
tons of jargon at me and just expect that I understand them. The tooling
consists of 300 different tools with a lot of overlapping functionality,
mostly for historical and backward-compatibility reasons. Debuilder, pbuilder,
dpkg-buildpackage, debhelper, cbbs.... what? Learning all this stuf was a
nightmare, while RPM was pretty straightforward.

Furthermore, Debian packaging tools don't have a preprocessor. It seems they
really expect me to repackage my app separately for every distribution
version. RPM on the other hand has a builtin preprocessor so that I can
customize my specfile on a per-distribution basis with only a single file and
a single tool. I ended up writing my own preprocessor for Debian packages, but
something tells me I shouldn't have to.

On the other hand, RPM does not support "Recommended" and "Suggested"
dependencies which are very useful. Neither does it support OR statements in
dependency specifications. This latter sucks, a lot.

~~~
mercurial
Fully agreed. I don't really like the RPM format, though, it's a glorified
makefile which makes it inconvenient to generate in an automated fashion.
Though, from what I can see, the Debian maintainers have done a good effort at
bringing together the various packaging resources in a single document [1].
And, well, packaging _is_ a complicated topic.

1: [http://www.debian.org/doc/manuals/maint-
guide/](http://www.debian.org/doc/manuals/maint-guide/)

