Perhaps that is because you are so wedded to your biases that you are not reading the answers provided. As I said, irrational.

Someone else posted the full list of systemd verification mechanisms in this subthread. I'm going to refer you to that.

And in cases where there is no mechanism in place, for example when systemd is executing an rc script, I have the exact same mechanisms you describe: roll them myself by scripting.

I fail to see the problem here, the systemd way is a superset of the rc way. If you think that is worse, then I stand by my 'irrational' comment.

I assume you wanted to answer my parent, as you are just agreeing with me here.

I have the exact same setup, and I experienced the reverse: using sysv init rpcbind would deadlock with networking, because networking tried to start nfs. Switching to systemd solved that problem.

So we have two competing anecdotes. Now what?

rc scripts offer the opportunity to either make the script wait until the service is responsive

How?

As someone who has written his own rc scripts, I can tell you: there are no trustworthy mechanisms to do what you say rc scripts do as a matter of course.

And yeah, systemd running a standard rc script can't test for these conditions either. Somehow playing this as a systemd weakness seems a bit ... irrational to me.

Wait, what? It's the other way around. If the dependencies are systemd managed, systemd will wait until they report back to be up and running before starting dependants. This is opposed to the SysV rc way, which just blithely ignores all output and continues booting unless the rc script actually hangs.

In fact, one of the most common complaints is that systemd keeps hanging on filesystems in fstab that are not mandatory to mount on boot, instead of ignoring the mount error and leaving them to be mounted manually later.

Aside from the fact that my snark attacked a desire vs. a conclusion, do you have any other reason to call it a strawman but for an obviously personal one (you've been whining at me for a couple of posts now)?

It is still a false dichotomy. No amount of nitpicking changes the fact that the very logic of his statement is fallacious.

Either we want absolute liberty and privacy, OR we want a nanny-state,

Since such a thing as absolute liberty and privacy is impossible, we must be living in a nanny state, watched, coddled and protected from all possible harm.

<Looks around> Hmm. I'm not seeing that. Perhaps you should work on your debating skills and not employ such easily dismissed false dichotomies?

Sadly, reality is not a James Bond flick.

You're an idiot if you don't see that in your case no-one is donating money to put the force of law against you.

Well, to coin one top tech figure: Brendan Eich obviously cares, since he paid good money to prevent Tim from ever marrying if Tim were so inclined.

I'd like to see a citation on this. You wouldn't be the first to be hoodwinked by the Telegraaf Media Groep into believing a canard.

NO. My argument was not that sysvinit was way too buggy. Your argument was that it was perfect, and I was disputing that by giving a single example of one of the possible ways it can break.

It's in fact this kind of dishonest arguing that is making those of us that want to look objectively at the various init systems move away even faster from SysV. Be proud of it. Now fuck off.

Well then call me an idiot and have done.

Shitty scripts are part and parcel in SysV rc. The whole system is an attractive nuisance for badly hacked together shell scripts, and it's a wonder it's held out as long as it did.

All this IMO, of course.

Sigh. Why do you have to turn this into another dick size war? I was trying to be reasonable by pointing out that SysV had some failure modes that systemd tries to address, and that one could at least accept that as a common ground upon which to debate the merits of both systems, but apparently you don't want to give even that much.

And then people complain that Lennart is occasionally a bit crabby online. Frankly, I'm starting to understand the guy.