[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: init system other points, and conclusion

I have reported on my impressions and experiences of both systemd and
upstart in my previous messagges.

I'd like to run through the remaining points I want to make.  I'll
then summarise and set out my primary conclusion.

Firstly, unlike the systemd maintainers, I think portability to
non-Linux systems is important.  It may be that our existing non-Linux
ports are not very widely used, undermained, and/or not of production
quality.  However, I think it is important for us to keep those
options open.  Of course that provides a space for people to work on
them and use them, directly, but more importantly it keeps Debian's
options open for the future.  And the competition helps keep Linux
honest, which is important because Linux is effectively unforkable,
has a poor history of responsiveness to concerns of some of its
downstream userbases, and has a nearly-unuseable governance setup.

This by itself means that systemd would have to have very strong other
advantages for me to want to choose it.  And I recognise that this
point of view is not necessarily widely shared.  However, happily, I
find that no conflict arises for me between my desire for portability
and the other relevant criteria.

It is important for a component like an init system to be flexible: it
needs to act as glue between disparate software projects, and to
accomodate their quirks.

My experiences with systemd's Debian maintainers (and, indirectly,
systemd's upstream) have been far from satisfactory in this regard.
Instead of taking a flexible approach, and being willing to provide a
range of glue facilities and approaches for different daemon
upstreams, the systemd community seems doctrinaire.  Daemon authors
are expected to do as they are told by systemd upstream, rather than
systemd upstream making things comfortable for daemon developers.

This is IMO the opposite of the proper attitude.

The same appears to be the case for systemd's interactions with Debian
as a downstream.  Pressure has had to be applied on issues such as
separate /usr (and much documentation still contains claims that this
is "broken"); I asked for systemd to be able to execute programs from
PATH rather than requiring unit files to specify the absolute path and
was rebuffed (#...)

This is exacerbated by the fact that systemd's Debian maintainers are
(IMO) much too deferential to upstream.

Finally, the systemd community seems to havve a programme of replacing
many other facilities throughout the system (including ones which
other software already does better - see eg binfmt-support, #716812,
and Colin's comments, which I agree with).  This is to be discouraged

In short, the systemd community feels, to me, arrogant and
controlling.  I am far from the first to say something like this, but
I've now experienced things for myself and I concur with the

upstart's minimalism is very appealing to me.

It does, however, have a number of missing features.  Those I have in
mind are:
  - ability to log daemon output to syslog
  - multiple socket activation (systemd socket activation protocol)
  - socket activation for IPv6 (and datagram sockets)

Of these Russ rightly points out that lack of IPv6 support is rather
poor; it is arguably not suitable for release in jessie without this.

However, crucially, these are all simple matters of programming,
without difficult design decisions.  They IMO don't reveal structural
problems with upstart's approach to things.

Furthermore, in my view the responses of Debian's upstart maintainers
to my bug reports about upstart have been exemplary.  There has been,
for example, no resistance (from them or AFAICT from upstream) to
supporting the systemd socket activation protocol.

I am confident, therefore, that if we choose upstart in jessie, these
lacunae (and any others we will discover) will be fixed.  These
problems are certainly not blockers for selecting upstart as the
default in jessie.

So, to recap this and my previous mails and summarise:
 * upstart is simpler than systemd (which leads to fewer bugs, etc.)
 * upstart integration fits better into a daemon source code
 * upstart is easier to package for than systemd
 * upstart's community is much better to work with
 * systemd's non-portability is (for me) a near-blocker
 * upstart's remaining disadvantages are readily fixable SMOP
 * upstart is therefore ready for adoption in jessie
 * sysvinit has many longstanding bugs and deficiences
 * openrc is not ready (I couldn't evaluate it due to lack of a manual)

I therefore conclude that the default init system for jessie should be


Reply to: