Debian looks at OpenRC

> e.g. I see no reason for them
So what? They won't interfere with your work if you don't need them, the overhead is negligible, so please, just name *one* sensible reason for disabling cgroups. Btw, file permissions are also totally useless on my wireless router, so why doesn't anybody complain because you can't disable those? Because they don't harm anything either.

OTOH, there is a reason for enabling cgroups they're needed to reliably terminate a service, including all its children. Perhaps you don't need that, but many others (like Cyberax) like that ability.

> ...but http://secunia.com/advisories/search/?search=dbus
Yeah. So how many of those redundant are reports because dozens of different distros ship the same fix for the same problem? How many of them affect d-bus-related stuff that isn't required for systemd (dbus-daemon, dbus-qt, dbus-glib etc.)? How many are made irrelevant by the fact that you need root permissions to even connect to systemd's sockets? Can you even name *one* real problem, that was caused by systemd's use of dbus, security or otherwise?

> Do you know the difference between PID 1 and a bunch of other processes, Mr. Downright Downplayer?
rleigh's original argument was that systemd shouldn't make use of cgroups because then it's hard to remove/modify them if they turn out to be a bad idea. In that context, whether the PID is 1 or something else doesn't make any difference whatsoever.

> What about accepting patches?
What for? As I said, other operating systems already have their own init systems and it's unlikely they'll switch to systemd (the BSDs aren't exactly famous for loving the LGPL). OTOH, making systemd portable will likely compromise its maintainability. It's all pain and no gain.

> What is irritating in the crowd touting systemd is that viral "who would need this or that?".
systemd can do everything sysvinit does and more. Nobody stops you from launching a shell script from a systemd unit if that is really what it takes, but systemd units cover the vast majority of cases just fine and they're easier to write and not as ridiculously inefficient as shell scripts.

> we thoroughly dislike an idea of running systemd at servers.
And yet you completely failed to name any sensible reason for that conviction.