Linus: “I no longer feel like I can trust ‘init’ to do the sane thing”(lkml.org)
lkml.org
Linus: “I no longer feel like I can trust ‘init’ to do the sane thing”
https://lkml.org/lkml/2017/7/6/577
339 comments
Ted Ts'o, the Linux ext2/3/4 filesystem developer, posted this two days ago at G+ as well. Interesting discussion, particularly about 1) systemd's bad programming taste and complexity, and 2) Lennart Poettering's inability to admit when he is wrong.
"For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible."
Also:
"Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition."
And:
"The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned."
https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
"For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible."
Also:
"Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition."
And:
"The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned."
https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
systemd is a mess. A while ago I tried writing a script for CD ripping that ran when udev detected a music CD in the optical drive, ripped the CD, then ejected the disk.
This kept failing. It turned out to be systemd having a hardcoded timeout of something like 30 seconds on any process launched by udev, that couldn't be changed without recompiling it from source, or having it fork off some other process group that lacked this limitation.
From what I can tell, systemd has some of the worst sort of developer myopia, where whole swaths of legitimate use cases are actively destroyed.
This kept failing. It turned out to be systemd having a hardcoded timeout of something like 30 seconds on any process launched by udev, that couldn't be changed without recompiling it from source, or having it fork off some other process group that lacked this limitation.
From what I can tell, systemd has some of the worst sort of developer myopia, where whole swaths of legitimate use cases are actively destroyed.
Making too many assumptions about the user environment is not smart. Then you start putting constraints and becoming defensive when these assumptions are questioned. This is becoming a pattern for systemd as is blaming everyone else. [1]
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone.
For instance if you have too many network interfaces and naming is a problem then switch on predictable network names which btw is anything but predictable for human beings and let the 97% who don't carry on.
12 digit random names are simply not predictable or better for human beings than eth0, wlan0? If there is a problem predictable network names is not the solution.
Similarly if you need binary logging and an audit trail then turn on binary logging but don't impose it on everyone else.
Its time to move beyond silly accusations of 'hate' etc every time there is a discussion about systemd because at the moment it just serves to deflect criticism and avoid accountability for questionable decisions.
[1] https://github.com/systemd/systemd/issues/2407
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone.
For instance if you have too many network interfaces and naming is a problem then switch on predictable network names which btw is anything but predictable for human beings and let the 97% who don't carry on.
12 digit random names are simply not predictable or better for human beings than eth0, wlan0? If there is a problem predictable network names is not the solution.
Similarly if you need binary logging and an audit trail then turn on binary logging but don't impose it on everyone else.
Its time to move beyond silly accusations of 'hate' etc every time there is a discussion about systemd because at the moment it just serves to deflect criticism and avoid accountability for questionable decisions.
[1] https://github.com/systemd/systemd/issues/2407
Linus has the proverbial moral authority to bootstrap an init system and the technical skill to pull it off. Amusingly, this strikes me something like the chairman of the Federal reserve hinting that he thinks interest rates are too high. Hopefully, the systemd developers will take notice and clean up some of their act. (Not to insinuate anything. They have widely known problems in playing nice with other projects, taking feedback, etc.)
They [systemd] shouldn't piss him off too much. He will sit down for a week, come out with his own init system which will take over the world. /s but not entirely :)
Like what happened to git in the past, will Linus write a new init himself this time?
The quote here in the title is missing the vital context -- the full quote is
""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.""
""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.""
This reminds me of a relevant joke.
Systemd walks into a bar. It shoots the bar owner and proclaims itself to be the new owner. It then turns the bar into a farm, brewery and distillery, opens a casino, a freight rail line and an investment bank. Oh, and there's an init system thrown in there somewhere too.
Systemd walks into a bar. It shoots the bar owner and proclaims itself to be the new owner. It then turns the bar into a farm, brewery and distillery, opens a casino, a freight rail line and an investment bank. Oh, and there's an init system thrown in there somewhere too.
The internals of systemd are maybe not the best. But the UI is definitely easier to grasp than what existed previously.
Just wanted to say that the issue is about automatically copying rlimits from the init processes to all processes executing setuid binaries - apparently Linus thinks that init could possibly apply some rlimits to itself for its own purposes which wouldn't necessarily be suitable for copying to any other random process.
IMO this idea with copying is in itself even less sane than init using rlimits on PID 1.
IMO this idea with copying is in itself even less sane than init using rlimits on PID 1.
Gee, such a surprise. Why didn't you speak out about it earlier, then?
For those who can't stand lklm.org UI, here's the mail on spincs.net:
https://www.spinics.net/lists/kernel/msg2550717.html
https://www.spinics.net/lists/kernel/msg2550717.html
When so many think that something is wrong, maybe there is some truth about it...
If even the creator have concerns, man, that's not a joke!
If even the creator have concerns, man, that's not a joke!
I would assume this is about systemd. Personally my experience with it has been great - the occasional screw-ups (they did happen - something related to dbus made all systemctl commands fail until a reboot) were nothing compared to the time I gained not having to worry about prehistoric initscripts.
So while it isn't perfect, it's IMO a step in the right direction, if only by lowering the barrier to entry to actually using and managing the thing.
If you are worried about stability then you shouldn't rely on a single machine anyway. Personally I manage systemd screw-ups (though I haven't had one in production yet - all of them were on my personal machines while monkeying around with Archlinux) just like any other hardware failure - by making sure my app/service stays available even if I yank the power cord from the machine.
So while it isn't perfect, it's IMO a step in the right direction, if only by lowering the barrier to entry to actually using and managing the thing.
If you are worried about stability then you shouldn't rely on a single machine anyway. Personally I manage systemd screw-ups (though I haven't had one in production yet - all of them were on my personal machines while monkeying around with Archlinux) just like any other hardware failure - by making sure my app/service stays available even if I yank the power cord from the machine.
Here's something I don't understand... Why do so many people hate systemd but not macOS's launchd [0]? Don't they serve similar purposes? I've been digging into macOS for a few months now, and I'm pretty happy with their defaults.
EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm not a linux expert, so I'd love to hear your criticisms.
[0] http://www.launchd.info
EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm not a linux expert, so I'd love to hear your criticisms.
[0] http://www.launchd.info
I wonder why Poettering chose Kay Sievers to work on systemd in the first place.
I fucking hope not.
Linus is clearly very smart, but user-facing tools is not what he's good at. Git is a perfect example of this.
Mercurial and Git were created ridiculously close to each other, and their main features/use model are quite similar, and yet mercurial is literally years ahead in terms of usability. The results to a given command are 99% of the time, what you would intuitively expect.
Now here's what I would love to see: Linus initiate a fork/rewrite/whatever of the init part of systemd, that keeps the concept of non-executing service definition files. They don't have to be compatible with systemd but that wouldn't necessarily be a bad thing either.
Edit: actually, aiming for compatibility probably means having to reimplement systemd weirdness, so probably is a bad thing as I think about it.
Linus is clearly very smart, but user-facing tools is not what he's good at. Git is a perfect example of this.
Mercurial and Git were created ridiculously close to each other, and their main features/use model are quite similar, and yet mercurial is literally years ahead in terms of usability. The results to a given command are 99% of the time, what you would intuitively expect.
Now here's what I would love to see: Linus initiate a fork/rewrite/whatever of the init part of systemd, that keeps the concept of non-executing service definition files. They don't have to be compatible with systemd but that wouldn't necessarily be a bad thing either.
Edit: actually, aiming for compatibility probably means having to reimplement systemd weirdness, so probably is a bad thing as I think about it.
Systemd is a steaming turd. However, it's one we have to live with, and there doesn't seem to be anything better on the horizon.
A good book on the subject might make things slightly better. However, it doesn't seem like anyone is interested in writing one :-(
A good book on the subject might make things slightly better. However, it doesn't seem like anyone is interested in writing one :-(
This is taking a quote out of context and trying to start the old usual systemd flamewar. Flagged.
I'd say that I no longer feel like I can trust 'git' to do the same thing either... but who am I kidding? I never trusted it to do the sane thing.
EDIT: Here are links to comments discussing the actual content of his email, in case anyone else came here for that and left wanting.
https://news.ycombinator.com/item?id=14734868
https://news.ycombinator.com/item?id=14733973 -> https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
EDIT: I read all the comments on this post, and I am disgusted to report that (as of this EDIT, nitpickers) the 2 above-linked comments are the sum total of actual replies to the content Linus was trying to discuss. I hope LKML had more self-control than HN.
EDIT: 14733558, it was really excellent of you to try and defuse things, too.