Linus Torvalds admits 'buggy crap' made it into Linux 4.8 Linus Torvalds gave the world Linux 4.8 earlier this week, but now appears to wish he didn't after spotting some code he says can “kill the kernel.” When Torvalds announced Linux 4.8 on Sunday he said the final version added “a few stragging fixes since rc8.” But by Tuesday he was back on the Linux Kernel Mailing list …
All lock debugging, etc - is peppered by BUG_ON()s
Granted, a BUG_ON() may be better than deadlocking in that case, but still... it is a reality - if you turn on any of the debug directives in the kernel you immediately wade into a morass of BUG_ON()s
So it's sort of a Linux BSOD? Fortunately, I've never seen it on my Linux box. I have seen a fair number of Windows BSODs, though.
People sometimes complain about Linus, but if Windows developers had anything like that much passion for producing a good product, Windows X would actually be the upgrade from Win 7 MS claims it is instead of a festering pile of dingo's kidneys.
You are comparing Windows the-entire-platform to Linux the-kernel. Like thinking Linus is in charge of Ubuntu, or whatever.
The original person in charge of the Windows kernel, Dave Cutler, is just as much of an anal asshole as Linus. And certainly more OCD when it comes to coding standards.
If you fuck up, Linus flames you on LKML. Cutler beats you up (or used to in his younger days, atleast). Or if you're lucky, just punches the wall.
Why the hell are you people down-voting Patrick, exactly? I couldn't be because he is 100% correct and you can't be arsed to look at a Microsoft asshole the same way you look at Linus?
I have drank with Both people in Question. Linus is BY FAR more stable than Cutler, and Cutler is BY FAR more anal than Linus (to be fair, "coding standards" does not mean Good Code).
So what's the bitch, here?
* Microsoft can't have someone that actually cares? (One, they're allowed one, they HAVE to have one, otherwise Marketing and Business units would prevent *any* code from shipping.
* You can't believe that anyone is a bigger asshole (for the right reasons) than our Fearless Penguiny Leader? (Would you like me to sort that list by last name, company name, or date?)
- Bonus Round, Two Words: Steve Jobs.
My *completely* subjective and biased opinion (not that you asked for it, and if wise, you wouldn't) is that if Linus flames you for doing something that:
* Has been covered already.
* Is documented (can be googled in LKML)
* Linus has specifically said "Do not do this".
* Linus specifically tells YOU "Did you not see me tell him/her not to do that? WTF did you then do the exact same thing?"
AND THEN calls you out specifically as a dumb-ass...you are a dumb-ass.
Honestly, how many times do you have to tell someone not to do something? When does it *finally* become "OK" to tell someone they are fucking up in a way that leaves no ambiguity (just like the previous dozen times)? Ten? Twelve? A Hundred?
In MY shop the answer is "One Time" then I haul you out by your shirt collar, into HR, and I say: "Cut their final check now because I never want to see this incompetant shit again." Following instructions of the Team Lead is a basic function of one's job as a developer. That fact that Some Open Source folk have used "I contribute" to also mean "and since I'm not getting paid, I can fuck off on my code and ignore the Lead" can and should be used to eliminate that person as Open Source as with Corporate, don't want to follow the rules then you can piss-the-hell-off.
Not to put too fine a point on it, but Linus has been a hell of a lot more patient with some contributors than I (and most of my peers) ever would have been, by orders of magnitude.
@PatrickStar called it corectly.
"Not to put too fine a point on it, but Linus has been a hell of a lot more patient with some contributors than I (and most of my peers) ever would have been, by orders of magnitude."
Yup, and the fact that Redhat staff keep dissing him over his comments explains a lot about why RHEL has a bunch of nasty festering bugs that the delicate flowers there refuse to fix.
They'd rather shoot the people complaining about the bugs and regressions for getting pissy at them than actually fix the fucking problem (Here's a hint: If someone's paying you £10k per machine per year for support and they have a problem because you fucked up your code, then they expect you to fucking fix it, not get huffy and refuse to deal with the customer because you got called a bad name.)
@ma1010
if Windows developers had anything like that much passion for producing a good product, Windows X would actually be the upgrade from Win 7 MS claims it is instead of a festering pile of dingo's kidneys.
You take that back. That is a total disservice to dingo's.
In the old days (as in 1990s) BUG_ON() was meant to allow the kernel to boldly announce a situation that was not properly handled by any error handling code in the kernel. BUG_ON() essentially logs some status information and then halts the execution of all code in that machine rendering the machine unusable and leaving the user just the option to reboot the machine. Naturally a reboot could then trigger the same situation leading to BUG_ON() again. BUG_ON() could and should be avoided by better error handling code. If better error handling code is not possible there might be something wrong with the entire design of the code leading to the BUG_ON() call.
He was around in 2002 and he forgot something Linus posted back then? What a twat.
It appears your downvoters don't understand sarcasm, so best make it bleeding obvious next time with something like:
"THIS POST MAY CONTAIN SARCASM AND MAY HARM WHEN PRINTED ON ROUGH EDGED CARDBOARD AND USED FOR RECTAL EXAMINATION".
You could add bold and italics to it, but I'd draw the line at blinking text. Or, more subtle, you could use the tag below:
/sarcasm.
This has been a general service announcement. The regular schedule will now resume.
:)
The sarcasm in the post was so obvious, it shouldn't have to be pointed out.
Yet it did...
In English: How can this right honourable linux developer be expected to remember something Linus said many years ago about something fairly obscure? Then get shouted at publicly and profanities hurled in to the air, for just attempting to contribute to the open source Linux kernel.
Then get shouted at publicly and profanities hurled in to the air, for just attempting to contribute to the open source Linux kernel.
Well, OK, I don't think anyone can be expected to read all of Linus' missives, but I do suspect that anyone aspiring to contribute code is well aware of the communication style in that team, including the occasional flame. That IS easy to discover upfront so you best grow a thick skin and put a bit of effort in re. code quality. That said, it's not great for new entrants, over time you may end up with an ageing pool of developers mainly shouting insults at each other :)
"In English: How can this right honourable linux developer be expected to remember something Linus said many years ago about something fairly obscure? Then get shouted at publicly and profanities hurled in to the air, for just attempting to contribute to the open source Linux kernel."
BUG_ON causes a kernel panic, then makes the kernel die.
You should not deliberately cause a kernel panic unless you have decided that the operation being performed has put the kernel in to a dangerous state - unless you are using it to debug, in which case the BUG_ONs need to be removed before pushing the code.
Therefore, this is not something "obscure", and the passage of time does not change what BUG_ON does, its intent or its well known use-cases.
It is also easily found in the KernelNewbies FAQ: https://kernelnewbies.org/FAQ/BUG
There are ways and means of managing a team. Good ways and bad ways. Public denigration is never a good way of boosting morale in a team. I'm sure there are a lot of young developers out there who are highly skilled and highly motivated, but whom read Linus' posts and say "fu*k, that, I'm not working with that arrogant tw*t".
@sabroni
Tha's really trolling for downvotes today, me owd cocksparrer. Wassup? Tha getten a codin boggart tha cant fettle? Leave t'penguins alone while theys having a panic and waddlin' round and round squawkin' at each other. Thems'll settle down soon enough an get on back t' peas getting above sticks.
"I'm sure there are a lot of young developers out there who are highly skilled and highly motivated, but whom read Linus' posts and say "fu*k, that, I'm not working with that arrogant tw*t"."
Nah, don't think young people care really. Have you seen youtube comments, or heard Trump? (Who isn't young but tries to appeal to a "certain segment".)
> I'm sure there are a lot of young developers out there who are highly skilled and highly motivated, but whom read Linus' posts and say "fu*k, that, I'm not working with that arrogant tw*t".
Said young developers tend to be delicate little flowers with a vastly inflated sense of self importance who are going to find that life doesn't owe them anything and what Linus calls people is as nothing compared to what happens when they're being paid to do stuff and cause a multi-million dollar clusterfuck because they can't stand being criticised.
I'm slightly bemused by the comments describing Linus' posts on LKML as "public". Sure, anyone can read them if they go out of their way to subscribe or read the archives, but what proportion of the general public makes the effort? I suspect that many of the critical comments come from those who would never have noticed if it wasn't for stories like this (and therefore have little idea of the historical context leading to the remarks).
Well, I don't know really how the Linux kernel development process works. It seems pretty much centred around Linus and I wonder how continuity is ensured. Maybe it's all well arranged but it raises some questions when the guy at the top of the pyramid* has to release the kernel and also is the one ranting about some bad practice.
* No idea if it really is a pyramid. Maybe an upside-down T?
True, but relatively few people run Linus kernels directly without vendor patches in practice. He's only at the "top of the pyramid" because others choose to follow his lead, and if it's a pyramid, it's one that works both ways past and future, due to various testing releases leading up to and before a Linus release and vendor and stability patches afterwards by other maintainers. In practice the rate of change (number of patch sets per release) is such that Linus has to trust subsystem maintainers to check things he no longer has time to do himself.
> It amazes me for someone who is such a perfectionist that this was allowed to slip in
My WAG* would be that Linus doesn't personally pore over every single line of code. More likely there are several "grades" of dev - with the best and most trusted allowed to submit their own code with little light handed oversight; while at the other extreme, there are devs (notably from the Freedesktop.org camp, see previous stories on Linus's rants) who don't get anything in without someone more trustworthy having vetted it.
* Wild Ar*ed Guess
"ultimately it was Linus who released it to the world as stable!"
And it was Linus who admitted that, apologised for it and is dealing with the fallout - and unlike some people or organisations I can think of, he did so as soon as he discovered it rather than trying to hide it or slip out an unannounced bugfix.
Back in 2007 - I think it was going from Fawn to Gibbon - I was hit by a very nasty and *incredibly* subtle bug. I was using GNOME but following advice from the community I setup various GUIs and over time every one demonstrated the bug which manifested itself with the mouse focus becoming "trapped" in an hidden GUI item. Once trapped, the mouse cursor moved around, but mouse clicks did nothing. I got as far as wondering if a startup process was generating a hidden window, but disabling everything didn't work. Short of becoming a kernel dev (not really on my lifeplan) I was stuck.
The only way to fix it was to restart X. Which lost all open windows.
I duly logged the bug (which was a bastard to reproduce - it seemed to happen at random) and had a few other users join in with their noting it. It wasn't universal, and seemed to have some connection with the type of mouse, but nothing "aha".
Time went on, and I experienced the full wrath of the Penguinistas - especially when I pointed out that the hardware setup (the first target of finger pointing) was dual boot and worked (and still does) 100% with Windows.
Anyway, the email address I used to register at AskUbuntu (now UbuntuForums) still gets the odd email - last was a few weeks ago about Yak) asking for a fix.
That's the better part of a decade *something* has been buggy in the kernel. And since I used Drake, Eft and Fawn without incident, I think it was introduced then - and is still there.
Not really sure of the moral of this tale, but learning there is buggy code in Linux is not news, I am afraid.
Let the slings and arrows begin :)
It's handling HID devices, and probably not in the kernel but in Xorg.
And it's not really subtle, it was annoying as fuck in my case.
I was able to perfectly reproduce it at will. In my case, the issue was caused by a Plantronics headset which are a dual device -- in addition to USB audio, it's also a USB HID device. The HID portion is responsible for responding to volume controls and headset button. Pressing the headset button immediately locked mouse focus to one window (I never cared enough to work out which window) and wouldn't release it.
When looking for others with the same problem, I came upon a workaround. It needed a certain key combination. IIRC, it was holding right Alt (maybe with Shift) and the middle mouse button. I can't remember now and I'm not bothered to look it up. Sometimes that fixed it, sometimes it didn't, and sometimes it appeared to fix it, but the issue reoccurred in a minute or so.
I realize it doesn't help you much, but yeah, Linux has lots of buggy code. And some developers also have an attitude that doesn't match the quality of their code.
Alt-Printscreen-r will sometimes reset the input interface, as will switching via the ctrl-alt-functionkey shortcuts (or chvt command) to a tty and back again.
All-in-all, triggering that bug has gotten more rare over the years as the misbehaviours of various HIDs have been noted and exceptions patched in.
I've seen similar behaviour. In such situations, one very good thing to do is to log the input from the offending device; in my case, it showed clearly that the mouse had some… slightly odd behaviour in that, for certain buttons, it wouldn't indicate that the button was released until it was next pressed, which (of course) immediately triggered another button press event. That one got fixed in the kernel via the HID quirks mechanism such that the kernel will generate fake release events for the affected buttons, making them effectively instant-release as far as userland is concerned.
That headset sounds like it has the same issue; and the workaround which you found was probably a key combination which sent XF86Ungrab or XF86ClearGrab or similar.
@Apprentice: Please get off your high horse. The bug affects all desktop environments, although it may have different manifestations in each of them. I understand you may use CLI exclusively in which case it's not a problem for you.
However, I'd like to point out one thing: people with oddly behaving HID devices probably outnumber CLI purists by a few orders of magnitude.
Yes: they got it wrong; but they did not attempt to hide it with some marketing department style drivel. Fortunately this has been found and made public - so the big downstream users (ie distributors) will be warned and remove the bad patch or wait for the next release.
No: not perfect; but who is ?
Another thing that this shows is that Linus is running the latest kernels on his own machine and so gets to suffer if he cocks up.
Yes there is, it's when the system is deemed to be in an unstable state and rather than risking security breaches and data corruption, the operating system stops to prevent further damage and facilitate diagnosis of the error (paraphrased from Wikipedia article on kernel panics).
KFC did that when he threatened to reveal his secret recipe to the world.
Well, that and the reason they abbreviated their name from Kentucky Fried Chicken.
(My legal team has asked me to point out that this is all utter bollocks, but we all know the truth really *nod* *wink* *twitch*).
Let's be honest though when do we ever see such an apology from any other large scale OS's when they manage to kill the kernel in the same way? I don't recall hearing Steve Jobs or Bill Gates publicly say we shouldn't have launched something as it had a major bug in it.
Let him have his accountability, it's better than never explaining at all.
"I don't recall hearing Steve Jobs or Bill Gates publicly say we shouldn't have launched something as it had a major bug in it."
Pretty sure Gates said exactly that about Windows ME actually. And a few other things too, in fact. He was quite good at the whole 'business' thing, and one of the things you need to be good at that is being able to admit mistakes and drop them. Oh, and a complete lack of a human soul, that helps a lot too.
Ballmer probably never did admit to any mistakes, but then it's pretty clear he was also awful at running a business.
Well, he sort of said sorry and that's better than silence or blaming the user (anyone remember Antenna-gate on the iPhone 4?). Mainly though he was just slagging off the guy who did the code. Fair enough the guy made an error and he's taken that point without whinging about it. Funnily enough he's the one who comes off looking classier IMO.
The more of these rants I see from Torvalds the more surprised I am that more Kernel devs don't just tell him to shove his little hobby up his arse.
Good thing I changed strategies on the Linux kernels, avoiding the mainline and going into long-term kernels is a better idea. As it allows for bug fixes to applied. I'm currently using Linux kernel 4.7.4 and I'm not going to update for a while now as the rest of the programs and drivers (mostly nvidia drivers) running on top of that have not updated up on the latest changes.
Mainline kernels are for those wanting to live on the bleeding edge.
I wish we could get Linus to read this article about the programmers who wrote software for the Space Shuttle.
https://www.fastcompany.com/28121/they-write-right-stuff?show_rev_content
The tl;dr is 1) have a collegial but firewalled and adversial relationship with QA. When they stop a buggy release and detect a new bug, they win, and they want to win. 2) don't blame the developer who did the bug, blame the meta-bug in your system that tolerated the bug's creation. Fix that meta-bug and you've got a better pipeline and you don't just stop that specific occurence but reduce the chances of future occurences of said bug.
Maybe buggy Linux kernels can't kill seven astronauts like buggy Space-Shuttle code could've but the economic damage they CAN do needs to be used to make a business case. The business case is to create a build pipeline optimized for success rather than blame-passing, personal humiliation, and scatalogical vituperation.
Why this fuss about some swearing once in a while. Born before the bomb, too late to sail on the big ships, to early to write any open source stuff. Thirty five years writing proprietary software, which of course doesn't change the task of programming. But my Deity I have seen broken furniture, blood on the floor, broken noses, cut car tires, back stabbing, finger pointing at guys not present, and tings I rather forget. What some commentards seem to complain about is rather "Sunday School" to me. Have those same guys any experience at all.
The reason I would like to have worked with open source is that I envy the fact that they work with people who presumably know what they are doing. While I had some very good bosses there was also some completely different. The worst you can get is a guy who once wrote one and a half meter of Basic and thinks he is an expert programmer.
An other reason is that most of the projects I have seen failing, failed the minute the agreement was signed due to an impossible timetable. Some people will know what I am writing about.
One of the reasons why Linux has become such a success, I would claim, is because they are not forced to deliver shit because of some upcoming Christmas or similar.
And what about Andrew Morton, is he hanging his head now, I doubt it, those guy know each other very well, but I could imagine he might meet BUG_ON() in some dream some night. We have very odd dreams at times.
"you'll be able to play with features including: HDMI CEC support, making Linux able to control chained HDMI devices with a single remote control;"
Really? In the kernel? Surely stuff like this should be a kernel loadable driver, not a default part of the kernel. Only absolutely essential drivers ought to be part of the kernel, loadable at runtime, or compiled in if the user has a specific need. Or am I misunderstanding what this means?
You're misunderstanding. The kernel is indeed modular and can load just the drivers that are actually needed. For that matter, you can build just the drivers you need if you don't want to deal with having all of them lying around and decide if you want them built-in, or just have them available as modules to be loaded as needed. Most distributions build every hardware driver that's not horribly unstable and include it as a loadable module. That way stuff works when you randomly plug in something new.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
