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

141–150 of 408 posts

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

#141

Post by majewsky »

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.

> there are no major, minor, patch level changes, in reality every change is a possible breaking changes

I noticed this when recently writing a spec that defines backwards-compatibility. There's surprisingly few things you can do when you want to stay backwards-compatible.

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

#142

Post by saw-lau »

emodendroket wrote: post #89
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…

Perhaps, but what if the app developer is long gone, and I am a user hoping to keep using my favorite program? Apparently the original Raymond Chen article is gone but I think this quote captures it: https://news.ycombinator.com/item?id=14202707

This is also quoted in a Joel Spolsky's article:

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

I love the 'Raymond Chen Camp's way of looking at things. xx

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

#143

Post by emodendroket »

magnetic wrote: post #137
chrisseaton wrote: post #113

Earlier quoted context omitted.

How do they handle bug fixing though? What if one application wants a bug fixed, but another application is depending on the bug inadvertently?

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.

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

#144

Post by fauigerzigerk »

alkonaut wrote: post #86

> "We simply do not break userspace" Wish this would be a goal for more of the application environment on Linux than just the kernel.

Indeed. I upgraded a Ubuntu installation a while ago. The network just stopped working because the developers of NetworkManager had decided that NM should no longer manage wired network connections on some Ubuntu configurations.

That is just a crappy attitude and I have to say NetworkManager is generally one of the buggiest and most unreliable pieces of software I have ever used. And I'm actually making a great effort to be polite here.

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

#145

Post by majewsky »

Cshelton wrote: post #125
lmkg wrote: post #114

Earlier quoted context omitted.

Rust also uses a sizable fraction of all publicly-available Rust code as a regression suite for compiler updates. This allows them to check edge cases that are "breaking in theory" to find out if there's actually any code that would be broken, or if the edge case had literally not yet been encountered.

By sizable fraction, he is referring to Cargo.io, Rust's public package repository. They literally run all tests against every crate published to the package ecosystem. That is amazing.

Makes you wonder why no-one else came up with that idea before. I mean, it is pretty revolutionary, but also really obvious in hindsight.

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

#146

Post by majewsky »

steveklabnik wrote: post #108
snuxoll wrote: post #106

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.

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?

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

#147

Post by pdkl95 »

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 some #define renames and a handful of very-thin wrapper functions. Occasionally it will be a bit heavier, which might make the legacy interface slower, but this should be balanced (approximately) the faster underlying implementation. If the compatibility shim is significantly slower (or has other unavoidable runtime issues), an upgrade that is slower for legacy uses that still works is always better than breaking existing code.

For an example and opinionated discussion, see JWZ's post[2] about his OpenGL 1.3 -> OpenGL ES 1.1 header.

[1] Exceptions are cases where there is a *fundamentally unavoidable cost to providing the interface (e.g. where N is the total number of interface entry points, something in the critical path unavoidably MUST take >O(N) time or space, or N is limited externally to a small value ("we only have silicon for at most N instructions"))

edit: [1b] Another exception would be when the legacy interface itself is a serious security problem. If your legacy interface unfortunately forgot to include a way to supply credentials and simply accepts writes from anyone, a prompt fix that breaks that API is necessary and appropriate. Next time you're designing an interface, be sure to remember that security has to be baked in from the very beginning!

[2] https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-... (you might want to copy/paste that URL if your browser betrays where you came from with a Referer header)

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

#148

Post by drzaiusapelord »

piker wrote: post #38
__david__ wrote: post #24

Linus's followup post later on in the thread explains his position in more detail and is a pretty good read: http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html

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…

Well, it only returns numbers, so padding retired calls with zeros should really break anything other than giving the wrong data. The only other practical alternative is to return 0 bytes and most likely crash the application expecting a result. How many old school apps making invalid stat calls are engineered enough to handle odd exceptions like this? I'd say probably few to none.

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

#149

Post by lightedman »

"a return to a former or less developed state."

See, it's the fact that Linus doesn't even know the real definition of 'regression' that makes me think I cant' trust him or anything he produces. That level of idiocy is simply intolerable.

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

#150

Post by majewsky »

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 a huge number of Python modules are both valid Python 2 code and Python 3 code.
Post reply on HN