4 ms·
You can read up on https://suckless.org/sucks/systemd/ https://suckless.org/sucks/systemd/ It is a good primer into why systemd provoke(d|s) so much hate and c
by HugoDaniel 6y ago
You can read up on https://suckless.org/sucks/systemd/ https://suckless.org/sucks/systemd/
It is a good primer into why systemd provoke(d|s) so much hate and controversy.
- qqssccfftt 6y ago> What PID 1 Should Do > When your system boots up the kernel is executing a given binary in its known namespace. To see what are the only tasks the application running as pid 1 has to do, see sinit. Just wait for child process to reap and run some other init scripts. Very objective and balanced article!
- stonewareslord 6y agoDid you read the source of sinit? It's an example of what init can look like. Check out the <90 source code here: https://git.suckless.org/sinit/file/sinit.c.html https://git.suckless.org/sinit/file/sinit.c.html I don’t think they’re trying to push sinit as a replacement, they’re showing just how bloated their init system has gotten.
- Koshkin 6y agosinit looks like another extreme: systemd does (almost) everything, sinit does (almost) nothing. I think a good design is somewhere in between.
- rleigh 6y agoI strongly disagree. PID1 is a single point of failure for the entire system. If it crashes, the kernel will immediately panic. Try it out yourself and see. A good design would move every last bit of complexity out of PID1, leaving PID1 doing the absolute bare minimum required. There is no need for the vast majority of systemd's functionality and complexity to be physically present in the PID1 image. They could fork off another process to do that. I've always found that aspect of its design to be utterly bizarre. Jamming additional complexity into PID1 is fundamentally wrong, it's obviously a poor engineering choice, and there are plenty of better ways of architecting the system.