made elsewhere, and I continue to disagree emphatically.  I've been a Linux system administrator, professionally, for decades ... not one, not two, but three.  I cut my teeth on Slackware and evolved with RedHat.  Now I use Devuan.  Why am I here?  Largely because SysVinit "just works".  It's solid, stable, reliable, secure, and does the minimal amount required to achieve those goals.  It "does one thing well" and is the gold standard by which all other init systems are measured even today.

If runit, or any of the others, rises to SysVinit's level, I happily encourage their use.  But that is a high bar to reach.

Labeling SysVinit as a "hobbyist" tool is not remotely accurate in any Linux history book.  It was, and is, bedrock upon which Linux emerged as a player in the arena.  The "harsh reality", if there is one, is that SysVinit was foundational for every professional Linux sysadmin today having a little gray in his beard.  It works as well today as it did then, and it still works better than many/most of its competing init systems depending upon the criteria being measured.

That being said, when RedHat replaced SysVinit with upstart, I hardly even noticed, and felt no inclination to move to another distribution.  I immediately felt that inclination when systemd became the forced standard.  RedHat forced me, a veteran sysadmin, to either start with a new distribution or abandon the stability, reliability, and security I was accustomed to.  I was expecting to return to Slackware before Devuan arrived on the scene.  And Devuan has been exceptionally good.

There is room for other quality init systems and maybe runit falls into that category as upstart did.  I started reading this thread mainly to see if other gray beards felt it to be so.

Cheers,
--K

It's not bug-free, and I got very frustrated when a weird intermittent bug was made infuriatingly hard to investigate due to sorely misleading documentation. (RTFM! - yes, I did! It was bad so I wrote my own.) However, once that was solved it has worked well enough.

The maintainer, forum user @Lorenzo, has to his credit been active and responsive in fixing issues.

It has promise and I like the idea behind it, so I'm stubbornly going ahead because it should work, damn it! However the reality is that I can't recommend it generally because decades (yes, decades!) of neglect from the wider community has left it hard to diagnose and fix whenever something goes wrong.

Boot times may be issues for some, but I was never that concerned. If someone is going to go the lengths of changing init system to save 10 - 20 seconds on boot, then it's most likely they would be better served by upgrading to an SSD, or M.2 or whatever.

I don't think any init system is all about boot times. systemd did cite faster boot times in various propaganda, but that wasn't its main advantage/purpose.

The people behind systemd, were never concerned about those init replacements - they knew that sysvinit was what they had to undermine and defeat...

Personally I think the increased adoption of runit and OpenRC was driven by systemd's anti sysvinit propaganda. Some willingly swallowed this with the added "...but systemd is not the answer" clause. Others utilised it as a means of distancing themselves from the critique being directed at sysvinit in order to undermine it and establish systemd as the de facto standard. Those people who jumped ship and dumped on sysvinit did a lot of the damage in my opinion - they did the devil's work, by word for word repeating sysvinit's supposed deficiencies.  Apparently vindicating the systemd cabal in the process.

This is a very astute statement. But with that being said, I have used runit and it works very well. To me it did seem to start up quicker than sysvinit, but I never timed it with a stopwatch. It probably just seemed like it.

Online, I saw  monit mentioned as a statistics provider for MMonit, in the vein of Prometheus (As I was researching infrastructure monitoring). I wasn't aware monit's primary purpose is 'Process/Service supervision'... since 2007.

apt show monit
https://github.com/MMonit/monit
https://en.wikipedia.org/wiki/Monit
(searching for a worthy monit guide or tutorial to mention)

I just use on desktop then would be no difference anyway I guess

How do you make the decision what is it important?

Good question, and easy to answer really. I start off with a netinstall iso, install just the basic system with no DE or anything. Then I boot into that console, and all that's there generally will never change. Then I start apt'ing packages and everything after that is fair game.

The base system has been solid for all of the 10 years i've been using it, no reason to change it IMO, it always works for me.

I do support all those who work on runit, dinit, openrc etc. More options are almost always good, whether I choose to use them or not.

First, thank you, blackhole and greenjeans, for your reply. I noticed that you did not answer the question: What is an admin or user supposed to do if a service fails due to a transient error? How do they know that?

@greenjeans: No, this is not "incongruous thinking". When I get the story right it was like that (feel free to correct me): Around 2000 Linux was the new kid on at the table. HP-UX, IBM AIX, SCO, Sun and yes, Microsoft too were the established names for the server room. You had to persuade your manager to bring Linux. But was still a freaky and nerdy thing made by a group of coder led by some Finish guy. How could that possibly work? But you got the permission. Then the day came where the mail, print, file or web server (or all together) failed. That was clear from the beginning, wasn't it? I mean, what quality can you expect from a bunch of non-professional coders? With good luck they were working for a university (iow: an egghead). Can you even imagine how bad such an admin feels? He then turns to SysV for assistance and what he gets back is like: "Well, you know, the philosophy is that services don't fail". Now Linux does offer great opportunities for everyone, so the admin might have answererd: "Thank you, but I will fork off."

Another question for you:

How do you make the decision what is it important? Or let me ask that otherwise: There was a time before SysV init-style. That was changed (broken?) for SysV. What made this change so extremely good that it seem to hit some optimum, which cannot be enhanced by further changes? Oh, please @blackhole: you might also have suggestion on that. Please let me know.

Changing is not automatically breaking. There was I time when I asked myself: "How could I change SysV init into something with supervision with minimal (scriptable?) changes to the init scripts?" to have the best of both worlds. But that would things only on the surface.

Thank you, JCK, for mentioning other init-styles. It remembers that the init-space is totally fragmented. Changing / enhancing SysV would only increase that. I'm not suggesting anything like that and I'm really no longer care about init-styles. Instead I started to make my own pidN service controllers that could run with minimal impact below any init-system I find. (If I would have to choose, I think I would take runit: I like its concepts anbd ideas but not so much the implementation.) SysV, systemd, /sbin/init? I doesn't matter. It's pretty easy to configure a single service to whatever the system runs and from that I'm on my own. And in addition to the small footprint, I do not depend on others, their implementation or whatever.

But back to the question above, I would be really interested in how you (all) decide what to consinder to change or update and what not. Because there the difference between bloat and not-bloat starts.

I agree to that partly. What I think is wrong with Linux is that every program has to have address all (!) possible use cases. Even if they are only useful in years where Easter Monday is on Thursday.

*greenjeans most definitely breaks stuff to see what's possible, just not the important stuff*

I have that habit too sir!

Wanted to leave this comment yesterday but a bit earlier in the discussion was a remark about service supervision and crashy programs - that is correct i might say, but modern init also brings dependency tree and readiness fd (and few more such not shell friendly ipc things). They were brought by upstart which was quite dubious like systemd but for different reason cause it was designed with desktop in mind, but predates it by a lot, even predates openrc by a year or two.
I would guess they are somewhat useful. Just like how user services are useful in this privilege separated desktop thing that became the norm, don't know when.
Lightweight stuff like puppy replaces sysvinit with busybox but the shell scripts are very similar.

On boot times - maybe systemd was faster when it was new and much slimmer, but as for now i have this modified dinit setup which boots in 1 second (4 seconds with vmlinuz) to the desktop, with nothing too special machine wise.

I personally like seeing things go forward the dinit way and less the daemontools way (for instance s6 compiles it's db, kind of gross). Openrc is a good middle ground here and it looks pretty.