The number of broken init scripts I have encountered throughout the years, that went unfixed for months if not years, stand in stark contrast to this statement. And I’m talking packages like uWSGI on Ubuntu 14.04! This is exactly why I gravitated immediately to systemd. The idea that init scripts actually worked and when they didn’t were easily fixable is not true. Yeah you can fix a broken script locally, but this doesn’t fly at scale n > 1. Submitting patches to distros is not a simple process, and not one that makes sense in this context either. Declarative beats imperative 9/10 times, and systemd is one of those 9.
This is demonstrably untrue. I strongly prefer SysV (which is not to say I think SysV is wonderful or anything) over systemD for a number of architectural and functional reasons.
But I do not enjoy digging into other people's init scripts. Fortunately, I rarely have to do that. I think the last time I had a problem with someone's init script was over 7 years ago.
Out of curiosity, what distros do you use that you've had such a good run with init scripts?
Or they can try out runit, openrc or nosh, if they feel adventurous. The last one is not yet in Debian proper.
To the extent that this isn't flat-out wrong, it's only because SysV init had so few features and so the actual patch had to go to one of many different upstreams. Having had to fix the same classes of problem in hundreds of different places like that has given me an appreciation for how long it's been since I've needed to do anything with systemd other than use it.
One important thing to remember is that the ability to have a standard way to start a process, as a non-privileged user, keep it running, with logging, etc. is something which has been standardized in the Windows world since the early 90s. It's really nice not to keep having to spend time working around the lack of a check-box competition feature for a quarter of a century.
Yes.
Yet systemd is unfixable. The fact that it does too much was the most popular complaint at the time it got pushed into every distro... while I disagree, my main concern is that it's unmaintainable.
When there is a bug with systemd, you have to fix systemd. And your version of systemd is completely different from the head, because head was rewritten last month (in a process that persists bugs) and yours is a year old. You can't just use head either, because every low level system on your computer is tied to systemd, and they work differently on head. You won't fork it either, because it's so large that a single person can't keep up.
Without a doubt, a declarative init is much better than an imperative one. But that relatively small number of commands is no gain if each command is more complex than the entire set it is replacing, and I'll completely disagree on the handling of modern hardware, hotplugging and the like. Besides, there is the entire logging saga against systemd.