[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.