Linus Chews Up Kernel Maintainer For Introducing Userspace Bug 1051
An anonymous reader points out just how thick a skin it takes to be a kernel developer sometimes, linking to a chain of emails on the Linux Kernel Mailing List in which Linus lets loose on a kernel developer for introducing a change that breaks userspace apps (in this case, PulseAudio). "Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious garbage and idiocy from a kernel maintainer again. Seriously. I'd wait for Rafael's patch to go through you, but I have another error report in my mailbox of all KDE media applications being broken
by v3.8-rc1, and I bet it's the same kernel bug. And you've shown
yourself to not be competent in this issue, so I'll apply it directly
and immediately myself. WE DO NOT BREAK USERSPACE! Seriously. How hard is this rule to understand? We particularly don't
break user space with TOTAL CRAP. I'm angry, because your whole email
was so _horribly_ wrong, and the patch that broke things was so
obviously crap. ... 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," writes Linus, and that's just the part we can print. Maybe it's a good thing, but there's certainly no handholding when it comes to changes to the heart of Linux.
if only more technical leads had this mindset (Score:3, Informative)
yes it is brutal this email thread is in the public. but the mindset linus has about the process is what separates the really good teams for the everyday teams. i had the opportunity to work on three different commercial unix operating system teams and this mindset is consistent with the teams that hit schedule with the appropriate quality.
Not the bug... (Score:5, Informative)
I'm not a big fan of this style of management, but I can't fault any of the content of Linus' rant.
Re:I wonder (Score:2, Informative)
This is Linux, not the GNU Movement.
Re:Not the bug... (Score:5, Informative)
No. He clearly stated that he saw this, "at first glance," as something that Pulseaudio had been doing all along. The patch made a function not only return a different error code, but an error code that was never possible before the patch. The change was not documented, at all.
The submitter really set him up, though. If you look further up in the thread, the "rollback" was a simple one line change from ret = -ENOENT; to ret = -ENVAL;. I'm fairly certain that it was just overlooked in the code review for the entire patch.
What got him was that instead of going back and saying, "Huh. Why did we change this error code? Oh my, ENOENT was never even possible before this. This'll break all sorts of crap!" he blamed Pulseaudio. That's a serious no-no that's been covered several times in the history of the kernel.
Re:Arsehole (Score:5, Informative)
true, an application in theory COULD be prepared to respond to all potential errors, as long as you don't mind a 200 megabyte binary for hello world
Re:Linus is an asshat, imho (Score:5, Informative)
For example:
Re:Arsehole (Score:4, Informative)
I would happily put up with that and more just for the credit of being one of the select few who get to work on the kernel.
It's not that hard, go find some hardware that isn't supported yet (or even that's not supported very well, like a lot of sound cards), and start writing drivers. If your code is decent, it will be accepted.
whiny mauro (Score:4, Informative)
An anonymous reader points out just how thick a skin it takes to be a kernel developer sometimes...
Mauro points out just how thick a skin it takes to be a kernel developer sometimes...there FTFY
Re:Arsehole (Score:5, Informative)
That's one hell of a good excuse for some of the brain-damages of minix. I can only hope (and assume) that Amoeba doesn't suck like minix does.
Nope, that was when he was still in Finland. Not a cultural thing, apparently.
Re:Arsehole (Score:5, Informative)
Linus hates ethnic minorities. He sees daily what they are doing to his beloved homeland and regrets that he has to work with them.
Don't feed the trolls, they say. But in this case, there may be a few readers here that don't know that Linus Torvalds belongs to an ethnic minority of Finland - the Swedish speaking minority [wikipedia.org] who are not always well accepted in either Finland or Sweden.
And, of course, that after moving to the US, he's still in an ethnic minority. Perhaps even more so.
Re:not good management technique (Score:5, Informative)
It's not like he wrote a patch with a changelog of "Break sound. Users have had functional audio capability for far too long."
It was a bug in the patch which broke the kernel interface (by returning different error codes), which was not the intended effect of the patch. Laurent Pinchart, the author of the patch, explained in the thread:
The reason Mauro Chehab got chewed out was because he refused to acknowledge that it was a kernel bug, didn't see anything wrong with a sudden change in the kernel return value, and then proceeded to blame pulseaudio for not handling it. That's why, other than his patch being called "total and utter CRAP" and "incredibly broken shit", Laurent was not mentioned in the email, whereas Mauro was told to shut up and called out as flat out incompetent.
Re:Be fair (Score:2, Informative)
uh, read what the guy wrote? He said yeah, it was a mistake and then goes on to explain what happened and what he was trying to do.
Re:Arsehole (Score:5, Informative)
And getting code accepted != kernel maintainer.
This guy (Mauro) is trusted to make commits to the kernel without direct hard core review by Linus. If I make a code change to V4L and it gets accepted to the kernel, it goes through Mauro, not Linus.
Theres a big difference between me committing code and me being a reviewer who is trusted to know what I'm doing rather than just some code monkey that someone else checks out first.
Re:Linus is wrong, and an asshole (Score:2, Informative)
You're wrong, and Linus already explained why.
Returning 'file not found' on an already open file is in no way acceptable. Ever.
Then blaming it on the software for not dealing with an error code it should never get is unacceptable.
Blaming the software for breaking when the kernel change caused the failure and the policy of the Linux project is that any kernel change that breaks userland code is a kernel bug is unacceptable.
Making a change from ANY API, kernel or otherwise that changes error codes for a response with ZERO documentation is ENTIRELY unacceptable.
Congratulations, you utterly fail to understand how to write interfaces (code or otherwise) in multiple ways and fail to understand how to comprehend the problem as well.
Comment removed (Score:4, Informative)
Re:Still.... (Score:5, Informative)
This sounds so gimp like. Like a teen at school trying to get in with the popular set. Or Dobby from Harry Potter.
It's just pragmatism. For every programmer competent to work on the kernel there are a thousand wannabes, so some vetting process is required. In companies, this is done via resumes and interviews -- and then generally by giving new software engineers projects of low importance so you can vet their work before trusting them with stuff that could break the business. Same thing, just a different context.
Re:It'll make Linux better (Score:4, Informative)
You clearly don't have knowledge of Linux Kernel development circa 2013. Here is something you should know [apcmag.com] written way back in January 2010. Furthermore, you don't seem to understand, as I already said, what "good people" means. Linus only wants to work with "good people", which is why he will tell you to go fsck yourself if you aren't one of them and refuse to get a clue, which is clearly what we have seen here. You have read a single post, out of context, and formed a conclusion that the guy is a poor innocent bastard who did nothing wrong (or little wrong) and had his ass handed to him. You might want to peruse the entire LKML paying attention to the relative posts for the whole story before you form an opinion.