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."
Presumably, this is a poke towards systemD. It has suffered from feature-creep, which directly opposes the unix-philosophy of doing only one thing, but doing it well. Recently, there was a problem with, I believe the DNS server which is part of systemD.
...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.
sysvinit was decrepit and unsuitable for modern systems,
This is complete bullshit. My (modern) computer worked perfectly fine before systemd. There was zero improvement after my preferred distro replaced init with systemd. Maybe it booted up 2 seconds faster? I don't know, it's linux, I don't ever fucking reboot it. The only change in my life was how much time I had to spend learning systemd bullshit that added ZERO VALUE to my use of linux on my pc.
So you better get a LOT more specific as to which system was "unsuited" for sysvinit before you start making blanket statements like that or people are going to continue to call you out on your bullshit.
SystemD is a trainwreck from day one and just keeps on piling more of it. If it were only init, things would've been more than fine. But no. It's a whole project of reinvented crapware that is reinvented BADLY. And distros blindly install more and more from the "project". Like Ubuntu and their idiotic decision to switch to systemd-resolved which was wrought with nothing but trouble, rendered Ubuntu 17.04 dead in the DNS water for a month since its release! I wonder which maintainer got paid to subvert Ubuntu with that.
* networkd assuming dhcp client role, but then not renewing lease (freedesktop bug #82731 -- open for 3 years now!!), among many other issues ...
* resolved assuming DNS resolver role, but then not being nearly compliant with RFC, among many other issues, some even serious security vulnerabilities
* consoled taking over console, but then someone realized it's a REALLY dumb idea so they scraped it (for now)
* timesyncd assuming ntpd role, but then doing stupid things like defaulting to Google NTP which is NOT a normal NTP service! Asked by google to not do that, responded EWONTFIX (systemd github issues #437), among many other issues
In fact, it's even bad at being "just an init". Good luck with those NFS mounts and systemd. Good luck with "A start job is running" when it encounters a trivial situation that every. other. init. can. work. around.
It's a shitshow fueled by arrogance of "we know better than all of you combined", just a quick look in the github issues is sufficient to see this. It's so out of control, that issues found to be 10 on vulnerability scales are closed as not a bug (CVE-2017-1000082).
Every software has bugs, but systemd bugs are closed EWONTFIX because the principal developer has zero clue about modern operating systems. The principal developer of an init for a traditionally server oriented operating system* who, by his own words, never administered servers. And who, by his own words, disables read ahead prefetch because "systemd developers all run laptops with SSDs and don't need it"....... !!
It's a sinking ship, rats are fleeing, and more and more professionals are getting SICK of it. You were warned, you laughed, you called us luddites, now enjoy the turd.
*) With a server market share of more than 50% (look up Netcraft monthly stats), and a desktop market share of 1% -- so guess where the priorities are
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.
That's because in-part design-by-committee ends up with the noisiest, stupidest person on the committee calling the shots, that project ends up catering to the lowest common denominator.
A large part of why Linux itself is successful is that while there's a lot of input, there's a single point of decision making in the form of Torvalds himself, and he's both smart enough to generally make good choices, and to listen to the debate and weigh the arguments to make a decision.
Lennart Poettering is no Linus Torvalds. Perhaps something to replace System V and BSD inits is necessary, but Poettering's work with pulseaudio is itself incomplete; the init system is far too important to trust to him when his sound daemon, a relatively small but important piece of the desktop system, isn't really finished to a polished state.
Besides, with the advent of the VM model for hosting and "cloud" where VMs are created and destroyed on an as-needed basis and automatically, stripping down the init process to the bare-minimum needed for a VM and using some kind of staging system to spawn the right conditions in the VM init process is probably more important than some all-knowing, all-seeing system that seems more tailored toward long-running, general-purpose computing anyway. The problem that SystemD solves isn't the new problem, it's the old one.
Do not look into laser with remaining eye.
No. The problems in systemd were closed because the maintainer didn't like people pointing out that his design is shit.
No, logs are preserved by shipping them off to another system over the network. Binary logs are harder to forge, but not impossible. Faking wtmp entries is a thing, for example.
The username starts with a zero thing where closed days ago.
Why the fuck should an init system even CARE what the user name is?
Why the fuck did that init system reinvent user handling that the OS was ALREADY doing?
Why the FUCK does systemd have it's own fucking DNS implementation?!?!
Calling systemd SHIT is an insult to every piece of excrement, feces, turd, and dung that will ever be egested in the entire past and future history of this and every other fucking universe.
Good for you. Mine didn't. Not my modern computer, not my server. What it did do was work something resembling fine after the init system had an endless array of other things bolted on to it to try and pretend to make it handle system events, It had endless scripts that executed sub processes to monitor the actual daemons in case they went south. Oh and when they did go south there was no way of the system knowing if a process was even running if it didn't go through some arcane process like clearing a PID lock file.
So I'm very glad that that you're not a distro maintainer given that you have a little perfectly working anecdote in your safe little space and think that therefore there is no problem in the wider world.
Or, exiting zero on error!
As to the problem of swallowing stderr, that's also pretty serious. When you can run a command by hand and see a clear error message, but it isn't logged at all in the journal, that makes troubleshooting very difficult and time consuming. Example from the unit file for MongoDB:
ExecStart=/usr/bin/mongod --quiet --config /etc/mongodb.conf
Or, when Poettering's employer Red Hat does things like this in systemd unit files "... > /dev/null 2>&1" then errors aren't logged. Ran into that this week when I had a typo in a BIND file. I have over 1,900 domains on one server, so it can be very hard to find the error.
There are so many ways to add an username Poettering won't like. The majority of programs for creating new accounts (except for adduser). Samba+AD, as you said. LDAP. Any random "pull authentication from a database" script. Using an editor on /etc/passwd. Etc.
POSIX defines a minimal set that must be supported, and systemd fails to handle even that.
But this is not the damning part -- every piece of software can have bugs, any non-trivial piece of software has bugs. This is natural. What's totally, utterly unacceptable, is responding to an obvious, critical bug, that also contradict the standard without providing a rationale, with a WONTFIX.
On a shit package that applies rainbow colors to a line of text, this would be grounds for immediate purging.
On something that wants to replace init+rc+mount+pm-utils+DNS+lxc+about everything else, it's grounds for nuking an entire distribution from the orbit.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
The project is a massive "cathedral" instead of modular pieces - planned for that reason or not a fork would be more difficult than devising a total replacement structured differently.