Bug#727708: Thoughts on Init System Debate
First off, I'd like to apologize again for taking so long to figure out
and write up my opinion. I still feel a little bit swamped with all of
the information that I've reviewed to come to my opinion, and I
certainly don't yet completely understand the full architecture of
either upstart or systemd even though I've been working with them both
for a while now
From the information which I have reviewed, and seen, either upstart or
systemd are viable choices for Debian, but we must choose between them.
Upstart has much clearer documentation than systemd, but systemd's
documentation is sufficient.[1]
Systemd's declarative style has the advantage of being directly
parsable, but the disadvantage of forcing logic out into daemons...
though that's probably where it should be in the first place.[2]
Upstart's CLA is problematic, and coupled with the fact that the rest of
the non-Debian distributions appear to be standardizing on systemd gives
me pause. I'm not sure if this is actually a major concern, though, as
long as Ubuntu continues using upstart.
Systemd's socket-based activation and cgroup based tracking are
technically superior to upstart, even though the latter causes problems
with portability to non-linux systems. However, if we were to decide on
upstart, we could have just a single init system everywhere, which would
be beneficial.[3]
Writing non-complicated unit or job files for systemd or upstart is
fairly straightforward, and should be easy for the vast majority of
packages. [A strong argument could be made that packages like
spamass-milter which it isn't so straightforward are deficient.]
With all that said, I think all of these considerations give me a slight
preference for systemd over upstart, though I believe that whatever the
committee decides on will be a great improvement over venerable SysV.
I should point out that I have not extensively examined openrc, nor have
I taken into account planned features and development in either systemd
or upstart which could sway my opinion.
Finally, thanks to everyone who has participated in this massive thread,
writing position statements, and putting up with all of the questions
that the CTTE has had.
1: For example, systemd could have much better introductory
documentation for unit file writers than it currently has. It also
describes many of its features in blog posts which are not written into
a cohesive manual which flows. I suspect these will be rectified in the
future, but I found it fairly frustrating to deal with.
It would also be super-nice, since almost all of systemd's configuration
is in /lib/systemd/system for there to be a manpage or similar which had
all of them and pointers to documentation what they did, etc.
2: It's sort of annoying that systemd's declarative syntax has knobs
like CondtionPathExists= etc, but doesn't have methods of then wrapping
segments of the unit file in conditionals. Instead, the solution
appears to be writing multiple unit files with the correct sets of
Condition...= But perhaps I'm missing something. (This matters to be
because of
http://svn.donarmstrong.com/deb_pkgs/spamass-milter/trunk/debian/spamass-milter.init )
3: Frankly, I don't want to support more than one set of init files; if
the other architectures are to be release architectures, they really
should get whatever the CTTE decides is the default init system ported
to them, and the maintainers of that init system in Debian should accept
patches to do so, even if it means that the default init system is less
functional on those architectures than it would otherwise be. [Even
without cgroups, it'll be superior to sysv, after all.]
--
Don Armstrong http://www.donarmstrong.com
Clothes make the man. Naked people have little or no influence on
society.
-- Mark Twain
Reply to: