Linus will not be merging any code from systemd developer(permalink.gmane.org) |
Linus will not be merging any code from systemd developer(permalink.gmane.org) |
https://bugs.freedesktop.org/show_bug.cgi?id=76935
I had actually started to warm to the idea of systemd, thinking that it couldn't end up the same clusterf*ck of mismatched reinventions that didn't really solve any problems that pulseaudio was. I guess it's time to move to Debian/kFreeBSD and ignore this crap.
Ubuntu probably won't because they're user-hostile, but I really hope Debian and the other major distros move away from systemd.
It worries me that Sievers, and the systemd team aren't approaching testing with an almost paranoid attitude. Linux is finally getting a foothold in consumer desktops, it'd be a shame for people to go back to other operating systems purely because "it broke one day, something about systemd".
You don't cavilierly fuck with PID 1, and that's precisely what the systemd folk appear to be doing.
I'm really hoping Linus's rant makes an impact on them.
I find the whole dependency system completely bizarre, because to truly implement it, you have to hook into _everything_ and make it part of this odd binary mess they've created above.
I really don't understand the route they are taking, I see the system becoming less capable and more fragile with this type of engineering being encouraged.
FWIW, exactly this happened to me on an upgrade one day on another Linux distribution, after a few other headaches. The switch to systemd broke smbd/nmbd, at the time there were not yet tools for spitting the new binary log format into text, and trying to data mine that logging system to figure out what the hell broke was a real adventure.
I was so skeeved I immediately dumped that and fled to Debian, because it had a reputation for stability.
Imagine how excited I was when Debian voted to adopt systemd.
I, also, have started looking at the BSDs again recently. herbstluftwm looks pretty nifty.
GNU/Linux support has improved a lot since my first installation in 1995, but it is still hit-and-miss on laptops.
For example, editing your xorg.conf is virtually a thing of the past these days. I haven't touched it in years and run a fancy triple monitor setup.
> "Hmm, a user adds to the kernel command line "debug" and systemd starts spitting out so much crap that the system doesn't boot anymore? That sounds like a major regression to me. Note this is a kernel command line, not a systemd command line. Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong.
> This bugzilla is the poster child of why people hate systemd and do not trust the developers that work on it."
My understanding is that this is not the issue and, in fact, the command line parameters are provided to userspace in the way that they are exactly so that applications can do this kind of thing.
Rather, the real issue is that the flag IS commonly used this way, and systemd's response to it being set was so aggressive that it prevented it from being used for anything else. A not-uncommonly-used system configuration, having "debug" set, was being broken unnecessarily and in an unintuitive way.
Yes, and they should be using, e.g., systemd.debug just like they use other systemd.* parameters to avoid collisions (and shit like this).
It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.
It looks like Greg has stepped in as a baby-sitter for Kay, and things are going to be fixed. And I'd really like to avoid adding hacky code to the kernel because of Kay's continued bad behavior, so I hope this works. But it's really sad that things like this get elevated to this kind of situation, and I personally find it annoying that it's always the same f*cking primadonna involved.
Steven, Borislav, one thing that strikes me might be a good idea is to limit the amount of non-kernel noise in dmesg. We already have the concept of rate-limiting various spammy internal kernel messages for when device drivers misbehave etc. Maybe we can just add rate-limiting to the interfaces that add messages to the kernel buffers, and work around this problem that way instead while waiting for Gregs fix to percolate? Or are the systemd debug messages going to so many other places too that that wouldn't really help?
Linus
"It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.
It looks like Greg has stepped in as a baby-sitter for Kay, and things are going to be fixed. And I'd really like to avoid adding hacky code to the kernel because of Kay's continued bad behavior, so I hope this works. But it's really sad that things like this get elevated to this kind of situation, and I personally find it annoying that it's always the same f*cking primadonna involved."
> my last kernel patch is more than a year old, my last non-trivial kernel patch 2 years old. i stopped working on the upstream kernel "long ago" for reasons i cannot stand the attitude of these guys, i decided to work with grown up or funny, or grown up and funny people instead and i enjoy it a lot more. not sure what this childish blackmail attempt relates to.
[1]: https://plus.google.com/108087225644395745666/posts/3cWXzYqB...
It doesn't matter what it's about. It's just an excuse for this:
http://pixdaus.com/files/items/pics/3/23/520323_376f9c805b8b...
This is at best a minor bug since it only affects the first line read from /dev/kmsg, but I thought I'd point it out if anyone wants to fix it.
- Kay claims a system not booting due to a casual kernel log flood from systemd is not an issue.
- Linus agrees the "debug" flag (along with other generic kernel flags) should be used by services like systemd, yet blasts Kay for using it, because it "usually isn't a problem", but here "it's a problem".
- Linus threatens not to accept kernel patches from Kay.
- Kay has not written a non-trivial kernel patch for over two years, and doesn't want to write any.
- Linus agrees rate limiting should be applied on the kernel's side, but that's not a solution somehow here, because reasons.
- Kay says Linus is involved in a "childish power play".
- Linus calls Kay a "primadonna who thinks the world revolves around him".
In short: http://media.giphy.com/media/6HFUDKwlWcAbC/giphy.gif
Wouldn't it be better for the entity writing the messages to prioritize them and select the most relevant so that it doesn't write so many that the system cannot start, rather than let an entity that doesn't know the meaning of the messages arbitrarily discard most of them?
Rate limiting seems a last resort not a proper solution.
The fact that the original flood of messages was as simple bug renders the whole "territorial pissing" thing somewhat more pathetic than it appears at first.
Brutal honesty works with computers, but it's not always the best policy for keeping humans productive. Linus gets away with it because he's a celebrity, and moreover the right kind of celebrity. These comments would look very different if the public mockery was coming from, say, Steve Jobs.
The team itself might be a self-selecting group of people who can work with Linus. But, overall, I'd say that his brutal honesty works "well enough". It might not be a good way to run a corporate project, but for an OS kernel, the benevolent dictator model seems to work pretty well.
I wonder how the kernel groups at Apple and Microsoft work though... or how FreeBSD is organized... that'd be an interesting comparison.
I'd put the core linux system into a situation special enough to make it the correct decision to toss everyone but the best of the best of the linus-compatible developers out. It's not a pretty decision, but after a certain point of importance, I can understand that decision.
It's clear that that the kernel dev guys and Kay have a history. I wonder if Kay would have been more open to accepting change requests to systemd without Linus's bad behaviour. It bears thinking about...
What you have to understand is that these people are not on Linus' payroll, so he has little direct power over them. Screaming at people is one of only two forms of power that Linux can exert, the other being withholding merging of code, which is even more extreme. And these incidents actually come up rather seldom when you think about how much code is submitted to the Linux kernel, which I think is a testament to how well Linus' management is working.
Why is Linus' behavior in response to crap like this bad?
> Kay: "Again, move discussions to the mailing list; this is a bug tracker, but there is no bug to track or fix here."
The fbsd wiki on launchd: https://wiki.freebsd.org/launchd
ulimit -c unlimited
systemd-coredumpctl
But I hated worrying about graphics drivers, updates, xorg.conf, automake, and finagling my system configuration to get source tarballs to compile.
Again, I have the greatest respect for Linus's achievements, but I personally feel that he uses the power those achievements have bought him to be a bully, and that gets no respect from me.
In it, Linus says the following:
> No, we very much expose /proc/cmdline for a reason. System services are supposed to parse it [...] And yes, that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature.
In a way this Sievers guy is right but he could have been more polite in asking the kernel devs for this feature. And he needs to co-operate by cutting down the log traffic until the kernel is fixed.
I mean, it would be nice if the kernel by default could handle a simple forkbomb, but it doesn't without restricting your limits.conf fairly severely. You can blow up the system in a variety of ways that are outside of the kernel's responsibility. It's not up to the kernel devs to hack around your bad behaviour.
While systemd is obviously doing something stupid, no userspace program should be able to dump so much to the log that the machine becomes unusable. It seems like they were going to apply per-file descriptor limiting the way to they seem to limit in kernel logs on a per-log site basis.
BTW Linus agrees rate limiting is desirable here. This is the reason why I said systemd has to hold off its fire hose until the kernel can take care of it.
systemd has apparently elevated itself somewhat above the typical "user space" level, but it's still not a bad idea to harden the interface between systemd and the kernel where possible.