Linus Chews Up Kernel Maintainer For Introducing Userspace Bug
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.
...a better love story than Twilight.
Winning friends and influencing people since 1983.
Seriously, who'd put up with this crap? There are nicer ways to make ones way through life.
This is somewhat related with this Linus' post on G+?
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
It's just a kernel patch, nothing to be actually "angry" about. Why so emotional? And especially when it's somebody who is not an employee.
Just say, "It is our firm policy that we do not break XXX, even when any given developer wishes they could. If you wish to continue contributing, you must follow the policy. Please apply the fix ASAP and acknowledge your understanding of these conditions."
It wasn't really the bug that set Linus off. At least not in my reading of the post. It was Mauro's cavalier attitude toward the bug. He tried to shrug it off as a problem with pulseaudio, when it clearly was a bug that he had introduced.
I'm not a big fan of this style of management, but I can't fault any of the content of Linus' rant.
Lemmings are silly; dinosaurs are extinct.
Seriously, someone makes a coding mistake in a pre-release kernel, there's a heated e-mail chain about it, and now it's on /. Why?
I have a "chain of clients" theory of system design.
The kernel developers protect the library developers from having to deal with the hardware.
The library developers protect the applications developers from having to deal with the kernel.
The applications developers protect the users from having to deal with all of the above.
Everyone has shit to deal with, but if you break the chain and let some of your shit spill into another layer, then someone else has to deal with way more shit than they can reasonably be expected to handle.
I am so tempted to kiss the guy! Linux can't have this type of _OBVIOUS_ audio sabotage at the kernel level if we expect game developers to ever make their products available on Linux. Linus NEEDS to reign this in, we just can't afford it. He is 110% right.
Keep the helm firm, man! That's exactly what we need!
Qybix
Qybix ----- I do not have a belief system; I'm an Anti-theist and proud of it! Saying that not believing in anything i
There are some people who you could site down with and explain things for two hours and they would still go away and do their own thing. IT is particularly full of people like this (and I'm aware of and try to avoid my own inclinations in this direction). Sometimes, you just have to make it clear that something is important and that means raising the temperature even as (and especially as) you remain in control internally.
This is also a valuable parenting skill. I don't think that that's entirely coincidental.
I wouldn't speak to anyone that way unless I never wanted to see them again. Shaming someone in public like this is a way to not only get them to quit, but to make a permanent enemy out of them.
What this tells me is that Linus is better suited to be a cult leader than a manager of any kind.
To be honest, I wish it happened more.
I _wish_ management where I am cared about quality at this level. It would be worth getting chewed out once in a while to know that stupid bugs are not tolerated.
News for Nerds, Stuff that Matters! Thanks Slashdot! Its been a while...
Nobodies Prefect
Tidbits for Techs Technology Blog
Sometimes shit happens. Sorry for that.
Cheers,
Mauro
Wrong. Answer.
If the only way you can accept an assertion is by faith, then you are conceding that it can't be taken on its own merits
For example:
Ita erat quando hic adveni.
Infrequently. I've seen somebody get hit that hard a handful of times in 20 years. I've had to do it myself twice. (There have been other lower-level chastisements.) Once I was the point man for a major reaming of a contractor that had been deceiving us for months about multiple issues. The other time was a guy that had been concealing his lack of progress on a project I was directing.
When somebody has engaged in completely unacceptable behavior, it's absolutely necessary to do at least one of two things: (1) get them off your project or (2) otherwise make them understand why such behavior cannot be tolerated. The latter is only an option if you believe the person is able and can be convinced to learn from their mistakes.
Doing it by email is a mistake and Linus can be criticized for that and, IMO, that alone. This is the kind of conversation you have face to face if you can and by phone if you can't.
The guy deals with A LOT of bullshit on a daily basis, and this was a BS patch anyway. That would be the end of it if the dude didn't start coming up with excuses. If you know you're wrong, fucking say so and make things right.
Bottom line, Linus has been in charge of the kernel for a couple of decades now, and his process is working. He doesn't flip out very often, so when he does, every who counts knows that some serious fuckups happened. And anyone who doesn't count (which in this case, almost certainly includes both you and me) can probably go fuck themselves if they don't like it.
Nobody in the world knows for sure how to manage a project like Linux. It is truly unprecedented. But Linus's way is working better than anyone would have expected two decades ago. If you want to second-guess him, feel free to start your own competing project and manage it your way. His way is working better than anything anyone else has ever tried, even if it's not "the best way".
Take a look at the call for which ENOENT was returned. The API spec says "EINVAL: The struct v4l2_queryctrl id is invalid. The struct v4l2_querymenu id is invalid or index is out of range (less than minimum or greater than maximum) or this particular menu item is not supported by the driver."
This is from a generic driver mechanism for USB camera-like devices. Because such devices aren't as standard as they should be, there's an insane number of options and possible errors. The spec says to return EINVAL for both incorrect calls and calls for which the device does not support the requested item.
The problem here is that the EINVAL error status doesn't distinguish between "program made bad call and is broken" and "we're iterating through the device functions to discover which ones are available, and this ID isn't meaningful on this device so skip it" EINVAL is supposed to mean "One or more of the ioctl parameters are invalid or out of the allowed range." A correctly made call should not return EINVAL.
The alternatives are limited, though. This is related to a historical Linux design problem, which comes from a historical UNIX problem - system call errors are reported using one error code, chosen from a short list written in the 1970s. "ENOENT" isn't really appropriate. "ENOTTY" ("The ioctl is not supported by the driver"), might be appropriate, except that the usual message for that is "Not a typewriter".
The API is a rather lame and excessively complex way to return what is merely a variable-length list of fixed-format structures. One would think that Linux would by now have a generic way to do that, since it comes up in other contexts.
Here's an example of an application which seems to be crashing because the programmer did not understand the nonstandard semantics of EINVAL in this API.
...and then it makes Linux as an operating system -- and everything that runs on it and depends on it, look bad...
While I agree that this incident does put Linux on the front pages in part of the Net, I seriously doubt the "look bad" part.
In fact, imho, this incident will generate more positive than negative for Linux.
Admins and users that are still sitting on the fence would take note, that Linus just don't take fuck as an excuse - and if anyone dares to fuck up like that fella he will get a public tongue lashing - and the top priority of Linux is to *NOT INTRODUCE ANY USERSPACE BUG*.
Muchas Gracias, Señor Edward Snowden !