Linux kernel hacker's open rant about systemd

in linux on (#3V8)
Linux kernel hacker Christopher Barry has engaged a full frontal assault of the systemd Linux subsystem and its creator, Lennart Poettering, on an "Open Letter to the Linux world" published on the Linux kernel hackers' mailing list. Here's a taste:
So why would very smart people who love and use Linux want to create or embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the reasons they say, as I mentioned at the top. But partially I think it's from a lack of experience. Not a lack as in programming hours, but a lack as in time on the Planet. Intelligence alone is not a substitute for life experience and, yes I'll say it, wisdom. There's no manual for wisdom. Implementing systemd by distros is not a wise move for them over the long term. It will, in fact, be their ultimate undoing.
Systemd has been no stranger to controversy. It broke a lot of systems, and important figures in the Linux world have registered their doubt about the replacement to the well-known System V init system, which was a fully transparent collection of human-readable scripts but that led to slow boot times. It will be interesting to see if Barry's rant generates a groundswell of antagonism against the new system, or if it gets ignored, or if it leads to meaningful debate and change.

[Ed. note: picked up this story from comp.misc. Thanks, Rich!]

Re: sysvinit was a dead end (Score: 2, Insightful)

by on 2014-08-14 16:03 (#3VF)

Pretty much echoes my sentiments regarding SysVinit. It gets the job done with minimal resources, but it's not really appropriate for modern systems where a parallel and dependency driven init process is a major user requirement and resources are no longer an issue - especially on desktop and mobile devices where the user would like as near to instant on as possible. Despite that I find SystemD does what it is supposed to without too much fuss, and is in many ways more capable than sysvinit, I also think it's a bloated mess that was badly designed from the start, and when it comes unstuck fixing it is an absolute nightmare. Don't even get me started on the whole DBus integration/requirement thing; that sounds more like something Microsoft would have cooked up for Windows than the core principles of UNIX, and is one of the main reasons that I'm taking a good look at migrating as many of our Linux servers over to BSD as possible when they are next due for a refresh.

PID1 needs to just do the essentials and be a minimal piece of code that is pretty much as close to "hello world" as you can get to avoid complications and failures, everything else should either be an optional SystemD module or an external program depending on the the user's preference. Want SystemD to handle your logging, fine, tell it to load that module and off you go. Want to run a proper daemon that can listen for remote log entries too, then disable the SystemD module and use RSyslog or whatever you prefer. Some functions of SystemD are already modular, but that needs to go a lot further in my view, and requiring stuff like DBUS integration right there in PID1 is just asking for all sorts of stability problems, but it into a module, then at least there's a chance the system might be able to recover without a kernel panic.
Post Comment
What number is 1st in the series twenty seven, 17, twenty eight, thirty four and 10?