4 ms·

Linus on kernel changes breaking user programs (from 2012/12/23)

76 points by w1ntermute 14y ago

gbaygon 14y ago
Previous discussion: http://news.ycombinator.com/item?id=4962912 http://news.ycombinator.com/item?id=4962912
sergiotapia 14y ago
Harsh, so god damn harsh! Then again, I can't fathom how Linus must feel getting hundreds of pull requests that are plain wrong and/or stupid.
spdy 14y ago
He is right. If you are part of the linux kernel team you know what you got yourself into (Linus) and you are part of one of the highest profile opensource projects on this planet. For are project like the kernel this is an appropriate response to eliminate errors. If they f..up on the development, alot of server will break all over the planet and many companies will get angry emails from people who have no clue why they cant upload pictures of their kitten. The fact that you then try to make excuses for breaking user space, and blaming some external program that used to work, is just shameful. It's not how we work. Most people would get some similiar response if you would do this on a clients project.
Ideka 14y ago
Have you seen Mauro's response? I think he took it like a champ. https://lkml.org/lkml/2012/12/23/87 https://lkml.org/lkml/2012/12/23/87
- Arelius 14y ago
  Once you follow it all the way through, it seems to be a much more involved issue: https://lkml.org/lkml/2012/12/24/125 https://lkml.org/lkml/2012/12/24/125
xfax 14y ago
Mauro's response shows incredible restraint. I commend him for that. Linus could have easily written that email privately to Mauro and spared him the public shaming. He could have then written a stern yet civil public response. Would that be asking too much? It doesn't matter who you are; basic human decency is not above you.
- gizmo686 14y ago
  The kernel mailing list is by desision public, and Linus's email was part of an already public thread. We can dissagree with what he wrote, but I do not think he had a good option of writing it in private.
- erikpukinskis 14y ago
  I've never worked at Microsoft, but I'm pretty sure Bill Gates and Steve Jobs sent messages like that to working groups, and even department lists. I have no idea whether it's right or wrong, but I don't think this kind of thing is atypical for big tech projects. Linux just happens to be open source, so when it happens in Linux you hear about it.
  - ryguytilidie 14y ago
    All this argument seems to do is solidify the idea that engineers would be well served to work on their ability to interact with others. It doesn't make screaming and swearing at your peers okay because Bill Gates or Steve Jobs does it, as much as everyone would like to think so.
  - hvs 14y ago
    It's wrong. Common sense should tell you that it is wrong.
