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"
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" :)