Yet Another Init decision

I’m trying to use this to capture some of my thoughts on the current GR, and to document my approach to this vote. If nothing else, I hope to use this to convince myself that I’ve read and understood the various options in the GR.

From my perspective, two of the choices on this ballot are easy to deal with, in that they have very clear meaning and the ramifications are easy to understand. We’re either all in on systemd and we don’t care about compatibility with other init systems, or we’re only loosely integrated with systemd and require that it be possible to replace it. It’s pretty easy to rank these two options relative to each other, depending on how you feel about systemd in general. The other options are the hardest to rank. They basically all come down to variants of “further discussion”, or of the status quo, with slight biases in one direction or another. The significance of them is the lens through which we want to view the situation, or how we want to frame the discussion.

There are a few considerations for me when weighing the options against each other. First, I don’t want to have another discussion about init systems in Debian ever again. Second, I really like systemd the init system and am happy to use it just about everywhere. Third, while I like systemd the init system, I don’t care much for systemd the NTP client, systemd the DNS resolver, systemd the DHCP client, etc. Unfortunately, I think this leaves me somewhat conflicted about choosing any of the stronger options. I’m tempted to prefer “Focus on systemd”, but I worry about where that leads in the long run. In particular, the GR option doesn’t discuss this at all, except to say that “[i]ntegrating systemd more deeply into Debian will lead to a more integrated and tested system…“, which may well be true, but I’d like to stop the integration somewhat short of the point where we start considering whether to rename the project Debian GNU/systemd.

So the remaining options to consider are:

• A. Support for multiple init systems is Important
• B. Systemd but we support exploring alternatives
• D: Support non-systemd systems, without blocking progress
• G: Support portability and multiple implementations
• H: Support portability, without blocking progress

(Note that I’ve re-ordered these from what’s on the ballot.)

First of all, I think this is way too many options, and I wish the people championing them could have worked together to consolidate a few of them. I get that there are subtleties, but I strongly believe that a small number of very clearly worded options would make it much easier to appreciate the differences.

Second, none of these options directly address my concern about how much of the system to turn over to the control of the various systemd components. Some of them may imply a limit, simply as a matter of practicality, but they really don’t directly discuss it at all.

Option A looks like a somewhat softer variant of option (E), which states that support for non-systemd inits is required. Option A is tempting because it seems to at least try to put limits on the integration of systemd into Debian, but the limit is at the Policy level, which I don’t think is the right place. Policy is never going to declare that a given implementation of NTP must be used, for example. So that leaves the questions, my mind: Is support for non-systemd pid 1 Important (in the BTS sense)? Would I be willing to accept a campaign of NMUs to add broad support for some other init system? I’m not sure that I would. Fundamentally, I’m not sure how important it is to me, when I get down to it. I haven’t heard a compelling use case that isn’t fundamentally rooted in somebody’s personal dislike or distrust of systemd. So, I don’t see how it can be truly important. (And please don’t bring up embedded systems; systemd works just fine on a Raspberry Pi Zero, and if you need to go much smaller then you really need to be asking yourself whether you truly need things like glibc and apt in your installation. At that point, I’m skeptical that Debian is what you want at all.)

Option G (Support portability and multiple implementations) appears to be a very long-winded way of saying “Further Discussion.” The status quo is preserved, and we essentially resolve to avoid committing hard either way. We assume that we are agile, creative, and focused enough to deal with whatever scenarios arise, and that we don’t need a final resolution to the systemd question. Or to any other technical question, for that matter; Option G doesn’t actually mention init systems and there’s nothing in its language that specific to init systems. I think voting for option G is essentially saying “I wish we never had this GR.”

Option B (Systemd but we support exploring alternatives) similarly seems to entrench the status quo. It essentially seems to be saying that we probably don’t need a GR to resolve current init system questions, and certainly don’t need one right now. It is the most open ended of the options I’ve looked at so far. It specifically mentions derivative distributions as something we should support, and suggests that avoiding tight coupling with systemd leaves them with the ability to make different init system choices. That seems like a reasonable claim.

So this leaves D and H, which look similar on the surface with both expressing goals of not “blocking progress.” Going deeper, they do share quite a bit of text. Option H notably states several guiding principles around the area broadly encompassed by the term “portability”. In particular, it talks about portability to different software stacks, which I take to mean things like non-Linux kernels or non GNU libc implementations, although it doesn’t give such specific examples. It talks a bit about hardware portability, though I doubt systemd has any fundamental hardware portability issues, so I don’t see this as much of an issue. I’m undecided about how I feel about software portability. The kFreeBSD port, to choose an example, was interesting, in an academic sense, but I’m not really sure how much it matters. I have no doubt that real bugs were found and fixed during that effort, but I do doubt that Debian is fundamentally better because it happened. It clearly hasn’t had enough of an impact to foster a self-sustaining sub-project. Even if supporting software portability is very important, though, I don’t think we need this option to enable it. Option B (Systemd but we support exploring alternatives), for example, feels entirely compatible with software portability, especially when support of derivative distributions is considered. (I think the kFreeBSD port could have happened, or at least started, just as easily in a derivative as in the main project.)

Aside from the stated principles, options D and H are identical. So the end result of those two is essentially identical, with just the basis for the decision being different.

I began this document thinking that it would help me decide, with confidence, how to vote. I think it has helped me weed out a few options, for various reasons, but I don’t think it has helped me to understand exactly which option I truly hope to see win. On one hand, I’d be perfectly happy to go all in on systemd and build a tightly integrated, consistent, and unified distribution. No compatibility layers, no abstractions, just direct tight coupling. It’s so much easier to test, and the behavior is going to be more predictable. On the other hand, I like the idea of people being able to experiment, and I dislike the idea of monocultures. There’s already enough of a Linux monoculture on the modern internet, and I’m not sure how comfortable I am with the idea of making Linux distros more and more homogeneous. But then again, the fractured Linux ecosystem has hindered adoption, especially in the desktop area, so maybe we need more homogeneity. Maybe Debian is too big and slow to really be the best sandbox for experimentation anyway, and such work is best handled in derivatives or other distributions altogether, especially early on. (Consider how long it took to complete the /usr/doc -> /usr/share/doc transition. Is Debian really the best place for experimentation?)

Init integration and tooling has been a topic of discussion within Debian for over 20 years. It had already been going on for some time when bug 76868 was opened in 2000, or when hmh gave a talk based on his paper on init systems in Debian at DebConf 2. Regardless of the outcome of this GR, it’s hard to imagine it really ending here. And maybe that’s OK. The init system provides glue that integrates a lot of different components into a unified OS, and as such is important. It’s not the only integral component, though, so in some ways it’s funny to me that it’s the one that keeps coming up.

Tags: