I voted this week. Twice, as it happens (vote early, vote often). This post is about my vote for Debian’s General Resolution: Init systems and systemd. You probably want to skip it, but I thought I’d write it up anyway.

[ 1 ] Choice 5: H: Support portability, without blocking progress
[ 2 ] Choice 4: D: Support non-systemd systems, without blocking progress
[ 3 ] Choice 7: G: Support portability and multiple implementations
[ 4 ] Choice 3: A: Support for multiple init systems is Important
[ 5 ] Choice 2: B: Systemd but we support exploring alternatives
[ 6 ] Choice 1: F: Focus on systemd
[ 7 ] Choice 6: E: Support for multiple init systems is Required
[ 8 ] Choice 8: Further Discussion

Firstly, I’ve re-ordered the ballot in the order I ranked things in. I find the mix of numbers and letters that don’t match up confusing, and I think the ordering on the ballot indicates the bias of whoever did the ordering. I don’t think that’s intended to be anything other than helpful, but I’d have kept the numbers and letters matching in the expected order.

I made use of Ian Jackson’s voting guide (and should disclose that he and I have had conversations about this matter where he kindly took time to explain to me his position and rationale). However I’m more pro-systemd than he is, and also lazier, so hopefully this post is useful in some fashion rather than a simple rehash of anyone else’s logic.

I ranked Further Discussion last. I want this to go away. I feel it’s still sucking too much of the project’s time.

E was easy to rank as second last. While I want to support people who want to run non-systemd setups I don’t want to force us as a project to have to shoehorn that support in where it’s not easily done.

I put F third last. While I welcome the improvements brought by systemd I’m wary of buying into any ecosystem completely, and it has a lot of tentacles which will make any future move much more difficult if we buy in wholesale (and make life unnecessarily difficult for people who want to avoid systemd, and I’ve no desire to do that).

On the flip side I think those who want to avoid systemd should be able to do so within Debian. I don’t buy the argument that you can just fork and drop systemd there, it’s an invasive change that makes it much, much harder to produce a derivative system. So it’s one of those things we should care about as a project. (If you hate systemd so much you don’t want even its libraries on your system I can’t help you.)

I debated over my ordering for H and D. I am in favour of portability principles, and I’m happy to make a statement that if someone is prepared to do the work of sorting out non-systemd support for a package then as a project we should take that. I read that as it’s not my responsibility as a maintainer to do these things (though obviously if I can easily do so I will), but that I shouldn’t get in the way of someone else doing so. As someone who has built things on top of Debian I subscribe to the idea that it should be suitable glue for such things (as well as something I can run directly on my own machines), so I favoured H.

That leaves A and G. I deferred to Ian here; I’d rather systemd wasn’t the de facto result despite best intentions, which results in placing G first of the two.

For balance you might want to read the posts by Bernd Zeimetz, Jonathan Dowland, Gunnar Wolf, Lucas Nussbaum, Philipp Kern, Sam Hartman and Wouter Verhelst.