Live data from Hacker News

A regression is the kernel not giving the same result with the same user space

lkml.iu.edu

321–330 of 408 posts

Re: A regression is the kernel not giving the same result with the same user space

#321
post #105

Earlier quoted context omitted.

No, in fact, it is pretty obvious, at least to people doing kernel dev. The contract in this case is that there will always be a version number, and anyone who expects it not to change is an idiot or just being obtuse.

Well, I do kernel dev. I am the maintainer of KVM. :) > anyone who expects it not to change is an idiot or just being obtuse If this was the case, Microsoft would have never had to skip from Windows 8 to Windows 10 (see below in another comment: "starts with Windows 9" was used in the wild to detect Windows 95/98).

Eh? The version number changed. MSFT just changed to something not completely predictable in advance. Or am I missing your point?

Re: A regression is the kernel not giving the same result with the same user space

#322
post #126

Earlier quoted context omitted.

Great links. To make Linus his live easier I've made a website on http://www.firstruleofkerneldevelopment.com/ with those links so he can just reply with: "See www.firstruleofkerneldevelopment.com" instead of posting a rant.

He is never going to do that unless he owned the domain. He is not going to point to websites that could potentially change and show ads, malware or whatever.

Do you understand how jokes work or...?

Re: A regression is the kernel not giving the same result with the same user space

#323

Poor guy. Linus just melted his face off. Makes me scared to even _consider_ contributing...

Plenty of people claim that they're scared to contribute because Linus might yell at them. That's unfounded for a lot of reasons.

TL;DR: Test your code before you submit it. Don't accept or acknowledge patches from others that haven't been reviewed or tested. And if you make a mistake, own up quick and he's not going to yell at you. It's pretty simple.

He will occasionally jump in and yell when people aren't accepting responsibility for problems they caused. Especially when they won't accept nicer, less authoritative criticism from their peers.

That's what happened in this case. Check the follow-up message in the thread where Linus explains his dissatisfaction (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02507.html). The contributor who caused the regression was caught denying that there was even a regression. His patch had already long been identified as the culprit and reverted. But over the course of three weeks he was insisting that it was not a kernel regression. Essentially he dug in for 22 days saying that it wasn't his problem. And he wasted tons of valuable contributor time where people were nicely telling him that, yes, it was indeed a regression.

Multiple people were telling him about the "don't break userspace" policy and how it was a regression. And yet that contributor was still deflecting responsibility for the problems caused. But the problem is that this patch would leave the distros in the lurch - scrambling to update their configuration before the kernel breaks behavior. And that's without any ETA on their "long term ... flexible solution" (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/00380.html). Thousands of people with varying levels of technical competency would have had their systems break in unexpected ways.

Quite frankly, he earned the dressing down. And plenty of people tried to be nice to him about it. It just didn't take hold in his mind until Linus dropped in to rudely remind him that even "correct" behavior is a regression if it breaks userspace. Also note that Linus said the issue had been escalated to him. Someone explicitly brought this to his attention because there was a distinct lack of progress due to CYA responsibility deflection.

Re: A regression is the kernel not giving the same result with the same user space

#325
post #266

Earlier quoted context omitted.

What behavior? Linus's comments were carefully directed at the bad behavior that needed to be fixed. I don't see any personal attacks. Linus is a manager, and part of being a manager includes putting your foot down when someone is causing problems. Ideally, the situation should be handled directly and unambiguously ("The thing you're doing is incorrect and causing problems. Stop doing that.") before the problems beco…

"Seriously, it's the kind of garbage that makes me think your opinion and your code cannot be relied on" is, quite bluntly, a personal attack, directly commenting on an entire developer's code history and knowledge based on one single issue. This could be worded a lot better. The profanity is also unnecessary. The rule of thumb I've seen in your typical management oriented business books ( eg, your books / training l…

Linus isn't a manager, he's in charge. Persuading people to move in the same direction is a critical management skill but fundamentally not the job of someone actually steering things, and it's entirely common for the person in that role to just bluntly do the decision loop thing and let someone else put a happy face on it.

If you're driven away from having the job of transforming specific concrete direction into action for a large important organization then you should probably find a different job. Not everyone needs to put up with that, although if you have ambitions as a manager of people it will probably be career limiting.

The only strange thing about the Linux kernel is how it's all done in public instead of face to face.

Re: A regression is the kernel not giving the same result with the same user space

#326

Earlier quoted context omitted.

Rust also has yet to develop a stable ABI, I know they’re hard at work on so many things so I don’t say this as some snide remark - but until this is the case and Rust supports proper dynamic linking there’s whole domains of tasks I’m not comfortable using it for.

I can assure you we’re not actively working on a stable ABI.

Unfortunate, but expected. On that note, would there be any breakage loading multiple Rust .so's with differing compiler/stdlib versions into the same process? This is one of my main concerns about the lack of ABI stability and the static-linking-first design of Rust. With C++ at the very least I know Red Hat isn't going to break the ABI within a major release, but the Rust 1.21 packages are already in epel-testing.

Re: A regression is the kernel not giving the same result with the same user space

#327

Earlier quoted context omitted.

I'm willing to bet my entire life savings that Linus understands the meaning of the word regression in this context better than you.

Having read the entire mailing list thread, no, he is NOT using the word correctly. I suggest you read the entire thread. Regression in the case of code indicates this problem was there before, fixed, and resurfaced. Simply breaking user space is not a regression. It is simply breaking things and nothing more unless this problem occurred once before.

As it's used almost everywhere in coding circles, regression means a patch that made things worse than it was before. No implication of the worse state being there before.

Re: A regression is the kernel not giving the same result with the same user space

#328
post #207

Earlier quoted context omitted.

> http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02539.html Wow. Now that's how you do an apology. If anything my confidence in this guy is increased.

Simple. Contrite. To the point. No excuses, just solutions. Yeah, this is a _very_ professional response to a (typical for Linus tbh) very emotional (but correct ) post that could be easy to react emotionally to.

Fair point, but I'm coming round to the idea that emotional 'anger' might be a very effective tool to use when in charge of things. It seems well applied in this case.

Re: A regression is the kernel not giving the same result with the same user space

#329

Earlier quoted context omitted.

I can assure you we’re not actively working on a stable ABI.

Unfortunate, but expected. On that note, would there be any breakage loading multiple Rust .so's with differing compiler/stdlib versions into the same process? This is one of my main concerns about the lack of ABI stability and the static-linking-first design of Rust. With C++ at the very least I know Red Hat isn't going to break the ABI within a major release, but the Rust 1.21 packages are already in epel-testing.

If you want to ensure that there's no breakage, the only way is to use the same version of the compiler on all the Rust code.
Post reply on HN