Linus Torvalds Says 'Buggy Crap' Made It Into Linux 4.8 (theregister.co.uk)
Two days after Linus Torvalds announced the release of Linux 4.8, he began apologizing for a bug fix gone bad. The Register reports: "I'm really sorry I applied that last series from Andrew just before doing the 4.8 release, because they cause problems, and now it is in 4.8 (and that buggy crap is marked for stable too)." The "crap" in question is an attempt to fix a bug that's been present in Linux since version 3.15. Torvalds rates the fix for that bug "clearly worse than the bug it tried to fix, since that original bug has never killed my machine!" Torvalds isn't happy with kernel contributor Andrew Morton, who he says is debugging with a known bad use of BUG_ON(). "I've ranted against people using BUG_ON() for debugging in the past. Why the f*ck does this still happen?" Torvalds writes, pointing to a 2002 post to the kernel mailing list outlining how to do BUG_ON() right. He later adds "so excuse me for being upset that people still do this shit almost 15 years later."
we're introducing systemgdb
So that I can live a lifetime where I never make a mistake and everyone in the world is a moron compared to me.
Actually Linus, there is a good excuse - when the failing of a logic assertion could silently lead to behavior that is worse than a kernel halt, specifically data corruption.
So... Linus reviews and approves a patch with code he knows causes issues (or should, since he "showed the right way" to do it 14 years ago), adds it to 4.8 after the last RC, releases 4.8, and THEN blows up at the original contributor for his own mistake in approving the patch? Dear god, someone get that man some Xanax, and take away his electronics for a week so he can calm the fuck down.
Overlord issues 'BUG_ON() considered harmful' edict 14 years ago and only now thinks about removing said anti-feature?
Introducing a change just prior to release? sorry but the only person to blame here is linus himself, BUG_ON() bad practises aside an even worse offense is introducing untested changes to code you are about to release.
> I want to ... live a lifetime where everyone in the world is a moron compared to me.
You really don't. Dealing with morons is frustrating. When everyone is a moron (regarding the subject at hand), every interaction is frustrating.
I don't *excuse* Linus's temperament when it comes to kernel goofs, but I do understand it. There are a couple of very specific topics that I've studied and researched for decades. When I have discuss to those topics with people who have other specialties, and let them have input and make decisions that are within my realm of expertise but not theirs, it can be very frustrating. Because Linus is the expert on the Linux kernel, and he's a perfectionist, I understand it may get very frustrating to continually deal with mistakes that are, to him, stupid mistakes.
Linus isn't likely to invite you out for an ice cream cone to discuss a bug and your feelings about it but, he's right that it's a pretty bad bug (http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00878.html). Luckily, the way kernel development works means that 99.9999% of users will never see this bug. No major distro has shipped this yet and by the time this kernel trickles down to users (if ever), the bug will be fixed.
He's not apologizing. Saying "I'm sorry blank blank blank" doesn't constitute an apology.
I'm really sorry I applied that last series from Andrew
That's not an apology. That's saying he's disappointed someone screwed up, and he named that person to direct the blame towards that person. No dev team I've ever been on would throw someone under the bus like that. We would take responsibility as a team. He might as well say "I'm sorry Andrew sucks as a developer and is so incompetent", because that is no less an apology than what he actually did say.
Now had he said "I'm really sorry I didn't do my job and I didn't properly test contributions, and as the gatekeeper to what code becomes official, I take full responsibility for the bug and I'm taking actions to do my job better in the future", well, that would be an apology.
Better known as 318230.
Wow, so it was Nixon who started using BUG_ON() wrong?
Bet it was that slimy rat Kissinger. I never trusted his patches.
The world's burning. Moped Jesus spotted on I50. Details at 11.
As I'm not a developer, I had to read through some of the comments left to the original stories to figure out what the fuss was all about.
Maybe most Slashdot readers are more focused than I am on coding and already know all of this. But what I learned is that essentially, sticking this BUG_ON line someplace in the code causes Linux to do the equivalent of a Windows blue screen of death when it hits it. It's a purposeful way to cause an instant system halt because you believe the software should never reach that spot in the code, and if it does, you're worried that data corruption will result -- so better to halt things than let that happen.
It sounds like even back in 2002 though, Linus was expressing his dislike for using it and recommended a WARN_ON alternative that would just alert people to the issue but let things continue.
The thing is? I'm not entirely sure Linus's anger is warranted here? It sounds like basically, he's of the philosophy that "the code must go on". In other words, it's almost always better to keep the system running, despite any bugs, than to kernel panic and stop the whole thing. Perhaps in a world of virtual machines and servers running a whole slew of different processes at the same time, there's logic to this? (EG. If one of your boxes is needed to perform DNS, DHCP and/or other basic functions for a whole network -- you'd probably rather it keep doing those things, even if a bug is hit that means a process reading/writing data to files someplace else gets a critical error that could corrupt records in a database or improperly truncate some other file it was working with.)
BUT .... this could just as easily be subjective, based on where the bug lies and what it impacts, vs. what YOU consider a mission critical use of the machine in question. If BUG_ON saves data from loss, maybe that really is better for SOME users than letting it go on generating/logging warnings that people aren't going to notice right away?
I get the idea Linus leans the direction he does on this issue mainly because he wants any kernel he approves as "stable" to have that appearance, buggy or not.
Buncha snowflakes and pop-tarts can't handle some feedback with a few 'fucks' thrown in??
You are in the wrong damn career. Computers and their software WAS BUILT with profanity. It is part of the culture.It is just like the military. Wars are won with profanity and murder.
If you don't want to hear it then go teach preschoolers how to color.
The corporate fascists running this country don't care whether you vote for the buffoon or the crook, really doesn't matter
Dangit gotta warn me when you are posting... now I'm going to have to replace the troll detector again. And two rooms of the house where it was sitting .. and a cat.
If you'd been at the end of "Torvald's rampant verbal abuse" for 15 years, you'd have been banned from submitting to the kernel about 14.5 years ago. So, really, it wouldn't be an issue.
Ya, all those young programmers that don't know about 15 year old discussions on the use of the BUG_ON macro etc., so they keep re-inventing the square wheel...that'll fix things!
Sometimes AC's say the stupidest shit.
If you actually read the thread, that's basically where he says it's appropriate, and only then.
The problem appears to be that people are using that feature in situations where recovery is feasible and desirable, or they're using it under the assumption that it only impacts people running special development kernels.
Log in or piss off.
Did I miss something? Is Andrew really that bad? He let a bug through here, but I remember him being one of the good ones.
I understand that this is a troll post but, it still makes me laugh. Software guys over the age of 40 are a pain in the ass to work with because they've seen so much idiocy over their careers that they can spot it immediately and point it out. If you are in your 20s and working with other people in their 20s, the echo chamber you live in is certainly re-affirming but, not particularly conducive to writing good software.
I guess this quote from Linus threw me off:
"I should have reacted to the damn added BUG_ON() lines. I suspect I will have to finally just remove the idiotic BUG_ON() concept once and for all, because there is NO F*CKING EXCUSE to knowingly kill the kernel."
I don't think the problem is that everyone else is a moron (though there are a lot of them to be sure), it's that everyone else has a different plan, agenda, goal, technique. So one person who lives and breathes the code is annoyed at other people who may want to get home early, are new to the code, are under a lot of pressure to get it done fast, and so forth. At the work place, should you accuse the employee of being incompetent at the task, or blame the manager for assigning a person without the necessary skills and experience to that task?
There's some good stuff in Linux. But damn it's an unreadable mess in so many places. I like looking at BSD based code because it is so often much more straight forward and easier to understand.
So where in the open source world are there regular code reviews with thought out discussions about how to write code better, how to follow the correct style guidelines, pointing out "oh by the way, you're using BUG_ON() the wrong way", and stuff like that?
Well mostly people who are too ignorant about software development to know that there is no such thing as a significant codebase in which that isn't the case. Clearly you have no software development skills or experience. Off you go ....
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I do excuse it.
He is attacking the mistake of the person and not the person.
Taking such stuff personally is ridiculous, but I suppose it does give people something to talk about with something that's almost a non-issue.
1.) Andrew Morton was the maintainer that published the commit, but Johannes Weiner pushed the fix. Almost no one mentions this. 2.) Point #1 doesn't really matter. Who cares about who did what. 3.) A relatively and surprisingly cool Linus comments on something that's been bugging him. It's almost pub talk except kernel developers. I wish I could've created a more cogent proof or argument, but really, non-news. Kernel developers discuss an issue resolved slightly later than ideal. Linus loves his beautiful artifact and wants to address anything that may mar it (which almost every article on this mailing list thread has overblown). I'd like to think everyone on that list is nearly as interested as he.
Btw, I *am* the moron in kernel dev. My name is in the kernel changelog exactly once, which means I helped find and fix a problem when I had never done so before - I didn't know what the heck I was doing. Kernel development is very complex, with it's own set of rules quite different from userspace and I was in there trying to work on it, sending emails to the maintainer of the md subsystem (raid etc.) For anyone reading my emails or code, I was, compared to them, a moron. My flailing about might have been frustrating for them.
On the other hand, after almost 20 years I understand Linux pretty well from the userspace perspective, particularly the storage and security side of things. So when I'm in a meeting at work and the project manager wants to put certain files "on the C drive", when he wants to defrag and log in as Administrator, he becomes the moron and I'm the one getting frustrated.
Sure, an ideal software team is basically:
- 1-2 grumpy old guys who are mostly just trying to steer the project away from disaster.
- A couple guys a bit younger than that who are less jaded than the grumpy old guys but, kinda get where they are coming from and so genuinely think about the code they are writing.
- A couple of young guys that just finished a C++ book and enthusiastically want to use templates everywhere.
That's a software team that can get shit done. And, probably won't be using the excuse of "refactoring" to rewrite it in six months.
So where in the open source world are there regular code reviews with thought out discussions about how to write code better, how to follow the correct style guidelines, pointing out "oh by the way, you're using BUG_ON() the wrong way", and stuff like that?
I really would like to know too. I write device driver for internal use, but I'll be torched down if I try to get them accepted in the kernel because there are so many things in them that I don't know how to do the 'correct' way.
Non-Linux Penguins ?
I'm fucking adding "come down off your thrown jerk-face" is my lexicon of phrases. Fucking ace.
I do not want your cheap brainburning drugs. They are useless for work. And I am a working man today.
I do excuse it. He is attacking the mistake of the person and not the person. Taking such stuff personally is ridiculous
I think that's a thing about geeks/nerds. If they see something that is stupid, they just say so. Most of the time there is no filter or consideration of the person behind the idea and, the effort they put into an idea, but don't intend it to come across as something personal. Usually it's because the critic (Linus in this case) isn't able to seperate their own emotions from their criticisms of an idea. Their code may be beautiful but their interactions are not and conflict arises.
Unfortunately we all do it to some extent however, I think the thing you have to look out for is when you start being an asshole most of the time because it puts people in the 'fuck you' mode, they don't listen to you anymore and, use BUG_ON. I'd imagine that he had some input as to who would be on the team so if they are morons, doesn't he share some blame for their actions?
These guys rise to a level of Assholiness where no one questions them anymore and they stop evolving. I'm not making a character judgment here, I've certainly been an asshole from time to time when I am working to realize a vision. What I saying is that being that asshole held me back where I was, so I wonder what guys like this can achieve if they have people rallying behind them, instead of them thinking 'hey this guy is gonna act like a jerk if I do something they don't like'.
Dealing with morons is frustrating however dealing with volatile people that can't control their emotions is too. No one gets what they want because a lack of charm inspires all the wrong things.
My ism, it's full of beliefs.
Yeah, that's the quote everyone highlights, but he's a bit more nuanced about it when he's maybe a bit less pissed. Two e-mails in, you have http://lkml.iu.edu/hypermail/l...:
Log in or piss off.
I really would like to know too. I write device driver for internal use, but I'll be torched down if I try to get them accepted in the kernel because there are so many things in them that I don't know how to do the 'correct' way.
No you probably won't be 'torched down', Linus' rants are typically aimed at people who aren't new to the Kernel and really should know better. If you're a newcomer to the Kernel they would afford you some leeway, just be prepared to take some constructive criticism on your code.
Where did I volunteer an opinion? I restated the parent's opinion with clarity, removing the sophistry. If you choose to take it as negative, well, then probably the parent post shouldn't exist.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.