I need my systems to work. Not once in my career have I experienced a showstopping issue with systemd. I cannot say the same for sysV.
I have had both ruin days for me. In particular the "hold down" when it detects service flapping has caused issues in both.
I use runit now. It's been rock solid on dozens of systems for more than a decade.
I think the *BSD are also good, at least from an educational standpoint, with their relative simplicity and low system requirements. Since there is a lot of integration making a from scratch distro might take less material, but it could be supplemented with more in depth/sysadmin exploration.
The whole point of sysv is the components are too small and too simple to make it possible for "showstoppers". Each component, including init, does so little that there is no room for it to do something wrong that you as the end user at run-time don't have the final power to both diagnose and address. And to do so in a approximately infinite different ways that the original authors never had to try to think up and account for ahead of time.
You have god power to see into the workings, and modify them, 50 years later in some crazy new context that the original authors never imagined. Which is exactly why they did it that way, not by accident nor because it was cave man times and they would invent fancier wheels later.
You're tired of hearing complaints? People still complain because the problem did not go away. I'm tired of still having to live with the fact that all the major distros bought in to this crap and by now a lot of individual packages don't even pretend to support any other option, and my choices are now to eat this crap or go off and live in some totally unsupported hut in the wilderness.
You can just go on suffering the intolerable boring complaints as far as I'm concerned until you grow some consideration for anyone else to earn some for yourself.
Like clockwork, we'd have a SystemD edge case cause a production-down incident at a (single!) customer site once per year. Inevitably, we'd burn anywhere from a half day to a week attempting to figure out WTF, and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.
The project is full of accidental complexity that its maintainers can't be bothered to fix when unplanned interactions cause problems and are brought to their attention. I certainly don't blame them; that sort of work is only interesting to a very specific sort of personality, and that sort of personality doesn't tend to thrive in a typical software company.
I can also absolutely say that I've never had a showstopping problem with OpenRC in the nearly twenty-five years I've been using it. It's remarkable how reliable it is.
Also Linux is trailing here Solaris, OS X, Aix,...
Do you have a reference? Not that I don't believe you, but I hated this behaviour from Poettering (although he seemed to more often blame the user) and we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
> ...we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
To whom would these issues be raised to? Based on my personal and professional experience, the SystemD maintainers (and -for those who are paid to work on the project- those who manage them) seem to disagree that "eliminating sharp edges" is a big priority!
The biggest problem is that people are being railroaded into one thing or the other by the strong arm of corporations instead of being given options. My system helps with that.
I won't support systemd/wayland/etc, but others easily can add that in to their version of the distro if they like and support it themselves without too much work, as it's designed to be forked by anyone.
When I was building the initial version of my distro starting from a Linux Mint computer, one time I accidentally double-mounted the virtual filesystems (/tmp, /run, /proc, etc), on the target volume as my script was too primitive and didn't check the mounts first.
Exactly 60 seconds later, the whole system crashed.
Later I accidentally did this again, except this time immediately caught the problem and undid it. No matter--systemd still crashed 60 seconds later anyhow.
Or like the bug that was revealed a while back where the firmware EEPROM was writable by default in /sys or wherever it was, resulting in somebody's firmware getting overwritten and the system bricked. lol
That's the systemd life for you, in a nutshell. That sort of thing times a thousand. Not all at once, mind you--it will just take a nibble out of you here and there on and off until the end of time. After a while it will straight up fuck you, guaranteed. Which is exactly what it was designed to do.
Same with anything "Linux Puttering" touches. The guy who is now officially a Microsoft employee, as people were saying he really was all along.
I have read the first couple pages of these results. Would like you like to highlight one of these in particular?