9 ms·

Linus will not be merging any code from systemd developer

123 points by mtct 12y ago

0x006A 12y ago
Linus will not be merging any code from Kay Sievers into the kernel until Kay changes his pattern of not fixing problems in code he previously submitted.
- MBCook 12y ago
  Early in the thread Linus explains it: 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 They then went into a rate limiting discussion. Later in the thread it seems to have come up again, leading to the post 0x006A summarized.
estebanrules 12y ago
Seems reasonable to me.
darkarmani 12y ago
Wow. This comment captures it best: > "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."
- shawnz 12y ago
  > Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong. 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.
  - darkarmani 12y ago
    Yes. Linus explains that the kernel will ignore flags it doesn't know for that reason; however, systemd should not be doing anything with the debug flag as that is meant for the kernel. The systemd flag should be namespaced.
    - programmer_dude 12y ago
      I think as always the kernel should be made robust enough (in this case through rate limiting) to handle such abuse. 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.
      - MBCook 12y ago
        If you read through the kernel thread, it seems that's exactly what they're doing. 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.
      - Rantenki 12y ago
        While it would be nice for the kernel to handle any kind of bad behaviour by default, it isn't always realistic. 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.
csmattryder 12y ago
Systemd is soon to be integrated as the default init daemon for Ubuntu, one of the most user-friendly Linux distributions available. 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".
- dredmorbius 12y ago
  And I really, really wish Ubuntu had held out with upstart instead. We need the alternative. 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.
  - akira2501 12y ago
    They're fucking around well beyond PID 1. Default binary log formats. This odd binary messaging bus with god awful reverse domain names, a shifting binary protocol format that injects itself into the kernels standard text-based messaging formats. 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.
    - dredmorbius 12y ago
      Oh, I know. Which again is why I'm as concerned as I am.
    - papaf 12y ago
      They also took over core dumps. ulimit -c unlimited It just fails siliently now. The priesthood have determined that it is better to run: systemd-coredumpctl This annoyed me because if I wanted to do internet searches to achieve simple things I would be using another OS.
userbinator 12y ago
Although I've heard a lot of others disagree, I like the fact that Linus' posts are straight and to the point. No sugar-coating or euphemisms, just telling the hard reality like it is.
- PhasmaFelis 12y ago
  ...Is a good way to turn otherwise-skilled people with some problematic but fixable habits into people who refuse to work with you ever again. 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.
  - tetha 12y ago
    Then again, a hard question is: Do we want developers with problematic habits working on the linux kernel? 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.
  - mbreese 12y ago
    He's been this way long before he was a celebrity coder. This is just how he runs Linux, and I think that is evidence enough that the process works for him. 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.
  - tdsamardzhiev 12y ago
    Read his G+ reply. Why on the Earth would one want to work with that guy anyway?
- 12y ago
duked 12y ago
this links provide a better context on the attitude of the systemd developer: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
e12e 12y ago
Oh, the actual bugzilla thread is (if possible) even more depressing: https://bugs.freedesktop.org/show_bug.cgi?id=76935 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.
- ww520 12y ago
  After reading that, I won't fault Linus in blowing up.
- Workaphobia 12y ago
  Incredible. I was giving him the benefit of the doubt until comment 10.
- nnq 12y ago
  I'm not a Linux expert, but why are other services even allowed the possibility of writing to the kernel log? I seems that this should simply not be possible. If you make it possible, someone will surely abuse it sooner or later.
- na85 12y ago
  Holy shit I always thought the systemd hate was just change-aversion until I read this. Ubuntu probably won't because they're user-hostile, but I really hope Debian and the other major distros move away from systemd.
- beedogs 12y ago
  Jesus. This is what happens when a severely narcissistic prima-donna runs a major project. Shocking and arrogant behavior.
