Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lkml.iu.edu

Post reply on HN
Print view View original

91–100 of 408 posts

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

#91

Post by tome »

pjmlp wrote: post #22
jordigh wrote: 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…

Rich Hickey has a wonderful talk about it. "Spec-ulation" - https://www.youtube.com/watch?v=oyLBGkS5ICk Which I fully agree with, basically there are no major, minor, patch level changes, in reality every change is a possible breaking changes, because we don't control what downstream is doing with our software.

Oh well, he should try a language with types ...

/me runs ...

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

#92

Post by magicalhippo »

mikeash wrote: post #71
acobster wrote: post #62

Earlier quoted context omitted.

Minor point, but he puts Python in with software that "almost never breaks" on update. Really? Am I missing something? Maybe he just hasn't tried running Python 3 yet...

Python 3 is a similar language with a similar name to Python 2. It shouldn’t be considered an update, nor applied as one.

Yet the Python 3 executable has the same name as the Python 2 executable...

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

#93

Post by martiuk »

rambojazz wrote: post #82
jordigh wrote: 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…

> you do not break interface for downstream users, no matter how wrongly you may think they are using the interface How does Linux manage to never break its API? For example in the event of a refactoring.

Certain parts of the API once able to respond with a value now just spit out '0', it means that whatever application that used it just continue to work even though that part is deprecated.

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

#94

Post by xstartup »

orcdork wrote: post #14

In any other kind of social/business arrangement he would be politely but firmly escorted out, possibly by security, for this kind of behavior. Being right or wrong is irrelevant.

Let me guess, you do not take any responsibility for what you do at work. I know plenty of folks who would love to make decisions and like thinking that they can do better, yet when their decision takes everyone down, they refuse to share any responsibility for a bad decision. And if you are not being held accountable that means someone else pays for your mistakes in business.

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

#97

Post by EGreg »

jordigh wrote: 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…

Why not simply bake these contracts and tests into the actual software APIs so they are impossible to break?

That way the app would be "backward compatible certified" if it used this layer. The layer would only run during deployment.

I guess an approximation is the Passing indicator on Travis or GitHub.

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

#98

Post by toyg »

jokoon wrote: post #56
raverbashing wrote: post #47

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)

He can afford to be politically incorrect because he makes all the decision, and because nobody else than him can make decisions. He is the expert. There are very few places in software where an expert/engineer have full authority on the development/how things are done/specifications. You often see money/markets/trends take over. I really wonder what linux will become without Torvalds when he will go away. I hope he…

Most of his current generals are very much the confident type (occasionally even too much so), so I don’t really see a problem there. As long as Linus doesn’t anoint a RedHat employee, things will just keep chugging along.

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

#99

Post by hatred »

dingo_bat wrote: post #81

I'm always eager to read Linus's rants. I wish more of my coworkers were like him. I hate the environment where nobody reacts strongly to anything! If somebody fucks up hard and refuses to own up, I (or whoever's in charge) should be able to shout at them. It's only natural.

Because its hard to say the least.

This sums it up: https://news.ycombinator.com/item?id=15610108

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

#100

Post by 35bge57dtjku »

jsjohnst wrote: post #79
piker wrote: post #38

Earlier quoted context omitted.

Interesting. > Behavioral changes happen, and maybe we don't even support some feature any more. There's a number of fields in /proc/ /stat that are printed out as zeroes, simply because they don't even exist in the kernel any more, or because showing them was a mistake (typically an information leak). But the numbers got replaced by zeroes, so that the code that used to parse the fields still works. The user might n…

Having had to fix a number of production issues where a change happened XX days ago but the code just silently kept going rather than breaking, I’m sorta of the mind to agree with you. I’d almost rather it break hard, so then I know it’s broke and can fix it. Very nuanced situation though and as such definitely not one size fits all.

Isn't that just 'fail fast' behavior vs. silent ata corruption?
Post reply on HN