The worst part wasn’t Linus rejecting the patch (rightly imho), but him dismissing RT as a small enthusiast’s project. There’s a huge industry depending on this. Like industrial control’s, etc.
For context, here is the rebase of the RT patch set on top of the current Linux release.
The list used to be much much longer. A lot of work is already in the mainline. It remains
- printk
- scheduler
- small fry / driver fixes
Though RT will require constant “gardening” also after being fully mainlined. There’s an ongoing push to educate kernel devs how to not break RT in the future.
> End result: no way will I accept this kind of completely arbitrary and
frankly not very intelligent patch.
> If people want to disable console printing, that's THEIR CHOICE. It
could be a new config variable where you ASK people about what they
want. Not this kind of idiotic tying together of things.
I thought Linus had committed to changing how he behaves in public forums? Even if he didn't like the patch, calling it "unintelligent" and "idiotic" doesn't accomplish anything. He could have just left the rest of the comments in there without using inflammatory language and it would have the same affect.
Overall I believe his language has gotten better. Yes it's still a bit abrasive but he's also not directly calling people themselves an idiot, which is a big improvement.
Reading through the whole PR comment, you see that this is a repeating pattern in the printk system:
> And guys, I want to make it really clear how disappointed I am with
> the printk tree lately. There seems to be some kind of hardline
> religious fervor having taken over to make these kinds of "this is how
> it has to be done, screw any sanity or common sense".
As an end user who recently used printk with PREEMPT_RT to debug a driver, I appreciate Torvald's insistence here.
> Even if he didn't like the patch, calling it "unintelligent" and "idiotic" doesn't accomplish anything.
Perhaps not, or perhaps it's an effective way to snap people out of a "religious fervor". As a developer I'd be upset at having my code called "idiotic", but would generally prefer it over someone thinking the code is idiotic but not saying it and getting stonewalled or hiding behind corporate doublespeak.
If I can do it, he can do it. Someone as clever as him could write a filter/plugin if nothing else to flag messages with too many curse words and personal attacks.
Not much of a difference if it was directed at a patch or person - calling someone's end-work idiotic and unintelligent is basically saying the same of it's creator...
It might be better than previous language, but it's still crass and abusive on some level.
> Not much of a difference if it was directed at a patch or person - calling someone's end-work idiotic and unintelligent is basically saying the same of it's creator...
No? I’d like to think I’m not, generally speaking, that stupid, but I’ve certainly made profoundly stupid decisions, and I sure hope I’m not as much of an idiot as the most idiotic code I’ve ever written.
The hard boundary between criticism and personal attack, for me, lies precisely between saying someone’s work is unacceptable because they’re stupid and saying that work is unacceptable because it itself is stupid.
I can’t say it doesn’t matter at all who I’m speaking to. Most sharply, I’ve interacted with a person who regularly seemed wrong in simple ways when I was speaking to them, then several hours afterwards I realized their reasoning might not have been as careful as I’d have liked but is still most probably sound. A more generally applicable point is that I’m not going to let myself go all the way to loudly pointing to things on the blackboard when I’m teaching an introductory maths course, even though there definitely are people with whom I’ve interacted in that manner and walked away smarter for the experience. But at the end of the day, either I think you’re right or I don’t.
So if you think my code is idiotic, bloody well say so. It’s going to hurt a bit, but less than if I have to discover that over several polite-language roundtrips, or worse, through polite silence. You can’t make learning not hurt at all, better just get it over with.
If you read the thread on the mailing list, the maintainer of the branch took it as constructive criticism and FWIW the followup of Linus didn't use any insulting phrases.
It wasn't apparently the first blunder on their part (even though it was somebody else who programmed it this way)
I think he has a major point though, he says this[0], if a desktop user or kernel dev tries RT how exactly are they going to use their system? I don't think I could even boot my system with no console output.
[0]:
For all we know, there may be random users who are playing around with
PREEMPT_RT. They don't have to, but they want to.
Just saying "you get no console because you wanted to try it out" is
simply not acceptable.
There is nothing wrong with rejecting the patch... there is something definitely wrong with calling it "unintelligent" and "idiotic". Esp since a year or two ago Linus publicly committed to toning down some of his more toxic behavior.
I think it's important to take context in mind here - this isn't how linus responds to every suboptimal patch. If you already say "this patch is bad" for many patches with average levels of bad, repeating that same thing for something which in Linus's mind is likely many magnitudes worse is gonna lose very important information!
(an alternative would be scaling back the severity of all negative speech, but then you'd drastically reduce the range of dislike showable for the much more frequent less severe cases; I do think Linus here might have gone too hard here, but don't think it's too far off what could be considered appropriate)
I reject PRs every day at work with varying level of "badness" and it works just fine. Normal people can put 20 seconds of thought and come up with a response that explains why a patch is unacceptable without resorting to name calling, even in this PR response Linus does that for the most part but in the end just can't help himself from throwing in a couple of petty jabs. There are other open source communities where this behavior would be unacceptable (for example the GoLang core team).
I am calling this out because Linus specifically said that he wants to handle himself better in public, he is aware of how he comes across and wants to change, it is not an RMS type situation where the guy has no self-awareness. Reading the rest of the thread I bet he regretted his response esp considering the response of the branch maintainer.
If your speech can range from -127 to 128 (positive to negative) and you intentionally restrict yourself to a subset thereof, you lose some of the expressive ability.
I think that is so firmly built in it will never change. I don't think he believes that email dev lists should be a safe space. I think for quite a while he curtailed it over the hubub over those social responsibility clauses or whatever that all the big open source groups were committing to a few years back when safe spaces and controlled dialogue to prevent hurt feelings were all the rage.
When the greybeards go, I'll probably moved to OpenBSD. I don't want to sell their development skills short, but I have less faith in the generation of devs replacing them. They have learned seemingly a small amount of fundamentals from their predecessors, as indicated by continuous bloat and inefficiency in the name of 'thats just how we do things now', in a derisive tone of 'get with the times', often ignoring the sacrifices being made in the process for often marginal gain.
The bellwether for me was when logs became binary blobs rather than plaintext.
They aren't right just because they're old. I could easily write the opposite comment:
I don't want to sell the greybeards' skills short, but I have less faith in them than the new generation (the most skilled part of the new generation; don't ignore sampling bias). The new generation has learnt the lessons of the old and improved on them, whereas many oldies stick to outdated technology like Autotools, Perl and Bash in the name of "if it kind of works half the time I can't be bothered to learn something better".
The bellwether for me is when devs doggedly stick to plaintext logs because "that's just how we've always done things".
Long reply from a young programmer that recognizes this trend and what it implies:
Alan Perlis says you can measure the perspective of a programmer based on their thoughts on the continued vitality of Fortran. Many universities are now going full Java and lowering standards on fundamentals for financial reasons, this is a bit alarming.
If you really want to stand out, spend serious time on fundamentals. Learn to develop and deploy clean, efficient software from scratch without relying heavily on external resources that add said bloat.
A huge trend in software right now is low-code/no-code tools. These tools can replace programmers that don't have a deep enough grasp of fundamentals to compete. A very small percentage of the world population knows how to code, so these tools are becoming massively popular.
This is what separates the programmer that can quickly throw together a basic CRUD app and a programmer that can develop a successful programming language from scratch. If you can make sense of the Linux kernel and you have the drive to constantly learn new tech, it doesn't matter too much what trends come and go.
If you just want to ride the wave and think just having a CS degree or knowing how to code will guarantee you an easy life, it will be a rude awakening when the industry keeps moving forward and economic crises trim the fat from the cyclicly overvalued and monopolistic world that is software development.
This is the duality of being a programmer. Yes, you can teach yourself many useful things and acquire powerful skills relatively quickly, but if you stop learning and challenging yourself, then you are liable to be left behind.
In the article, Gleixner is quoted to have said this: "printk() is the last thing I am going to clean up [...]. Then I am going to hand over to young people [...]."
Does he imply to step back (as a maintainer) from active kernel work in the near future?
For context, here is the rebase of the RT patch set on top of the current Linux release.
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-...
The list used to be much much longer. A lot of work is already in the mainline. It remains
Though RT will require constant “gardening” also after being fully mainlined. There’s an ongoing push to educate kernel devs how to not break RT in the future.