mcescalante 12y ago
For anyone interested in what ensued, Greg KH submitted a patch to systemd to fix this issue. Linus then replied (among some other words) to Greg's confirmation of his patch with: "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."
NotKaySievers 12y ago
I was looking at devkmsg_open() because of Linus's patch, and I noticed that user->prev initialization is missing in that function and a few other places where seq/idx gets reset. 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.
jonalmeida 12y ago
This is quite confusing after reading Sievers' reply on Google+ (third comment on the post) [1] > 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/3cWXzYqB6MB https://plus.google.com/108087225644395745666/posts/3cWXzYqB...
- rwmj 12y ago
  I'm guessing Linus is referring to udev (which is broadly tied to the kernel). For no good reason, udev -- a separate daemon -- was pulled into systemd.
dkarapetyan 12y ago
I don't get why there are so many egos in kernel and low-level development circles. I get that it's a bit more challenging than usual application development but the egos seem way too big relative to what's involved.
- SamReidHughes 12y ago
  The reason is, in the typical contentious low-level development human interaction, one developer is an idiot with insane scrublord opinions, while the other isn't. So the first developer has an inflated ego, and the second doesn't, and people standing on the side who don't have a clue which is which. In this case, we have one who thinks it's reasonable for the debug flag to bring down the system, and the other is a sane reasonable person who's not going to tolerate this crash-the-planet type behavior any more.
- mantrax4 12y ago
  Have you seriously not witnessed an online fight over tabs vs spaces so far? Or braces style? It doesn't matter what it's about. It's just an excuse for this: http://pixdaus.com/files/items/pics/3/23/520323_376f9c805b8bb192612c1f959a5be7b6_large.jpg http://pixdaus.com/files/items/pics/3/23/520323_376f9c805b8b...
mantrax4 12y ago
The nerd fight tl;dr so far: - 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 http://media.giphy.com/media/6HFUDKwlWcAbC/giphy.gif
- sixbrx 12y ago
  "- Linus agrees rate limiting should be applied on the kernel's side, but that's not a solution somehow here, because reasons." 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.
- ZeroGravitas 12y ago
  Good overview, but the kick off was that a simple bug in systemd was flooding the kernel log. Rather than ask for that bug to be fixed (possibly assuming it was intended behaviour) they asked for systemd to ignore a flag that is expressly designed to be read by things other than the kernel. 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.

123 points by mtct 12y ago

Linus will not be merging any code from Kay Sievers into the kernel until Kay changes his pattern of not fixing problems in code he previously submitted.

MBCook 12y ago
Early in the thread Linus explains it: 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 They then went into a rate limiting discussion. Later in the thread it seems to have come up again, leading to the post 0x006A summarized.

estebanrules 12y ago

Seems reasonable to me.

darkarmani 12y ago

Wow. This comment captures it best: > "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."

shawnz 12y ago
> Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong. 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.
- darkarmani 12y ago
  Yes. Linus explains that the kernel will ignore flags it doesn't know for that reason; however, systemd should not be doing anything with the debug flag as that is meant for the kernel. The systemd flag should be namespaced.
  - programmer_dude 12y ago
    I think as always the kernel should be made robust enough (in this case through rate limiting) to handle such abuse. 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.
    - MBCook 12y ago
      If you read through the kernel thread, it seems that's exactly what they're doing. 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.
    - Rantenki 12y ago
      While it would be nice for the kernel to handle any kind of bad behaviour by default, it isn't always realistic. 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.

csmattryder 12y ago

Systemd is soon to be integrated as the default init daemon for Ubuntu, one of the most user-friendly Linux distributions available. 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".

dredmorbius 12y ago
And I really, really wish Ubuntu had held out with upstart instead. We need the alternative. 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.
- akira2501 12y ago
  They're fucking around well beyond PID 1. Default binary log formats. This odd binary messaging bus with god awful reverse domain names, a shifting binary protocol format that injects itself into the kernels standard text-based messaging formats. 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.
  - dredmorbius 12y ago
    Oh, I know. Which again is why I'm as concerned as I am.
  - papaf 12y ago
    They also took over core dumps. ulimit -c unlimited It just fails siliently now. The priesthood have determined that it is better to run: systemd-coredumpctl This annoyed me because if I wanted to do internet searches to achieve simple things I would be using another OS.

