A realization that I recently came to while discussing the whole systemd controversy with some friends at the Collab Summit is that a lot of the fear and uncertainty over systemd may not be so much about systemd, but the fear and loathing over radical changes that have been coming down the pike over the past few years, many of which have been not well documented, and worse, had some truly catastrophic design flaws that were extremely hard to fix.   For example, I still have the following magic installed in /etc/polkit-1/localauthority/50-local.d/dont-bug-me.pka:

[Don't Bug Me]
    Identity=unix-group:sudo
    Action=*
    ResultActive=yes

I added this because Network Manager insisted on popping up a window and asking me to type my password whenever I tried joining a new network.   And figuring out how to make Network Manager not do such a brain-damaged thing was so painful, that after going through reams of poorly documented XML schemas, and 50 language translations interspersed with actual configuration in various XML files, I just gave up and used the Big Hammer to make policykit just Completely Go Away.

I could tell similar horror stories about dbus when I had to debug various suspend/resume failures, which is something else which is similarly opaque and impossible to understand, but the point is that many of these failures have caused many people to want simple shell scripts, instead of having to crawl through badly designed XML schemas, or someone else's complex C or C++ code, just to figure out what the hell they did and how to patch around their design fail.

It's not entirely fair to charge all of this to Systemd's account, but I think one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away.

That being said, I recently did try moving my laptop to systemd, and I was pleasantly surprised by the Debian's integration --- it didn't blow away my rsyslog configuration, or do any number of a things that I'm worried about.  +GNOME  may start depending on more and more of systemd's features, and thus make it even harder to configure away its design failings, but that's +GNOME's problem, not systemd.   And besides, this is why I'm using XFCE and not GNOME.   :-)

I do find it very difficult sometimes to figure out why a particular systemd service gets started, and when I tried putting together a battery target which would automatically shut down various daemons that I don't need when I want to save power, it apparently somehow caused the brightness keys (fn-F5 and fn-F6) to mysteriously stop working --- and as I expected, it was impossible to debug.   So instead of using a systemd target, I'll just hack together a shell script that runs the necessary "service <foo> stop" instead of using a systemd target.  If things start breaking horribly, I'll file debian bugs, and try to find ways to work around the brain damage.   The fact that I won't be able to edit shell scripts to work around brain damage is still a little anxiety-producing, and the fact it's much more difficult to create a runlevel which is "just like runlevel 3 but without certain services running" is unfortunate, but I'll give it a try and see how much pain is involved.

At least with Debian, it's relatively easy (at least at this point) to roll back to sysvinit if systemd proves to be intolerable.   I figure I might as well try it now before I'm forced off of sysvinit and then discover all of the things that break and which can't be easily worked around.