Torvalds blasts tardy kernel dev: Your 'garbage' RISC-V patches are 'making the world worse' Linux head honcho Linus Torvalds has put a kernel developer "on notice" for waiting until the eleventh hour to supply a patch set for Linux on RISC-V systems which "makes the world actively a worse place to live" – in a scathing missive harkening back to his invective-laden tirades of old. Torvalds' brusque attitude was …
Meh. If you don't make things painfully clear to some people, they won't even understand what the problem is.
Linus is not a bad person because he doesn't suffer fools gladly. Contributors to the Linux kernel should be professional and mindful of the standards which are expected. It's not a touchy-feely education course.
To be honest, I thought his reply was quite polite and measured.
I once said a whole lot worse to a supportably experienced software engineer who tried to deliver some over-complicated and totally uncommented code that would only run without crashing on the very limited test cases they used to "prove that it conforms to specification". I was, however, restrained - I delivered my opinion in a private office with the door closed, and not in the open-plan office space in which I first saw the code submission.
'the very limited test cases they used to "prove that it conforms to specification"'
If it was supposed to do more than "conform to specification" as it was, then I hope you gave the specification writers a bollocking too for incomplete specifications.
Insufficient documentation is a pain, sure, have a whinge about that, but you can't berate them for testing to specification.
The way that sorted of thing normally happens is you write a good spec, then the developer picks a small number of test cases and writes code to those tests, not to the specification.
The programmer wrongly claims it confirms to the spec because it passes their tests.
That's not a spec issue, it's a programmer issue.
> I was, however, restrained - I delivered my opinion in a private office with the door closed, and not in the open-plan office space in which I first saw the code submission.
Thing is, the code that goes into the Linux kernel, ends up on tens of billions of devices, from supercomputers all the way down to smart fridges. That's why these discussions are in the open, NEED to be open, on a mailing-list, and not behind closed doors. The world depends on Linux, and by extension, on Kernel hackers to not drop the ball.
The people writing that code literally make the software that keeps civilisation spinning.
That has always been my approach: praise in public when deserved, have a(n occasional rather strong) word in private.
If you need to publicly put people down to satisfy your own ego you're a loser, and really not worth my time. I make an exception for heckeled comedians, of course, for that I will gladly make an exception because that tends to result in an amusing crash course in manners :).
Ditto for restaurant visits - you can identify the losers by the way they treat the serving staff.
If you don't make things painfully clear to some people ...
That is (unfortunately) so.
Linux does not run like it runs just because.
I does so because the Torvalds is on top of things.
And even then, has to deal with the type of BS that brought this to light.
It's been said here more than once:
Linus is the one signing off on whatever is sent to him.
It is his project, his reputation and finally, his name.
.
The kernel team should have a care about the PID 1 process since the kernel panics when PID 1 dies.
Personally I'd love to see a return to a minimalist PID 1 orphan catcher and then have the kernel team provide any support required for the service manager to function in a different PID.
Perhaps you have missed the massive expansion of systemd beyond pid 1. I would have a lot less problems with systemd if it had stuck to pid 1 but even in the beginning it was fairly obvious that was not the plan. Specifically the gross abandonment of interoperability with existing kernel software and the beginning of the previous mentioned expansion of functionality well beyond init that was there from the start. FYI the current "pid 1" systemd is now 1.3 million lines of code.
> If you don't make things painfully clear to some people, they won't even understand what the problem is.
You can keep telling yourself that to justify your approach.
Some developers do have to shape up or ship out. But making them hate you is never the correct resolution.
> But making them hate you is never the correct resolution.
Have any of the examples you are responding to, from Linus's message to the comments here, indicated that those who got told off ended up full of hatred?
> You can keep telling yourself that to justify your approach
Perhaps you are projecting, having been told (often?) that you are useless and growing to hate the people who have been forced into that position?
Nah, we miss the old Linus. Life isn't all sugar-drops and gum-drops. Sometimes ... the truth hurts.
No qualms with the delivery.
Imagine the responsibility for making sure 38 millions lines of code continues to work seamlessly across versions updates. Seems pretty understandable that the one responsible may get a bit upset and need to lay down the law when asked to include poorly written code to the project at the last minute. I can't fault anyone for that and it's reassuring to see a firm hand on the tiller.
Also, Linus would be first in line to help you bring your coding up to the kernel's standards, if you have the right attitude.
I used to subscribe and post to the kernel mailing list years ago and I've seen it many times. Once even explaining a complex problem to me, a user with a broken driver (I felt so silly that he spent his time on me like that). He's actually a very nice man, and most of his "brash" behaviour is more jovial than malicious.
I had to say his point about the potentially misleading and dangerous helper function contaminating a generic header is the kind of quality control that has kept the Linux kernel from descending to chaos.
Compared with some of the absolutely unacceptable behaviour that developers and their management I have observed, I would have to say Linus here would be the paradigm of civility.
"Compared with some of the absolutely unacceptable behaviour that developers and their management I have observed, I would have to say Linus here would be the paradigm of civility."
Agree, openssl when it was back in the nonsense 4 numbers + one letter numbering schema still, just after heardbleed is one example.
Now, I've had a look recently and a massive part seems to have been re-written in real C and not any longer the Chthulu C style language !
I often use a hobbyist board that is run by someone with an aspie lack of empathy in social interactions. Any minor fault and you get a massive public bollocking.
It's a useful board, but lots of people who could post on it simply don't. Nobody likes being yelled at,
So, carry on like that, and folk will just avoid the aggro by not being part of it.
There is more to good management than being right.
One of those things is planning your exit. As I get older and more conscious of my own impending fate, I can't help wondering whether having a few underlings who can filter this kind of dross (and the responses to it) might be a start in that direction. It would be difficult to conduct a papal election in the absence of cardinals.
If you cannot see the difference in the cost of garbage between a social media board and the kernel that drives the majority of all servers and 100% of all current supercomputers then you are hopeless. I pray you are not that hopeless.
I think he was remarkably restrained and correct. I might have used MANY more adjectives.
I was curious as to what Linus' suggested alternative would be. He basically suggests using (a << 16) + b, possibly decorated with suitable casts; if b might be outside the range of a 16-bit integer, you might use (uint32_t)((uint16_t)b) or similar.
Under most circumstances, I'd agree with him (as he points out, you can look at such and immediately see which is the high word and know what the code does). Though you don't have to get much more complicated before reaching a point where a separate macro is helpful. I would defend this macro for packing one-byte red, green, and blue components into 24 bits of a uint32_t, for example :
#define PACK_RGB( red, green, blue) ((PACKED_RGB)(red) | ((PACKED_RGB)(green)<<8) | ((PACKED_RGB)(blue) << 16))
Aside from everything else its a terrible function name.
The number of arguments and their types are written right there in the function signature, no need to repeat that information in the name. Its a DRY violation.
I can see why this change lit Linus's blue touch paper, it would set me off too.
Ha ha, I just read the whole email. The number of times I was asked to review code and then told btw, its urgent, it has to be released tomorrow because we promised the customer. What is the point in me reviewing then? There's no time left to change anything no matter how bad it is so just release it and accept the consequences. Don't make me a co-conspirator in your mess.
This post has been deleted by its author
Maemo for the Nokia 770/810 was a sack of shit where it got progressively worse due to idiot developers with free rein.
What if Linus or someone like him had been in charge of GNOME? We might have a useful, elegant, internally consistent Linux UI instead of yet another sack of shit. Someone to say "what the hell are you doing making the scrollbars disappear? that's useless!" would have been vital.
I have developed and managed projects since the mid 1980s, (retired in 2016) and had someone submitted that late in the cycle I would have reacted a LOT worse (and DID). Had their submission also been GARBAGE (as it appears this was) and beyond their scope I would have reacted a LOT worse and told them "NO" in about 47 LOUD words(in private, I hope)! Linus was measured, pointed, on-target, and left room for future (different/non-garbage) submission. Man has more patience than I. And his project is far larger and more critical, so garbage has the potential for more impact!
I am 200% on his side on this one.
The Linux kernel is now part of top secret-carrying military radios in Germany.
Thousands of other applications from Checkpoint firewalls to search engines to DSL measurment devices, industrial control etc.
Of course I expect Mr Thorvalds to have the balls to defend the kernel from substandard contributions.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