userbinator 12y ago

Although I've heard a lot of others disagree, I like the fact that Linus' posts are straight and to the point. No sugar-coating or euphemisms, just telling the hard reality like it is.

PhasmaFelis 12y ago
...Is a good way to turn otherwise-skilled people with some problematic but fixable habits into people who refuse to work with you ever again. 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.
- tetha 12y ago
  Then again, a hard question is: Do we want developers with problematic habits working on the linux kernel? 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.
- mbreese 12y ago
  He's been this way long before he was a celebrity coder. This is just how he runs Linux, and I think that is evidence enough that the process works for him. 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.
- tdsamardzhiev 12y ago
  Read his G+ reply. Why on the Earth would one want to work with that guy anyway?
12y ago

duked 12y ago

this links provide a better context on the attitude of the systemd developer: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935

e12e 12y ago

Oh, the actual bugzilla thread is (if possible) even more depressing: https://bugs.freedesktop.org/show_bug.cgi?id=76935 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.

ww520 12y ago
After reading that, I won't fault Linus in blowing up.
Workaphobia 12y ago
Incredible. I was giving him the benefit of the doubt until comment 10.
nnq 12y ago
I'm not a Linux expert, but why are other services even allowed the possibility of writing to the kernel log? I seems that this should simply not be possible. If you make it possible, someone will surely abuse it sooner or later.
na85 12y ago
Holy shit I always thought the systemd hate was just change-aversion until I read this. Ubuntu probably won't because they're user-hostile, but I really hope Debian and the other major distros move away from systemd.
beedogs 12y ago
Jesus. This is what happens when a severely narcissistic prima-donna runs a major project. Shocking and arrogant behavior.

mcescalante 12y ago

For anyone interested in what ensued, Greg KH submitted a patch to systemd to fix this issue. Linus then replied (among some other words) to Greg's confirmation of his patch with: "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."

NotKaySievers 12y ago

I was looking at devkmsg_open() because of Linus's patch, and I noticed that user->prev initialization is missing in that function and a few other places where seq/idx gets reset. 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.

jonalmeida 12y ago

This is quite confusing after reading Sievers' reply on Google+ (third comment on the post) [1] > 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/3cWXzYqB6MB https://plus.google.com/108087225644395745666/posts/3cWXzYqB...

rwmj 12y ago
I'm guessing Linus is referring to udev (which is broadly tied to the kernel). For no good reason, udev -- a separate daemon -- was pulled into systemd.

dkarapetyan 12y ago

I don't get why there are so many egos in kernel and low-level development circles. I get that it's a bit more challenging than usual application development but the egos seem way too big relative to what's involved.

SamReidHughes 12y ago
The reason is, in the typical contentious low-level development human interaction, one developer is an idiot with insane scrublord opinions, while the other isn't. So the first developer has an inflated ego, and the second doesn't, and people standing on the side who don't have a clue which is which. In this case, we have one who thinks it's reasonable for the debug flag to bring down the system, and the other is a sane reasonable person who's not going to tolerate this crash-the-planet type behavior any more.
mantrax4 12y ago
Have you seriously not witnessed an online fight over tabs vs spaces so far? Or braces style? It doesn't matter what it's about. It's just an excuse for this: http://pixdaus.com/files/items/pics/3/23/520323_376f9c805b8bb192612c1f959a5be7b6_large.jpg http://pixdaus.com/files/items/pics/3/23/520323_376f9c805b8b...

mantrax4 12y ago

The nerd fight tl;dr so far: - 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 http://media.giphy.com/media/6HFUDKwlWcAbC/giphy.gif

sixbrx 12y ago
"- Linus agrees rate limiting should be applied on the kernel's side, but that's not a solution somehow here, because reasons." 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.
ZeroGravitas 12y ago
Good overview, but the kick off was that a simple bug in systemd was flooding the kernel log. Rather than ask for that bug to be fixed (possibly assuming it was intended behaviour) they asked for systemd to ignore a flag that is expressly designed to be read by things other than the kernel. 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.