The Debian ctte init discussion, which has been the drama that keeps on giving, appears to have finally had a decisive vote for systemd [EDIT: I was over-ambitious about decisive. The drama continues.] as the jessie init. Some notes:
- I found out that the FLOS neologism that is my fault is being used in the discussion. I’m not sure that I’m entirely happy about that, but I do think that we should be self-aware about building something very different from the Unix tradition.
- Even with my well-documented distaste for some of the philosophy (and rider components) in systemd, my experience and taste is that Upstart is the worst possible choice, and nothing else seems to have a chance. Letting the Canonical folks continue to act like Upstart isn’t universally technologically and philosophically unsatisfying to is wasting everyone’s time.
- The FDO agenda has largely succeeded, a bunch of the upper layers of the ecosystem are developing dependencies on systemd-coupled interfaces. This is largely because the previous interfaces being used for much of that functionality were the same developers’ now-abandoned earlier projects, which turned out to be disasters. This would be fine if there were even signs of competing implementations of those interfaces, or if the design of those interfaces weren’t such that it would be almost meaningless to attempt one, because the parts were designed as part of an integrated stack. I don’t see, for example, a clean standalone logind implementation (since it assumes things that only sysmted does further down the stack) or a nice healthy syslog-ng/rsyslog arrangement for journald. The FDO folks made an end-run around any kind of discussion of the merits of their plans by implementing quickly, getting a few of them widely adopted (initially by sheer political blustering), then coupling the rest of their design to the parts others were on board with. I’m pretty sure they consider that some kind of virtue.
- Related to (3) the integrated service manager over rcconf system discussion seems to have been decided on Linux up and down the ecosystem. I may not like the decision, but we should probably make the best of it and start working on/around the most annoying things about systemd. They seem willing to accommodate at least on cosmetic things like ISO dates.
- With that in mind, my preference would have been “We will adopt systemd iff a series of ecosystem assurances/development projects happen,” but that is unrealistic and (AFIK) forbidden by the Debian process. Especially a move from putting dist configs in half a dozen cryptic paths in
/usr(which offend me in a variety of ways) to, giving credit to the merits of the “/usrbelongs to the package manager” retcon,/usr/etcthe way some of the BSDs use/etc/defaults.
While we’re dreaming, forcing an interface/adapter to use a syslog in place of journald, or at least an alternative journald implementation with a simpler back-end (graceful feature degradation acceptable) would be great. I’m not even necessarily advocating using it, just that I don’t tend to take software without competing implementations as credible. Perhaps pressure from the volume of the Debian community will make some of this happen. - I will agree with their vote in the “Fuck it, go with systemd, get the uniformity and feature advantages, try to mitigate the misfeatures, and leave as much room for coming back to the decision later if someone succeeds in writing and agitating for something more satisfying” sense.
Even with all that said, I’m a little surprised OpenRC wasn’t taken more seriously, since it is the conservative incremental progress choice – objectively, it is currently more featured than Upstart by most metrics – but the developers haven’t been politicking the way the Upstart and systemd folks have, and their incidentally combined efforts managed to discredit it. It has better portability (already runs on Hurd and FreeBSD) than the other options, and is one of two with a (admittedly, less featured) cgroups mechanism. The latter one is interesting because via some impressive politicking the cgroups discussion was at some point re-framed from “makes use of cgroups” to “uses cgroups in exactly the same way as systemd.”
I’m curious how the procd/ubus/hotplug2 stack coming out of OpenWRT is going to interact with the rest of the ecosystem, I suspect we’re going to see that stack meet midway with systed/dbus/udev and some of the light distros using it and shims even for PC-like applications, which will likely be the next time things get really interesting, barring a couple skirmishes where user-level software dictates the stack to the metal.
