Hacker News new | ask | show | jobs
by cycloptic 2243 days ago
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.
1 comments
vezzy-fnord 2243 days ago
> 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.

link
cycloptic 2243 days ago
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.
link