Live data from Hacker News

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

lkml.iu.edu

231–240 of 408 posts

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

#231

Linus is such a breath of fresh air. I'll take an honest, emotional, impossible to misconstrue, ass-chewing over the alternatives. Too often there's an avoidance of straightforward, blunt speech that conveys exactly what is meant. I really have better things to do than try to parse nonspecific beating-around-the-bush and deconstruct word-castles.

The emotion definitely shows how angry he is, but it is possible to express yourself without getting angry; to be clear, concise, and impossible to misconstrue. Ass-chewing isn't generally beneficial as it makes people defensive and potentially angry themselves. The mea culpa is good: "And again sorry, I screwed up, it should not have happened, my perspective was incorrect and I know I need to make it right." This is…

> As someone who's gotten chewed out before, all it does is leave a bad taste in your mouth and most likely going to quit the company or possibly the project.

That seems to be his direct intent, and being angry does help get this point across.

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

#233

Earlier quoted context omitted.

Because high quality kernel code is more important than not alienating contributors. If someone prefers softer conduct, they are free to fork the kernel and start their own efforts.

> If someone prefers softer conduct The big issue I see people reacting to is profanity. You can be as hard on someone, given the nature of the infraction, without using profane language or denigrating someone. If they don't comply, threaten exactly what Linus threatened, no more commits will be accepted. While I don't disagree with Linus' right to speak as he does. He can be just as effective without the type of lan…

I don't see the problem with profanity, different strokes for different folks.

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

#234
post #29
post #4

Mercurial, made by another (in my opinion) much more well-spoken kernel hacker, is what really introduced me to the concept that you do not break interface for downstream users, no matter how wrongly you may think they are using the interface. It’s an attitude that is difficult to convey because software developers always want to have the freedom to “improve” their own software, even at the possible cost of breaking…

If only compiler developers had this attitude.

... just recompile

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

#235
post #217

Linus is such a breath of fresh air. I'll take an honest, emotional, impossible to misconstrue, ass-chewing over the alternatives. Too often there's an avoidance of straightforward, blunt speech that conveys exactly what is meant. I really have better things to do than try to parse nonspecific beating-around-the-bush and deconstruct word-castles.

"At least he tells it like it is" right? Forget that he's an asshole about it. Pretty much the same reason everybody voted for Trump.

Except Linus is technically right, where Trump is normally technically wrong, and an asshole.

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

#237
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.

Was there a "first rule" before the 2012 rant, or was it invented in that email thread?

Linus has said earlier that this rule has been in place pretty much since day 1 (in a google+ thread here: https://plus.google.com/115250422803614415116/posts/hMT5kW8L...), although he's made it much more explicit than it was at first.

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

#238

Earlier quoted context omitted.

The bug they fix is the bug that keeps the API contract intact. The first application gets its bug fixed, and the second application breaks because it was relying on a bug that didn't match the API contract. You program to an API, not to an implementation. The second application did the latter, and will therefore pay the price.

Well, sometimes, but the Windows philosophy is probably to introduce a shim so that an app relying on the broken functionality still works.

If you can afford to do that, it's nice to do it indeed. It can get messy and hairy quite quickly though.

It seems to me a lot of it boils down to "who gets impacted". If I have a bug in my kernel and a lot of apps are somehow relying on it, I need to be mindful of that and perhaps swallow the purity of the contract in order to provide a pragmatic fix.

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

#239

I'm glad Linus has this attitude and it is unfortunate it's not present in some other places Though it is annoying if you're at the receiving end of it, own up (the opposite of what the patch author was doing)

you would want to work with someone like this? I think he comes off as a giant asshole. there's tons of ways to get your point across and be passionate about your work without treating people this way. if this email came out at any company I've worked at it would be a serious problem, HR involved immediately

no amount of skills gives you a free pass to treat people like shit. I would not want to work with anyone who has this attitude

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

#240
post #37

Earlier quoted context omitted.

For user experience reasons that seems like a extremely sensible principle. But doesn't this make fixing some security issues impossible?

Linus calls out the fact that there are some times in which breakage is unavoidable, but that should only be after trying very hard to avoid breakage.

I do think there's an enormous difference between breaking changes of the form "hey, this is important and it's going to break shit, we can't find an alternative, be prepared" and "oops, we broke it, good luck!"

Rare, planned breaking changes are a reasonable answer to improving security and usability. Python 2 -> 3 and the Mac PowerPC switch both seem like examples: they caused real inconvenience, but they were very clearly announced and had real benefits.

Sporadically screwing over users, though, really is unforgivable. Last time I updated Windows it escalated a minor graphics card issue from "automatically recovers" to "kills your session to collect error data". It's like the patch author comes into my house once a week and unplugs my machine, just for their own amusement.

Post reply on HN