Bug#727708: init system thoughts
Thanks for this write-up, Colin. This was very interesting to me,
particularly in the concrete examples of where you've felt like systemd
has stepped into areas that will pose integration problems for us. This
is something that I've seen referred to in the abstract frequently, but
without a lot of specifics that made sense to me. Both of those examples
make sense to me.
Just a couple of specific comments....
Colin Watson <cjwatson@debian.org> writes:
> (Now, I've been working with Upstart's model for years, and it's now a
> pretty fundamental way of how I think of system operation; so if people
> who are new to *both* models rather than partisans of one side or the
> other consistently tell me that the systemd model is easier to grasp,
> then I'll listen.)
I am new to both models. I'm not very fond of the upstart model.
Lennart had a comment on this point that I thought phrased the problem in
an interesting way: both systemd and upstart deal with the same data, but
with systemd, the full dependency tree is precalculated and exists as
state within the init system. With upstart, behavior is dynamic and to
some degree emergent: you know who is listening to what signals, but you
can arbitrarily introduce signals, and you're dealing with a message bus
rather than a dependency tree, so you're reacting to things as they happen
on the bus. In systemd, you can dump everything that can possibly happen
and work through the state transitions by hand if needed, with the
possible exception of unexpected device events (which are horribly
important in some cases -- don't get me wrong -- but which are
uninteresting in a lot of common debugging scenarios). I think it's
somewhat harder to do that with upstart, where events are generated more
dynamically.
Basically, the way I'd put it is that I think the upstart event model is
the sort of elegant, minimal model that someone who has thought really
hard about the space comes up with, but which is hard to understand for
people who have *not* thought really hard about the space. It's elegant
and clever; for me personally, I find it *too* clever. I understand what
it's trying to do, and it has a certain grace, but I find a dependency
graph more robust and predictable, and even the levels of dependencies
make sense to me given packaging background and familiarity with the
Depends vs. Recommends scenarios. I can build a relatively complete
mental map more easily than I can with the message bus approach.
I should probably note here that I'm a notorious skeptic about message
buses in general. People I work with have probably gotten rather tired of
me going on about my feeling that message bus integrations are overly
complex to reason about, hard to guarantee correctness of, and are
overused in system design. :)
> There is of course also the non-Linux porting issue, which Ian, Russ,
> and Steve have discussed at more length elsewhere, and I won't repeat it
> at length. I will just add in response to Russ that there is a great
> difference between one project whose lead maintainer has explicitly said
> that he will reject patches for porting to non-Linux architectures
> because they fundamentally do not make sense with its architecture, and
> another project one of whose developers has been working on such a port
> with some degree of success so far.
This is a very valid point, and you're right, I probably understated that
in my writeup. One of the things that I may turn out to be wrong about
(and would be happy to be wrong about, for the record) is the likelihood
of completing a working port of upstart to Hurd and kFreeBSD. As I
mentioned but probably not explicitly enough, the existence of those ports
would, for me, turn the whole second part of my analysis into a dead heat
between systemd and upstart as opposed to a general advantage for upstart
in terms of ecosystem integration.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: