Linux: concerns over systemd adoption and Debian's decision to switch

Wed Oct 22 16:57:07 UTC 2014

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.