Ian Jackson's general resolution to prevent init system coupling has failed to pass, the majority vote deciding that the resolution is unnecessary. This means that not only will Debian's default init be systemd, but packages will not be required to support other init systems. Presumably, this means that using other init systems on Debian (without using systemd as a base) will not be possible without major workarounds, or possibly at all. It also leaves the future of Debian projects such as kFreeBSD unclear, as systemd is linux specific.
The vote results can be found here
The winners are:
Option 4 "General Resolution is not required"
This approach is not sufficient because behavior remains dangerous. For example, it does not prevent an ancillary service from being too trusting [soylentnews.org].
This approach is not sufficient because behavior remains dangerous. For example, it does not prevent an ancillary service from being too trusting.
I'm not entirely sure about that. Systemd is split up into a bunch of different pieces, and right now because of the shim, the only piece that seems to be necessary for desktop components is systemd-logind. As best I can tell, my system isn't making much (if any) use of the other systemd "modules" or whatever you want to call them. systemd-login and systemd-shim are the only persistent processes, and everything else is either completely unused or only being exec'd briefly just like any other program, so they're subject to the same security concerns as any other process doing the same jobs.
There are still good arguments that can be made about various pieces of systemd not being mature enough yet, but it's far less of an issue when they're just another set of processes that get run, rather than the init and logging being new and untested. As long as systemd-shim remains supported and doing what it's doing, systemd's a lot more tolerable, at least to me, because you get some of those purported systemd benefits (for desktops mostly), without being forced to deal with the contentious parts like binary logs and your desktop forcing you into a specific init.
...Doesn't mean I like it, though. It's just not particularly more offensive than hal or dbus in this neutered form, so I'm taking it cautiously for now and waiting to see where Debian (and Linux in general) goes with it.
I do not want systemd, systemd-shim or a modular re-implementation of systemd. And that was before inexcusable issues such as the DNS cache ignoring recommendations in RFC5452.
I think you are vastly underestimating the scale of problems in systemd and I ask you to consider how many times you are prepared to be burned.
Meh. I don't want systemd, but I also didn't want HAL or dbus, either. Especially HAL, which was extremely fragile and fraught with problems for a very long time. I got stuck with them too, and learned to deal with it. I especially hated udev, because the initial adoption was a mess and broke a lot of things I had carefully set up, but nowadays it's actually a pretty useful thing. As long as it's not the init and not forcing its own DNS and other bullshit, I can deal with it being another lame dbus/HAL piece of shit that will eventually become more mature. (Maybe one day it'll even become a useful piece of shit like udev eventually did, but I wouldn't take those odds.)
Right now thanks to the shim package, it's doing almost nothing on my system, and I can tolerate that. If it annoys me enough despite that, I can safely remove it and only lose some convenience stuff. I can tolerate that option, too. No reason to jump ship to BSD just yet, and definitely no reason to switch away from Debian when the alternatives don't even have the shim, making them less flexible than Debian regarding systemd.
If/when something happens to change the landscape further, I'll worry about switching to something else. Right now it would be premature.