4 ms·
This seems like a pretty strong and specific technical argument in favor of systemd: https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.de
by Pyxl101 10y ago
This seems like a pretty strong and specific technical argument in favor of systemd: https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html
What's the best single page summary along with adequate details of the arguments against systemd, and what's the professed alternative? From Googling around, I haven't found anything with a comparable level of technical quality, depth, and concreteness.
- nickpsecurity 10y agoBtw, here's the answer to your recently deleted question: http://www.throwww.com/a/7bn http://www.throwww.com/a/7bn Had to do some long shifts before digging it out. Not sure why you deleted it given it was a decent question. Still "self-censoring?" :P Anyway, you can email my profile address about it if still curious on technical angles and such.
- nickpsecurity 10y agoInteresting link btw. I think the number of features is oversold a bit. Others here pointed out that, being so critical, it's best to have first process be simple as possible with another doing the complicated stuff. So, those features could be delegated into an isolated process via message passing. However, it stood out that the shell scripts are complex and buggy in edge cases. Quite opposite of robust programming we normally want. The socket activation trick is nice. I could see following Systemd's lead to improve in those two areas with a regular, minimalist init. Other features in other processes. See where that goes before letting one component go octopus on everything else.