- 37comments
- 288comments
- 80comments
- 97comments
- 177comments
- 23comments
- 34comments
- 318comments
- 467comments
- 123comments
- 19comments
- 290comments
- 384comments
- 3comments
- 33comments
- 109comments
- 26comments
- 17comments
- 568comments
- 12comments
- 17comments
- 15comments
- 41comments
- 20comments
- 121comments
- 9comments
- 39comments
- 3comments
- —discuss
- 2comments
I was hoping for a little more on Systemd
Systemd's a dead horse, no use flogging it any more. This article seems much more concerned about the init systems that /aren't/ discussed, but really should be.
Could you elaborate? I know it's controversial and dispute-ridden, but it seems to still be progressing, looking on from afar as someone who has nothing to do with these things.
I think "dead horse" just meant "discussed and debated to death already", not that the project itself is stagnant or ill-fated.
Somewhat related, but I recently started using systemd, and I really like it. The init systems discussed in this article are fascinating though, it'd be really interesting to see what would've changed should one of them "won the war", so to speak.
Author did not cover DragonflyBSD's svc(8) which nobody seems to know about. It's not a full blown init system, but something you would use like daemontools. I could see this turned into an init system with significant benefits by doing so.
https://www.dragonflybsd.org/cgi/web-man?command=svc§ion...
Fuck, I forgot about that one.
Yeah, the interface is daemontools-like, but its primary differentiation is the use of jails.
The author of https://github.com/ServiceManager/ServiceManager states that you already know about it. Yes, it's far too early to put it into a history. (-:
Missing runit http://smarden.org/runit/
Not missing.
runit is a daemontools derivative and so fits under that bill.