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 <cjwat...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org