Something that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely no question that the vast majority of Linux users would rather sysvinit disappear entirely.<p>But that <i>doesn't</i> mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependency management and speed gains of systemd without the monolithic architecture and without the complicated shell scripts of sysvinit, as well as cool features like service management trees for non-root users. (In fact, runit doesn't need to be run as init—you can run it as a non-root user and provide service management even if you use another init. It just happens to make a nice init.)<p>The tests I've seen show that a minimal system with runit boots roughly as fast as than a minimal system with systemd. That doesn't mean runit is the end-all solution to "which init"—it's perfect for my needs, but maybe not yours—but it <i>does</i> mean that the choice is not a choice between systemd-but-fast versus sysvinit-but-slow. The field of choices is much, much broader.<p>[1]: <a href="http://smarden.org/runit/" rel="nofollow">http://smarden.org/runit/</a><p>[2]: <a href="http://cr.yp.to/daemontools.html" rel="nofollow">http://cr.yp.to/daemontools.html</a>
So... none?<p>Unintegrated desktop linux is painful, and the fixes for it so far have mostly been hacks. Systemd actually attempts to create some kind of modern cohesive system which is a <i>good</i> thing.<p>Maybe you don't see the downsides to the lack of integration because you're just used to putting up with them.
As a user of linux on the desktop, I've never felt a moment of concern over the fact that it takes longer to boot than did Windows. I'm not sure who is panicked by this and I'm distressed that we would solve all of our problems with init by embracing systemd.<p>If Gnome requires systemd, lets drop Gnome.
Integration comes with a huge price.<p>I'm a beginner sysadmin, and therefore not really knowledgeable about the recent changes in Linux -- however I've seen FreeBSD in production(ish), and it was indeed a more pleasent experience. Paths, configuration, the package system, the documentation (!) all felt nicer.
He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment:<p>"I have to provide a system that runs reliably and can easily be reasoned about and yet I have to build it on distributions created by people who consider how long it takes to get to the fucking GDM login screen and if shutting the laptop lid will cause the system to hibernate properly or not."
Why weren't any of these objections heard back before Canonical knuckled under? Was upstart even worse? I really enjoyed the "impotent rage" piece linked in TFA's comments.
Whatever happened to the old unix philosophies of KISS, and if it isn't broken, don't fix it.
Granted, as many other have pointed out, SysVinit definitely has its pain points and could use improvements, but there are some other init systems people can use without having systemd shoved down our throats. It's been a while since I've played with *BSD, but it might be the time to start seriously looking at it again. Or switch to slack/debian and keep my old-fashioned init system.
Assuming that everything the author says turns out true - such as the "big one" exploit - in say an year from now, does anybody know any active popular open source distro that aims to keep systemd away from servers?