> A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process.
These improvements weren't real. There was a long tail of scripts that didn't follow the standard and never would. Every distribution still had their own customizations on how sysvinit scripts worked (e.g. debian with start-stop-daemon, suse with insserv, etc.)
And rc was different on almost every major distro family, which made life even more difficult for no particularly good reason.
And there's a certain point where all these things you are doing are ultimately to paper over the "hacks and untidiness" of everything. The introduction of systemd had two major effects:
1. It broke all non-LSB init scripts (because LSB is all it supported)
2. It introduced a straightforward declarative syntax for system resources (units for services, timers, mounts, etc.)
I would argue that the above two things have done more to standardize the Linux plumbing layer and help people take fuller advantage of it than literally all the linting, guidelines, and policywork we did for the decade prior.
And if that's all it did, we wouldn't be having this discussion. Instead it is becoming some sort of self-appointed "userland middleware", which nobody asked for. People resent "better init" turning into "henceforth home directories will behave differently".
That's a dishonest argument and you know it. The entire home directories thing is aimed at enterprises, and nobody wants to enable it for individuals' machines. Poettering said as much in the talk where he presented it. It would be much more reasonable to respond to people who dislike systemd if they wouldn't constantly make bad-faith dishonest claims about it.
The question remains, what do home directories have to do with init, at all? Okay so Poettering wants to "fix" home directories - is there any reason to couple that with systemd, beyond the fact that systemd is his baby (and point of leverage over the rest of the system)? There are dozens of other examples - network configuration? syslog? cron? This is what I mean by 'OS middleware' - systemd is basically a distro, and a radical one at that. It is aiming to replace huge swathes of stuff that no one except seemingly Poettering believes is broken in the first place. I think distros would have been more hesitant to adopt systemd as an "init system" if this roadmap had been clear upfront.
<conspiracy>
I have heard the opinion ventured that systemd is actually a power play by Red Hat to introduce an API layer between userland and the kernel - one controlled by Red Hat. It's not implausible - as Red Hat is funded by selling consultancy services, they have a financial incentive to convert as much of Linux as possible into Red Hat Linux.
That's one shitty conspiracy. If this were Red Hat's play, why would they do it with a project that other distros can adopt and have adopted? If anything, providing APIs in systemd makes it easier to migrate to other distros as long as they use systemd. (All relevant enterprise distributions use systemd, i.e. RHEL and SLES and Ubuntu Server.)
Up front, let me state that I have no desire to die on this particular hill, which is why I weasel-worded the hell out of my <conspiracy> block.
However, in this hypothetical scenario, the idea isn't to make it difficult to migrate away from "official" Fedora - it's to make it increasingly difficult to build a distro that is not, fundamentally, Fedora. And if everyone is building distros around Red Hat's quirky middleware, which distro is going to work best? Red Hat's, of course. Who are you going to hire to tell you how to manage the thing? Red Hat, of course.
(The logical extreme of this is the situation with Darwin. OSX's kernel+"middleware" is technically open source, but it's basically impossible to build an OS around it.)
That also makes no sense. Using systemd does not fundamentally turn your distro into Fedora. There are several distros that aren't Fedora that have established use of systemd, and there are several companies selling support offerings around those other distros. In reality, all these distros have come together to work on it jointly as an open source package, which is just a small part of your overall Linux distro typically made up of thousands of packages.
By comparison, I don't believe any companies are selling support offerings for open source Darwin, not even Apple.
Correct, Red Hat will decide the future of Linux userland, not the distros, they will just have to follow. This is a way of building one distro with many flavors instead of many separate distros.
These improvements weren't real. There was a long tail of scripts that didn't follow the standard and never would. Every distribution still had their own customizations on how sysvinit scripts worked (e.g. debian with start-stop-daemon, suse with insserv, etc.)
And rc was different on almost every major distro family, which made life even more difficult for no particularly good reason.
And there's a certain point where all these things you are doing are ultimately to paper over the "hacks and untidiness" of everything. The introduction of systemd had two major effects:
1. It broke all non-LSB init scripts (because LSB is all it supported)
2. It introduced a straightforward declarative syntax for system resources (units for services, timers, mounts, etc.)
I would argue that the above two things have done more to standardize the Linux plumbing layer and help people take fuller advantage of it than literally all the linting, guidelines, and policywork we did for the decade prior.