Slashdot Mirror
In Which Linus Torvalds Makes An 'Init' Joke (lkml.org)
Long-time Slashdot reader jawtheshark writes:
In a recent Linux Kernel Mailing List post, Linux Torvalds finishes his mail with a little poke towards a certain init system. It is a very faint criticism, compared to his usual style. While Linus has no direct influence on the "choices" of distro maintainers, his opinion is usually valued.
In a discussion about how to set rlimit default values for setuid execs, Linus concluded his email by writing, "And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why."
In a discussion about how to set rlimit default values for setuid execs, Linus concluded his email by writing, "And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why."
To this Linux outsider, it seems that systemd was implemented more because someone decided to do it, rather than being done because it was the appropriate solution to a problem.
No, it's both. There was a valid problem: sysvinit was decrepit and unsuitable for modern systems, as seen by the fact that every other Unix system out there has abandoned it and has something that resembles systemd in some way (Solaris has SMF, MacOSX has something else).
But because there's no overall system-level architect, some guy just decided to make his own solution, which very likely is suboptimal because he's not a system-level architect and there seems to have been little to no other input on the solution. People complain about "design by committee", but this is what happens when you don't have some amount of design-by-committee: you get one person's pet project which might have some great ideas but then has too many rough edges or even severe design flaws because that one person's judgment isn't tempered by other peoples' experiences and criticisms (esp. if that one person is actually hostile to outside criticism...). Even the Linux kernel has a good amount of design-by-committee if you look at its history: different subsystems have different maintainers, and there's been a very active mail discussion list ever since the start where people discussed major changes before just merging them in willy-nilly.
You make a great point about having a system-level architect. Red Hat has been trying to fulfill that role for a long time now, but has done a very questionable job really. Just the fact that they've been pushing GNOME so hard shows their judgment isn't very good; Gnome has horrible architecture (esp. its terrible and unstable and undocumented Gtk+ library) and just isn't very functional. It's another great example of a small team with some wacky vision pushing it on everyone else without any external input/criticism or pushback. Red Hat projects seem to be like this a lot.
Yeah. systemD supports the Windows-philosophy of doing almost everything, but doing it half-assed. Besides, what's wrong with having the DNS server be part of the init system?
And yet that part isn't 100% separate... it cannot operate on its own, it requires libsystemd -> it isn't separate. While it is true it is mostly unused it is a gross misrepresentation to say it is 100% separate.
Systemd is a poorly thought out concept.. Half of the feature-creep is because of a lack of understanding and the other half due to NIH. ... sure starting with a number is bad BUT blocking a "." in the name... that SMB and AD issues right there...
The recent "username starting with a number" bullshit is clear proof of that... username start with a number & wanting a unitfile executed as said user ? TOBAD... executing as ROOT... Systemd still hasn't resolved this & their preferred solution right now is redefine what a valid user is
Or what about the rapid polling of getpid() ?
its a flawed concept
incorrect so stop spreading FUD...
sysvinit is perfectly fine. The issue was sysvrc & more specifically the really bad sh coders that redhat had.
SysVinit as init, ie pid1 is good enough... its boots from the kernel, its launches RC, it reaps zombines and it shuts down the system. THAT IS ALL INIT NEEDS TODO.
Sure pid2 might need to be more complex BUT PID1 does not! especially if you need todo an update w.r.t. RC, which with systemd needs a reboot DERP!
SysVInit is very simple and does its job well; runit is very very good as well, likewise openrc-init is good. The commonality is simple PID1
So because Redhat cannot write good sh they push a concept with people that can't write C/C++ not can design an RC system and when they run into issues they absorb concepts rather than fixing their issues.
I quote myself...
More pointedly, systemD has recently been found declareing usernames that are considered valid by the system at large and by POSIX standards, to be invalid and selecting a new userid at random (on some very common systems, root) and silently running processes under that user id.
This is an EXTREMELY non-standard behavior and as such, unexpected by the user community at large. By many, it is considered a security breech. Based on the comment from Linus, I suspect he does not consider this to be sane behavior.
The systemD developer community has demonstrated reluctance to correct this observed behavior.
This isn't "change is scary". This is, the damned thing is broken and the developers went into Pewee Herman mode (I meant to do that! I won't fix it).
THAT is scary. The rude and dismissive attitude around the cult of SystemD is even more scary.
...For all these things and many more there has been a turf war along the lines of "We will fix this in the kernel!", "Oh no you won't, we will fix this with our daemon", "Oh no you won't, my userland administration tool will fix this"....
At that point, the need for an overall system-level architect comes into play. Someone who looks at the overall system, its architecture and design goals and decides the best way to implement features and fixes.
.
To this Linux outsider, it seems that systemd was implemented more because someone decided to do it, rather than being done because it was the appropriate solution to a problem.
Unlike most complainers (some that simply doesn't understand systemd at all) systemd solves a number of real world problems created by the disconnect of how computers used to be used (let's call it "static" configuration) and how a system is used today (... "dynamic" configuration).
If systemd is so bloated, reinvents the whole of Linux, is a Microsoft conspiracy etc. why is that it actually solves (most) problems with older init systems? Why is it modern Unix systems have similar "dynamic" init systems rather than the old? Why is it nobody else actually created a modern init system that can be used for the same things as systemd but "follows the Unix philosophy"*?
In a was systemd is kind of a hack - but that is because it tries to integrate into the Unix design and allow it to do things it wasn't designed to do. In some cases maybe systemd have to much of hack in it but again: where is the alternative?
Note: I don't really like systemd.
(* I strongly maintain that people taking about 1) doing one thing well being a Unix thing rather than a design thing 2) thinking that philosophy is actually applied to modern Unix systems are seriously confused)
I am not questioning you opinions on systemd, particularly since my father, a retired CE and lifelong *nix user dislikes it with a passion. But I'm way to ignorant of the dirty mechanics and politics of Linux to understand how, with so many presumably knowledgeable folks who dislike systemd, it became a standard in the more popular distros. Does it solve some vexing issue for the maintainers of these distros? What do these people find so compelling as to make such a fundamental change?
If you want news from today, you have to come back tomorrow.