[pessimizer]

I have none of these objections to systemd. My objection is that it's both pervasive and unauditable. I can accept one or the other.

I don't have to rely on 'many eyes' to tell me what's going on with init scripts, I can just look. systemd is sprawling, has no particular philosophy that I can notice, and all of its internal systems are heavily interconnected; this leads me to expect that very few people will be auditing the code that don't work for redhat, because very few will understand it. I expect it to increase the vulnerability of the entire system to accidental or intentionally inserted bugs by an order of magnitude. Therefore, I'd like to see it in the wild for 5 or so years before personally using it - but it looks as if to continue using many linux applications I have to switch to it while it is being written.

I don't get the point (other than cgroups and boot times), I don't get the hurry, and I don't get the animosity to alternate and legacy init systems, and to alternate Unices.

[bkor]

Red Hat has audited the code in the past. The boot time bit is an item from the linked article. The thing is that systemd provides more than just an init system. Stuff that's pretty useful.

[sprash]

Red Hat is a military contractor based in America. This means they can be forced to introduce vulnerabilities under a gag order.

[pessimizer]

>very few people will be auditing the code that don't work for redhat,

[bkor]

You also said: > My objection is that it's both pervasive and unauditable.

You said it was unauditable, it has already been audited. Adding arbitrary limitations to this doesn't change that.

[e7620]

I didn't downvote you, but I want to audit it myself, thanks.

[bkor]

I also help out at Mageia, the systemd packager (Colin Guthrie) is fairly busy but does find the time to add patches to systemd package (e.g. backporting fixes). Before systemd was integrated, he also fixed a fairly important journald bug. He doesn't work for Red Hat. Every time before systemd package is upgraded, he performs a lot of testing, often pushing things upstream again. It's not without bugs by far. Reason it is stable is continued coordinated effort across distributions. If you check the release notes of some versions there are fairly big changes every so often. It requires a bit of expertise to sort that out. Though a lazy distribution could just wait a little and backport the "stable" marked patches.

[e7620]

The problem is that systemd is taking a lot of work better spent in other parts of the project. Instead of testing systemd, it's better to user simpler components, systemd is evolving, introducing more bugs, and people like that packager have to make a Herculean effort instead of using other init system, even sysv! and improving other applications.