It's weird to see Linus on the other side of being disciplined, and a pretty stark contrast to his own slightly more abrasive style.
For example: https://lkml.org/lkml/2012/12/23/75
For example: https://lkml.org/lkml/2012/12/23/75
I knew that stuff like this goes on in mailing lists; I've grown up in the computer culture. But seeing this as an adult, after learning some people skills and how interpersonal communication works, it's really shocking what to see kind of destructive tone prevails in some prominent tech circles.
But it wasn't "an honest question"; that's the point. It would have been an honest question for you or me, but you and me are not Linux kernel hackers. (At least, I'm not, and I assume you're not.)
Getting a message like this once would lead to a personal e-mail or in-person conversation explaining that this is in no way an acceptable way to communicate with me, followed by a prompt beeline for the exit if it occurred again.
And I expect Linus would be absolutely fine with that, because if you were unable to understand why he was so emphatic about the point he was making, he wouldn't want you hacking on the kernel anyway.
The key thing to recognize is that Linus treats the kernel as what you might call "mission critical" software. Think of it as like, say, the operating code for the Space Shuttle. If someone came along and changed the operating code for the Space Shuttle so that, say, the program that fired the retro-rockets stopped working, and when asked about it, their response was, "well, that looks like a bug in the retro-rocket program", you would not want that person doing that job. And since the retro-rocket code is mission critical, just saying, "no, that's not a good idea" might not get the point across emphatically enough. You might have to use strong language to make sure it is 100 percent understood that breaking the retro-rocket code is unacceptable. In a situation like that, you do not want to leave any room for misinterpretation.
Also, if you look at Linus' posts, you'll notice that he does not always use that strong language. He only uses it when, in his view, it's warranted--meaning, when someone has done something that is so wrong that just saying "that's wrong" won't get the point across strongly enough. That's why we have strong language: for those (hopefully very rare) occasions when no less strong language will do justice to the situation. There are certainly plenty of people in our culture who abuse such language; but looking at Linus' posts as a whole, I'm not sure he's one of them.
I've seen the same tone from crypto hackers, also under the guise of writing "mission critical" software. It's not an excuse. You don't see airline pilots or doctors yelling at each other for making the occaional honest mistake, which happens in every field and can with the correct routines be caught before it causes any damage.
Though, I agree, sometimes there is an excessive amounts of public humiliation on the list.
You're right, you don't. But my point was that you also don't see Linus yelling at other kernel hackers for making honest mistakes. The mistake he yelled at someone for in the case under discussion was not honest; it was a mistake nobody qualified to hack on the kernel should have made in the first place.
Whoa, whoa whoa. I don't know about pilots but speaking as someone whose significant other is in medicine, those people are FIERCE. Yelling, crying, and having massive holier-than-thou outbursts is so common that I'm surprised anyone puts up with it.
I honestly don't see an alternative, even though I would never communicate in such a way.
"It's unacceptable to break userspace. I've fixed the issue personally on this occasion. Look after your area or I'll be forced to find somebody else who can." would suffice
Alan put it well at some point: the way to create working open source software is to minimize the amount of communication needed.
As in, the intention is not to communicate, but to maintain a kernel. If occasional derision of the "shared code reduces bugs" meme is required, Linus will provide it.