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

151–160 of 408 posts

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

#151

Post by penguinUzer »

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.

I have the same problem where I work. If someone messes up it starts a long game of passive aggressiveness. I'd much rather people come right out and tell me I'm causing an issue. In this way I can change course or work on convincing the other party this is what needs to change.

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

#152

Post by jordigh »

bjourne wrote: post #42

John Johansen will survive. Linus has made it incredibly damn clear what "no user space regressions ever" mean. See f.e the similar rant from 2012: https://lkml.org/lkml/2012/12/23/75 And it is his kernel so it is his rules. John Johansen admitted he messed up ( http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02539.html ) and promised to handle things better in the future so all is well.

> John Johansen will survive.

We really need to stop excusing Linus's behaviour. Just because we may happen to agree with what he is saying doesn't mean we also have to agree with how he is saying it.

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

#153

Post by majewsky »

EGreg wrote: post #97
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.

Some contracts are so complicated that we need 100-page RFCs to express them. What makes you think we can express these in a regular type system? (Unless you use Idris or Coq or something like that.)

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

#154

Post by jordigh »

pdkl95 wrote: post #147
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…

> software developers always want to have the freedom to “improve” their own software Developer can still have that freedom in most[1] situations. When you have a new idea for a better/faster implementation that is, unfortunately, incompatible with the existing interface, you can usually provide compatibility with a shim that implements the old interface using the new interface . Sometimes this is little more than so…

> Sometimes this is little more than some #define renames and a handful of very-thin wrapper functions.

That's more or less the thesis of Steve's blog post too.

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

#155

Post by olewhalehunter »

leeoniya wrote: post #122
bjourne wrote: post #42

John Johansen will survive. Linus has made it incredibly damn clear what "no user space regressions ever" mean. See f.e the similar rant from 2012: https://lkml.org/lkml/2012/12/23/75 And it is his kernel so it is his rules. John Johansen admitted he messed up ( http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02539.html ) and promised to handle things better in the future so all is well.

> Linus has made it incredibly damn clear what "no user space regressions ever" mean out of curiosity, how does a policy like this translate to microkernel OSes (e.g. Redox) where most everything runs in userspace?

shhh just get out the popcorn and enjoy the rantings of an egomaniac who wrote a glorified DOS extender for an outdated time-sharing system

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

#156

Post by chrisper »

sytse wrote: post #126
bjourne wrote: post #42

John Johansen will survive. Linus has made it incredibly damn clear what "no user space regressions ever" mean. See f.e the similar rant from 2012: https://lkml.org/lkml/2012/12/23/75 And it is his kernel so it is his rules. John Johansen admitted he messed up ( http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02539.html ) and promised to handle things better in the future so all is well.

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.

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

#157

Post by lmkg »

delroth wrote: post #45
wolfwyrd wrote: post #43

Earlier quoted context omitted.

It's laid out further in the thread [1]. The key quote comes from Thorsten: > All that afaics doesn't matter. If a new kernel breaks things for people > (that especially includes people that do not update their userland) > then it's a kernel regression, even if the root of the problem is in > usersland. Linus (CCed) said that often enough [1] http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html

Does that mean the kernel is not allowed to change version number anymore because I could write an app that segfaults if it sees Linux >= 4.14?

When the Opera browser updated from 9.60 to 10.0, they found that some sites stopped working because they blocked user-agents with low versions of Opera... and they checked versions by looking at only the first digit after "Opera." So version 10 looked to them like version 1.

Opera "fixed" the problem by having version 10 report itself as version 9.80 in the user-agent string.

Because time is a flat circle, the same thing happened when Microsoft was planning the successor to Windows 8. Too many programs saw "Windows 9" and thought the OS was Windows 95 or 98, and tried to use outdated versions of APIs (or refused to launch). So Windows skipped a version and that's why the current version is called Windows 10.

So to answer your question: There is precedent for that scenario.

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

#158

Post by tsilva »

delroth wrote: post #45
wolfwyrd wrote: post #43

Earlier quoted context omitted.

It's laid out further in the thread [1]. The key quote comes from Thorsten: > All that afaics doesn't matter. If a new kernel breaks things for people > (that especially includes people that do not update their userland) > then it's a kernel regression, even if the root of the problem is in > usersland. Linus (CCed) said that often enough [1] http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html

Does that mean the kernel is not allowed to change version number anymore because I could write an app that segfaults if it sees Linux >= 4.14?

Another example is what happened when Linux moved to 3.0; some programs expected a 2.x version, or even 2.6.x, these programs were clearly buggy, as they should check that the version is greater than 2.x, however, the bugs were already there, and people didn’t want to recompile their binaries, and they might not even be able to do that. It would be stupid for Linux to report 2.6.x, when in fact it’s 3.x, but that’s exactly what they did. They added an option so the kernel would report a 2.6.x version, so the users would have the option to keep running these old buggy binaries. Link here.

From: https://felipec.wordpress.com/2013/10/07/the-linux-way/

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

#159

Post by steveklabnik »

majewsky wrote: post #146
steveklabnik wrote: post #108

Earlier quoted context omitted.

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

This is a thing I've been wondering about. Is dynamic linking (in the way that C/C++ programs use it all the time) not a usecase that Rust wants to cover?

You can do dynamic linking, you just can't do it across compiler versions. This is how all of the Linux distros are doing it, for example.

It's a spectrum:

Rust: recompile the world when you update the compiler

C++: recompile the world when you change ABIs or when the ABI changes (My understanding is that MSVC++ changes the ABI every ~2 years? I could be wrong.)

C: never recompile the world

It's not that we don't want the benefits of a stable ABI, but it's a monumental task, and there are more important things for now.

Don't forget that you can get a stable ABI today by using the C ABI. You just lose out on the fancier features Rust has.

Post reply on HN