Quoting russell@coker.com.au (russell@coker.com.au):
People who have chosen systemd have spent a lot of time making it work better and solving some real problems that other init systems have had for many years. People who want to choose SysVInit have spent a lot of time flaming people who write the code.
I continue to like OpenRC a great deal, as the init system. I'm still looking around for the most conservatively written, narrowly scoped PID1 process. (OpenRC doesn't handle being PID1.) I've written a description of how to (very easily) convert Debian 8 'Jessie' over to OpenRC -- or to runit, sysvinit, or upstart, all of those available packaged in Debian 8 -- and make that architecture decision persist. It turned out to be very easy. Actually I wrote the basic details on this mailing list, in response to a question about that. Later, I fleshed out the topic for my Web site: http://linuxmafia.com/faq/Debian/openrc-conversion.html
We had a "debate" about the relative merits of the various init systems on this list some time ago. It turned out that only one of the people who were criticising systemd had actually used it, and that person wasn't making the more extreme criticisms.
Both on this mailing list and on your blog, you seem obsessed with, in effect, calling some set of unnamed but broadly scoped critics names, e.g., that they're just flamers, misogynistic, homophobic, and driven by hostility and hate. I'm sure you're aware that this variety of rhetoric suffers a rather serious 'if so, so what?' problem (residing somewhere among the subvarieties of non-sequitur appeal). But anyway, I generally find it a great deal more interesting to discuss technology, than to detail at length how awful are the tribe on the other side of the figurative river. In your more _charitable_ moments, you've been known to dismiss being fond of something other than systemd as mere conservatism -- relying on, among other things, the false assumption that anything else is backwards. A point I'll get to in a moment. However, I did want to stop here and praise the 'mere conservatism' rhetoric as at least not the total non-sequitur fallacy that the name-calling is. ;->
It's quite likely that I have contributed more patches for init systems than anyone else on this list. The attitude of SysVInit fans doesn't make me inclined to spend any more effort patching that init system.
You know, I just remembered what this 'systemd must always be compared to SysVInit and nothing else' trope reminds me of: djbware fans would always characteristically compare qmail only with Sendmail, and djbdns only with BIND. This behaviour persisted _long_ after Postfix, Exim, and Courier-MTA emerged as competitors to qmail, and long after NSD/Unbound, PowerDNS, and MaraDNS/Deadwood emerged as competitors to djbdns. A cynic might imagine these worthies to be unwilling to compare against _modern_ alternatives to Prof. Bernstein's eccentric creations. Anyway, thank heavens, Unix open source offers a smorgasbord of worthwhile options in the software categories in question. Here is a partial list: init systems: systemd, Upstart, Epoch, finit, SysVinit, initng, runit, s6, OpenRC, BSD init, nosh. inits (PID1): BusyBox, SysVinit, ninit, sinit, minit, systemd, BSD init, Upstart, finit, runit, Epoch, nosh, uinit. service managers: OpenRC, finit, runit, daemontools / daemontools-encore, systemd, s6-rc, initng, Epoch, nosh, anopa, supervisord. My current idea of a good system composite is a really tiny, minimal PID1 (leaning towards BusyBox[1]) spawning OpenRC as the init system. If I ever actually need service supervision, I'd probably use runit or supervisord on whatever daemons merit such supervision. Because, really, building big feature sets into PID1? I rather think not. It should catch signals and reparent orphan processes (reap zombies), and collect their return status. Processing poweroff and reboot is nice (as part of catching signals). All else including the rest of process handling (the 'init systems' bit), such as process supervision, dependency management, daemon start/stop, libdbus interface, handling /dev changes, monitoring mount points / files / sockets / timers, parsing of various files / messages / strings, and all the rest, need not be in PID1, so I'd rather it _not_ be in such a sensitive and vital place. Yes, having process supervision in PID1 is the only way for total process control to be possible, but I don't have any use-cases where that is actually needed. And socket activation is actually a big dumb bad idea as we know from initd/xinetd, but available with sundry toolkits if you actually want it. Please notice that I don't call either systemd or its acolytes names. I merely say 'I'm glad you like it' to the latter and 'No thanks for now, but I'll bear you in mind' to the former. (And if I'm a misogynist, you'll need to account for my N.O.W. card, http://now.org/ , being older than you are. Do you want to start claiming I'm not a feminist, again? Because that was really funny the last time, so I'd love to do it again.) If I ever actually have a need for the cgroups (control groups) kernel feature, I'll look around for best of breed toolsets. Of course, LXC/OpenVZ do that, but is rather more than just simple management of control groups, and might be excessive. LXC's CGManager is that system's cgroup-wranging tool, and can be used without the rest of LXC if one wishes. And I read that OpenRC includes cgroup management, but I've not pursued that. [1] Or possibly sinit.