On 10/21/2014 05:20 PM, Jimmy Hess wrote:
The all-in-one approach of systemd might have a place on some specialized desktop distros, but outside that niche its' IMO a terrible idea.
The proper fix is probably a go back to Upstart or SysVInit and rewrite systemd, so all the pieces are separated and exist as a higher layer on top of init.
That is how systemd works, there are many parts and "systemd" is the sum of all those parts. It has a PID1 that replaces sysvinit/upstart, but afaik it doesn't do a whole lot extra. I don't use systemd, and I don't know a lot about it, but it seems lots of people don't get that it's not all lumped in PID1, there are a lot of processes that do different things that are mostly tightly held together (I think only udev and a couple other things still work without the rest of systemd.) Then again, the systemd people do spread FUD about sysvinit as well, Poettering's own blog for example even misleads on how systemd and sysvinit work http://0pointer.de/blog/projects/why.html A lot of things in the comparison chart have sysvinit listed as "no", when it's obviously not init's job directly, but a subprocess/script, except it lists "yes" for systemd on some, where systemd still passes it off to a subprocess! (They really are taking advantage of the PID1 and the entire bundle of software both being named "systemd" I guess.) [Insert obligatory "No I don't think sysvinit is perfect, but..." here] ps. What's with all the fear/hate of shell scripts? I realize the init scripts on most Linux distros are messy (200 LOC just to start sshd? Come on debian.) but the solution isn't to run away from them; rewrite scripts to have saner logic and not do a dozen redundant/unnecessary checks.