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"
Now I'm going to have to switch distros again. I guess I had a good run with Debian, but I'm not going to stay with a distro that doesn't care about what the users want. I usually expect that crap from proprietary software projects, so I'm just amazed this is happening.
From having used GNOME since the pre 1.x days and having to switch to XFCE a few years back, to Mozilla supporting H.264 support (but only for operating systems that already licensed the codec) and other very questionable decisions, and now to this - the last few years haven't been great for what was once some of the most popular and well respected free software projects.
Don't even bother with Linux. Consider moving to FreeBSD. They're much further away from the insanity that has caused so many problems in the Linux world.
On the server side of things, you still have Debian/kFreeBSD. You wouldn't have many changes to migrate to that. However, for the desktop/notebook or embedded systems you are SOL unless FreeBSD supports your hardware, either raw FreeBSD or processed as Debian/kFreeBSD or PC-BSD. OpenBSD is another option, for some hardware, but because of the tight support lifecycle, you would be looking at upgrades/reinstalls every year.
There was a submission here a few weeks ago about how kFreeBSD will likely be ended soon, thanks to systemd.
I'm not giving up on using Debian just yet. It still has systemd separated, so you only run it as init if you install systemd-sysv, and can instead install systemd-shim if something else on the system needs to use the other parts of systemd (like systemd-logind). That means it's possible to pin systemd-sysv to -1 priority and not have to worry about abrupt init and logging system changes, which is what I did.
I created a file (name doesn't matter, but I used nosystemd) in /etc/apt/preferences.d/ with the following contents:
Package: systemd-sysvPin: release o=DebianPin-Priority: -1
With that in place, systemd-sysv can't be installed, so the worst that will happen is an update will try to install systemd-shim instead and you'll get the parts of systemd that the desktop bits (upower, policykit, etc) want without changing your init or logging. With that done it's just another annoying dbus/hal/etc layer of bullshit and is mostly harmless.
(Another note for anyone upgrading from wheezy: you'll want to install sysvinit-core before doing the full update because of the old sysvinit package becoming a transitional one)
I don't really like the situation, but it's still better than most distros and I'm not ready to jump ship to BSD yet. Ubuntu purged sysvinit a while back in favour of upstart and others are doing the same thing for systemd now. Debian still gives you some choice in the matter in a way that's reasonably flexible, so I'm taking a "wait and see" approach for now.
What I decided to do was revert from testing to stable...i.e. Wheezy. What I'll do when support for Wheezy ends I haven't yet decided...and don't plan to decide for awhile.
That could be a good choice for some, though it wouldn't be great for me because I follow testing and use it like a rolling-release distro so that it's easier to cherry pick software from experimental, unstable, and Ubuntu PPAs. Stable gets too far behind Ubuntu so it's harder to keep the PPAs working.
Except for a bit of a shock when Debian first tried to dump systemd on me, and a brief burp when there was a bad dependency (it got fixed; that's what testing is like sometimes), it hasn't really been a problem. There are only a couple things that attempt to install systemd*, and they're desktop-specific bits, so for servers it's a non-issue right now. For desktops the parts that you lose don't prevent you from running a desktop, just some convenience bits. (Unless you use GNOME, at least, but if you use GNOME you've probably already accepted the systemd overlords)
I kept systemd completely off my system for a while, but then decided to give the non-init parts a fair shot. Installed the shim, blocked systemd-sysv, and let the the desktop-friendly bits do their thing. Figured it'd be easy enough to remove if it becomes problematic, and since my gripes with systemd (from a technical perspecive) are mostly with the init and logging, I had no issue with giving the other parts a chance.
So far, barring some really minor annoyances, the logind+shim haven't been a problem. It makes crap like upower and udisks happy, neuters most of systemd, and basically turns systemd into another dbus-esque abstraction that I ignore unless something goes wrong. Meanwhile, my old-fashioned init and syslog processes just keep doing what they've been doing for years.
As long as the systemd-shim package is maintained we're probably okay, and it seems there are still people in Debian that care enough about it, so there's some hope.
* By "systemd" I mean the actual systemd processes, not the libs that other apps have as dependencies so they can use systemd if it exists. That crap is harmless, and even my wheezy-using laptop has had them installed forever. Without systemd installed they're just a few megabytes of wasted disk space that do nothing.
OK. But I have one system, so it's both a desktop and a server. Until I'm assured that systemd won't cause problems, I'm just going to avoid it, and everything linked to it. Since my system *is* a desktop as well as a server, well...
The question, really, is "Is systemd actually a desirable way to go?". I haven't encountered anything that makes me say yes, so I don't want to commit to it. Particularly as it seems to be an increasingly intrusive and entangling system. I don't mind building things from source, though. (Well, most things.) If I must, I can cut my main system off from the internet and communicate intermittently through a laptop, but that would be much less desirable than finding some better way. But stable is good enough, so there's no hurry. And maybe I'll even be convinced that its a good idea.
Yeah, I totally get that. I use a VPS for stuff I need up reliably, and for home stuff it doesn't matter much if I mix desktop+server bits because if the desktop is down I've got bigger concerns than worrying about mpd or my LAN-only httpd not running. I can afford to experiment a bit. Though I still refuse to let systemd become init, and I'm going to continue to refuse to do that for as long as possible.
I don't necessarily think systemd's a great way to go, but neither was HAL, which is why it ended up superseded eventually. Meanwhile I'm just going to hold out as long as possible using sysv init, and if I start having issues with the non-init side of systemd (right now the only part that seems to run is logind, so the annoyance is minimal) I'll just throw it out and deal with clunkier USB storage mounting.
Either way -- sticking with stable or using shim -- the idea's same. The situation isn't exactly dire yet, so it's a bit premature to be freaking out and switching to BSD. By the time it gets to that point, the entire landscape could change again. That's what happened not long after I finally got forced into using HAL. "Damn I'm stuck with it now. Oh look it's deprecated, yay" :)
I might sound sane and normal about it right now, but if systemd-shim vanishes for some reason, I can guarantee that I'll be frothing at the mouth along with rest over it. Nearly all of my systemd complaints are about the init, logging, and the shitty, politically-charged adoption. Using the shim lets me avoid two of the three, and the third doesn't affect me in day-to-day use. I've already said a fair bit about Poettering, Sievers, and the pushy, rushed adoption of systemd already in other threads, so there isn't much point revisiting the complaints, but it's still a sore point with me. Still, that's not reason enough by itself to flee to BSD when Ubuntu and Debian have worked around some of the brain damage with the shim package.
One potential fear with systemd, and one I do agree with, is that Poettering, Sievers, and co. are using their influence in so many pieces of Linux software to unfairly tie everything together in a way that will make systemd unavoidable. It's a sleazy tactic and it's pretty obvious it's really happening. Pulseaudio depends on systemd now. udev is folded into systemd. NetworkManager requires systemd now. udisks and upower (which I believe Poettering has been involved in) need systemd. Probably some more but I can't think of what else.
Another is that distros will stop providing non-systemd start/stop scripts after systemd becomes the default, effectively making non-systemd impossible. I think this is a legitimate concern, but not necessarily a serious one, because someone that's serious about using an alternate init will be willing (and hardcore enough) to make their own init scripts or whatever. Someone might even rig up a systemd-to-sysv script generator of some kind to serve as a starting point.
All said, I do think the systemd problem is a fairly big deal, but I don't think it's going to destroy Debian or Linux. Like you said, there are enough sane users and devs around that eventually, even if systemd ends up ubiquitous, it'll get tempered into something less insane. The real problem is the sleazy and suspicious way the whole thing has happened, and I have a feeling that's where a lot of the vitriol and emotion comes from. There's a huge backlash here because people feel cornered, forced into something abruptly. Hell, Debian's normal decision-making could reasonably be compared to an Entmoot, but not with systemd. Just for a comparison, I think systemd may have made its way from newcomer to default faster than Debian switched from KDE 3.5 to KDE 4.x
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.
It's NOT GNU/Linux any more - now it's GNU/systemd/LinuxGet it right!