[cycloptic]

The entire purpose of designing models is to reduce things that have irreducible differences and then tell people to shut up and deal with it. There is nothing else there. What is it exactly that you think IT gets paid to do other than this? We have finite time on this planet.

Also, things are constantly being rethought. That is quite literally what the churn encompasses. You can't complain about this while asking for it at the same time. I have seen all these lists of other init systems and while they are interesting, they are completely missing where the actual discussions are happening and what is actually being discussed. The core problem has already moved to a different area and that's why it really doesn't matter if they are doing a bad job. I can see you hinting at this in your article but it's not good to dwell so much on things that happened in the past and are already history. I am very grateful that you actually quoted all your sources though, so thank you for that.

The comparison of init to HAL seems not relevant to me; if anything that has made it obvious that they had the right idea but it was in the wrong place, and that init was the right place to put this type of logic after all. Adding to that it also seems very unlikely that the kernel developers will change their position on the responsibilities of an init any time soon.

And about the idiomatic way to daemonize, nobody follows those guides. Nobody. Seriously. It's a complete clusterfuck and writing more guides doesn't help either. There are an absurd number of programs out there that still use pidfiles. Go and do a search on github for "pidfile" and be horrified.

[vezzy-fnord]

All models are wrong, some are useful, others not so much. There's no need to treat me with these banalities. The job model ought to have died with Upstart. It did not. Oh well.

> The core problem has already moved to a different area and that's why it really doesn't matter if they are doing a bad job.

Yes, I agree.

Still, the losers of history deserve their voice, too.

"Nobody" is a significant overstatement. A lot of (certainly not all) daemons that used to only support double-forking and PID files were fixed in the wake of daemontools. systemd and other init systems benefited from this work when they appeared. Still, PID files are subject to TOCTTOU regardless of what you use, so that's a given.

[cycloptic]

Sorry for the glibness I am just really bored with these complaints, it really feels like the same old bikeshedding. As far as I know there is no way to make a transactional state machine without having the concept of a single, reordable work unit. Daemontools did not solve this or present a different model that was more workable. For every developer that rewrote their daemon to get rid of forking, we got more new developers with outdated learning material coming over who expected services to work like they did on some other crazy environment like Microsoft Windows.

I don't particularly care about who was a "winner" or a "loser" either. In general you cannot get away from TOCTOU on Unix without taking extreme care and avoiding things that would seem reasonable, like storing filenames in other files or using the "kill" command. In practical use I have seen no inits that make any concerned effort to solve these issues at all. That is a situation in which we all lose.

[vezzy-fnord]

> As far as I know there is no way to make a transactional state machine without having the concept of a single, reordable work unit.

You're basically taking systemd's architecture as an axiomatic premise, so no surprise your conclusion is obvious. I reject the premise, and the fruits of it I go into detail in chapter 3.

For the record I am mostly a Unix-hater, so your complaints about Unix are things I agree with. systemd, however, is simply more New Jersey design with unwarranted pretensions.

systemd, in a way, is exactly the init system that a community as infantile and disordered as Linux rightfully deserves. May they enjoy it.

I'll leave things at that.

[cycloptic]

No I am not commenting on systemd or Linux at all. The fact is that if you implement a dependency graph, you must track and resolve state. There is no way around this. Add in support for event listeners and one-shot syscalls out to hardware (because remember, udev or some equivalent is still a critical piece in all this and there is no HAL to handle this for us) and now you have to deal with transactions. Try to parallelize it and now you have work units. That's the way it goes. Even in microkernels you will find all these things scattered around and they aren't going to be less painful just because you wrote them in eBPF. I liked the third chapter but it left me a bit disappointed because it didn't mention anything other than a critique of the wrong way to do it.