jacquesm 14y ago
Two things: this should not have been the public chewing out that it was, Mauro obviously didn't do any of this on purpose and getting scolded like this privately would have been plenty, heck the guy probably berates himself a lot more effectively than this message could. Second: the buck stops at the top. Testing procedures should have caught the bug long before being seen in the wild so apparently linux still has some catching up to do there and that's a lesson that Linus should be learning here rather than to dump on the developer that caused the bug that wasn't caught in testing. Process really does matter in cases like this. The problem is not that it happened, the question is how to make sure it never happens again. Maybe Linus was wearing his 'do I look like a people person to you?' t-shirt.
- mekoka 14y ago
  Second: the buck stops at the top. Testing procedures should have caught the bug long before being seen in the wild so apparently linux still has some catching up to do there and that's a lesson that Linus should be learning here rather than to dump on the developer that caused the bug that wasn't caught in testing The buck may stop at the top, but if Linus takes the public blame and picks it up, he then has to put his house in order, wouldn't you agree that's what we're seeing here? Yes, testing procedures should've, would've, etc, but that's exactly why these kernel maintainers are there for. As far as Linux having some catching up to do, how often does this situation occur? I also believe the most valuable lesson to learn here is the one you can do nothing about: no matter how adamant you are about your dearest and most basic rules (we've heard Linus many times on code that break user-space), shit happens. His frustration appears to stem from (rightful) presumptions that a kernel developer would not make such newbie mistakes. I totally agree with you that this exchange should not have been so public, unfortunately kernel communication is by design. I would, however, also like to provide a different perspective. Linus is carrying the burden of being a bully, he does a dirty job of publicly berating people from whom he expects nothing but the best, everything about his handling of these situations shakes our moral fibre and makes him appear a dis-likable human being. But then, we're millions to enjoy the fruit of this dirty job everyday, blinding ourselves to what it takes to provide it. Such is often the burden of leaders.
  - 14y ago
looser 14y ago
Using some logic here: 1 - It seems Mauro added a new error message called ENOENT; 2 - After this change, Mauro noticed an error at pulseaudio; 3 - Linus says that always the userspace is right and kernel space is wrong in those cases and simply discarded Mauro's argument; But thinking about this I think Mauro is not entirely wrong. Mauro's question makes a lot of sense to me: Why pulseaudio failed after just a new error code was added to the kernel? Can't it be that pulseaudio is doing some wrong treatment that is ignoring the possibility of a new (or non-existent) error code?
- deleted 14y ago
  [deleted]
- tmhedberg 14y ago
  ENOENT isn't a new error code. It's the standard errno value that indicates an attempt to access a nonexistent file or directory on all POSIX platforms. The problem is that it was being misappropriated in a nonsensical way, returned by an ioctl call. ioctl can only be called on already-open file descriptors, so it makes no sense for it to complain that the file doesn't exist. If the file pointed to by the file descriptor didn't exist, the file descriptor wouldn't have been able to be opened in the first place (errno would have been set to ENOENT by the call to open).
  - looser 14y ago
    Ah! So Linus argument makes sense indeed. No need to test if the file exists in a process that assumes it is already opened... Thanks for clearing that up.
  - ziffusion 14y ago
    What if an ioctl is trying to indicate that a certain "entry" is not valid or available? Like when it is returning a cached entry or dealing with some container, where a notion of an entry does make sense. Insisting that ENOENT is reserved for path operations seems asinine.
    - tmhedberg 14y ago
irollboozers 14y ago
This is awesome. I would entirely freaking love to be chewed out like that. I feel like this is what it feels like to be set back on the right track by folks like a young and tempestuous Steve Jobs, Bill Gates, etc. Sure he's cranky, but even through his crankiness you can tell he is fundamentally right. DHH needs to swear more.
dgottlieb 14y ago
The original patch/commit that Linus calls out: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f0ed2ce840b3 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...
- cjensen 14y ago
  Whoa. That should have set off alarm bells when being reviewed. Changing errno return values just because? And a counter-change in another place to put the changed errno back to the original. I'd accept that from an intern. Any grown-up that did it would get a talking to, though not in public.
sparx 14y ago
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560 broken kernel could fuck up a lot lof users.I am suffering from this broken kernel, and I do appreciate what Linus is doing.
jasonkostempski 14y ago
Why self-censor 'f*cking' but not 'FUCK'? Consistency please.
zem 14y ago
I've been defending Linus over this, but on second thoughts I think he crossed the line here: > And you've shown yourself to not be competent in this issue, so I'll apply it directly and immediately myself. I'm rather surprised at him; he's been pretty abrasive before, but seldom directly abusive like this.
vacri 14y ago
Torvalds swears in kernel chat, unrelated devs frown sternly, sun rises in the east, tides happen twice a day...
epynonymous 14y ago
this is awesome, communication should be open (as in public) and candid. i'm not saying that i enjoy the approach, but there's much truth to linus' rant, that was a shit commit.
deleted 14y ago
[deleted]

76 points by w1ntermute 14y ago

Previous discussion: http://news.ycombinator.com/item?id=4962912 http://news.ycombinator.com/item?id=4962912

Harsh, so god damn harsh! Then again, I can't fathom how Linus must feel getting hundreds of pull requests that are plain wrong and/or stupid.

spdy 14y ago

He is right. If you are part of the linux kernel team you know what you got yourself into (Linus) and you are part of one of the highest profile opensource projects on this planet. For are project like the kernel this is an appropriate response to eliminate errors. If they f..up on the development, alot of server will break all over the planet and many companies will get angry emails from people who have no clue why they cant upload pictures of their kitten. The fact that you then try to make excuses for breaking user space, and blaming some external program that used to work, is just shameful. It's not how we work. Most people would get some similiar response if you would do this on a clients project.

Ideka 14y ago

Have you seen Mauro's response? I think he took it like a champ. https://lkml.org/lkml/2012/12/23/87 https://lkml.org/lkml/2012/12/23/87

Arelius 14y ago
Once you follow it all the way through, it seems to be a much more involved issue: https://lkml.org/lkml/2012/12/24/125 https://lkml.org/lkml/2012/12/24/125

xfax 14y ago

Mauro's response shows incredible restraint. I commend him for that. Linus could have easily written that email privately to Mauro and spared him the public shaming. He could have then written a stern yet civil public response. Would that be asking too much? It doesn't matter who you are; basic human decency is not above you.

gizmo686 14y ago
The kernel mailing list is by desision public, and Linus's email was part of an already public thread. We can dissagree with what he wrote, but I do not think he had a good option of writing it in private.
erikpukinskis 14y ago
I've never worked at Microsoft, but I'm pretty sure Bill Gates and Steve Jobs sent messages like that to working groups, and even department lists. I have no idea whether it's right or wrong, but I don't think this kind of thing is atypical for big tech projects. Linux just happens to be open source, so when it happens in Linux you hear about it.
- ryguytilidie 14y ago
  All this argument seems to do is solidify the idea that engineers would be well served to work on their ability to interact with others. It doesn't make screaming and swearing at your peers okay because Bill Gates or Steve Jobs does it, as much as everyone would like to think so.
- hvs 14y ago
  It's wrong. Common sense should tell you that it is wrong.

jacquesm 14y ago

Two things: this should not have been the public chewing out that it was, Mauro obviously didn't do any of this on purpose and getting scolded like this privately would have been plenty, heck the guy probably berates himself a lot more effectively than this message could. Second: the buck stops at the top. Testing procedures should have caught the bug long before being seen in the wild so apparently linux still has some catching up to do there and that's a lesson that Linus should be learning here rather than to dump on the developer that caused the bug that wasn't caught in testing. Process really does matter in cases like this. The problem is not that it happened, the question is how to make sure it never happens again. Maybe Linus was wearing his 'do I look like a people person to you?' t-shirt.

mekoka 14y ago
Second: the buck stops at the top. Testing procedures should have caught the bug long before being seen in the wild so apparently linux still has some catching up to do there and that's a lesson that Linus should be learning here rather than to dump on the developer that caused the bug that wasn't caught in testing The buck may stop at the top, but if Linus takes the public blame and picks it up, he then has to put his house in order, wouldn't you agree that's what we're seeing here? Yes, testing procedures should've, would've, etc, but that's exactly why these kernel maintainers are there for. As far as Linux having some catching up to do, how often does this situation occur? I also believe the most valuable lesson to learn here is the one you can do nothing about: no matter how adamant you are about your dearest and most basic rules (we've heard Linus many times on code that break user-space), shit happens. His frustration appears to stem from (rightful) presumptions that a kernel developer would not make such newbie mistakes. I totally agree with you that this exchange should not have been so public, unfortunately kernel communication is by design. I would, however, also like to provide a different perspective. Linus is carrying the burden of being a bully, he does a dirty job of publicly berating people from whom he expects nothing but the best, everything about his handling of these situations shakes our moral fibre and makes him appear a dis-likable human being. But then, we're millions to enjoy the fruit of this dirty job everyday, blinding ourselves to what it takes to provide it. Such is often the burden of leaders.
- 14y ago

looser 14y ago

Using some logic here: 1 - It seems Mauro added a new error message called ENOENT; 2 - After this change, Mauro noticed an error at pulseaudio; 3 - Linus says that always the userspace is right and kernel space is wrong in those cases and simply discarded Mauro's argument; But thinking about this I think Mauro is not entirely wrong. Mauro's question makes a lot of sense to me: Why pulseaudio failed after just a new error code was added to the kernel? Can't it be that pulseaudio is doing some wrong treatment that is ignoring the possibility of a new (or non-existent) error code?

deleted 14y ago
[deleted]
tmhedberg 14y ago
ENOENT isn't a new error code. It's the standard errno value that indicates an attempt to access a nonexistent file or directory on all POSIX platforms. The problem is that it was being misappropriated in a nonsensical way, returned by an ioctl call. ioctl can only be called on already-open file descriptors, so it makes no sense for it to complain that the file doesn't exist. If the file pointed to by the file descriptor didn't exist, the file descriptor wouldn't have been able to be opened in the first place (errno would have been set to ENOENT by the call to open).
- looser 14y ago
  Ah! So Linus argument makes sense indeed. No need to test if the file exists in a process that assumes it is already opened... Thanks for clearing that up.
- ziffusion 14y ago
  What if an ioctl is trying to indicate that a certain "entry" is not valid or available? Like when it is returning a cached entry or dealing with some container, where a notion of an entry does make sense. Insisting that ENOENT is reserved for path operations seems asinine.
  - tmhedberg 14y ago

irollboozers 14y ago

This is awesome. I would entirely freaking love to be chewed out like that. I feel like this is what it feels like to be set back on the right track by folks like a young and tempestuous Steve Jobs, Bill Gates, etc. Sure he's cranky, but even through his crankiness you can tell he is fundamentally right. DHH needs to swear more.

dgottlieb 14y ago

The original patch/commit that Linus calls out: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f0ed2ce840b3 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...

cjensen 14y ago
Whoa. That should have set off alarm bells when being reviewed. Changing errno return values just because? And a counter-change in another place to put the changed errno back to the original. I'd accept that from an intern. Any grown-up that did it would get a talking to, though not in public.

sparx 14y ago

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560 broken kernel could fuck up a lot lof users.I am suffering from this broken kernel, and I do appreciate what Linus is doing.

jasonkostempski 14y ago

Why self-censor 'f*cking' but not 'FUCK'? Consistency please.

zem 14y ago

I've been defending Linus over this, but on second thoughts I think he crossed the line here: > And you've shown yourself to not be competent in this issue, so I'll apply it directly and immediately myself. I'm rather surprised at him; he's been pretty abrasive before, but seldom directly abusive like this.

vacri 14y ago

Torvalds swears in kernel chat, unrelated devs frown sternly, sun rises in the east, tides happen twice a day...

epynonymous 14y ago

this is awesome, communication should be open (as in public) and candid. i'm not saying that i enjoy the approach, but there's much truth to linus' rant, that was a shit commit.

deleted 14y ago

[deleted]