Eli5, What is kernel regression? Does he mean breaking backward compatibility?
regression = "it worked before, it doesn't work anymore"
A regression is the kernel not giving the same result with the same user space
111–120 of 408 posts
Re: A regression is the kernel not giving the same result with the same user space
#112I'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.
The problem is that often things are not so clear-cut... what seems like a fuckup at first glance or from one perspective might be something different (perhaps one thing is messed up but it was to fix another thing, or perhaps you are mistaken and things are just different but not "fucked up", etc). As soon as you start shouting at someone, they will tend to get defensive and dig in their heels, thus making it more difficult to get to the bottom of what actually happened and why.
For most of us in software, our jobs are not saving lives or anything -- it's not worth creating a toxic culture just so you can feel good about yourself by shouting at someone.
Re: A regression is the kernel not giving the same result with the same user space
#113Earlier quoted context omitted.
> 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.
I mean, is the answer really that hard? If the "refactor" would break the interface, you can't do it. Maybe you deprecate the old method and make a new one.
How do they handle bug fixing though? What if one application wants a bug fixed, but another application is depending on the bug inadvertently?
Re: A regression is the kernel not giving the same result with the same user space
#114Earlier quoted context omitted.
If only compiler developers had this attitude.
I think Rust has done this quite well, managing to have the best of both worlds. Unstable features are only available on the nightly build and need specifically enabling (and their interface may change). Once a feature is considered stable it is carefully maintained. They do have some breaking changes, but they're not common and for unusual edge cases: https://killercup.github.io/bitrust/ This explains the Rust appro…
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.
Re: A regression is the kernel not giving the same result with the same user space
#115Earlier quoted context omitted.
How is it normative? Although that's a bit of a rabbit hole, since presumably you won't allow me to appeal to the definition of 'normative'. Torvalds lambasts a developer for making a mistake, swears at him, and tells him the first rule of kernel development is that you don't make mistakes. Great.
He lambasts the developer not for making a mistake, but for making a mistake and refusing to admit that this is a mistake. That is very different.
Probably also worth specifying that it's not just any developer, but a maintainer. Accordingly, it's reasonable to have higher expectations of mistakes with respect to "The First Rule", let alone acknowledging them as such.
Re: A regression is the kernel not giving the same result with the same user space
#116Mercurial, 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…
For various reasons I would not go back to Java, but that was wonderful, your very old code still worked with newer versions, nothing broke during upgrades (even when behind deprecation one version).
Go is really good about this too. It's great.
Re: A regression is the kernel not giving the same result with the same user space
#117Earlier quoted context omitted.
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 ...
What are you trying to say? There are already a lot of explanations for why Clojure is dynamically typed and how it fills its role nicely that way.
Re: A regression is the kernel not giving the same result with the same user space
#118Earlier quoted context omitted.
I think Rust has done this quite well, managing to have the best of both worlds. Unstable features are only available on the nightly build and need specifically enabling (and their interface may change). Once a feature is considered stable it is carefully maintained. They do have some breaking changes, but they're not common and for unusual edge cases: https://killercup.github.io/bitrust/ This explains the Rust appro…
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.
Well, Rust has a stable ABI in the same sense that C++ has a stable ABI: you get a stable ABI if you use an extern "C" and repr(C) layer at the linkage level, or you use the same version of the compiler to compile all your code. It's not ideal for some use cases (though I think not having a stable ABI is the right decision at this stage), but it's not worse than C++.
Re: A regression is the kernel not giving the same result with the same user space
#119Mercurial, 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.
I agree that platforms should stay backward compatible as much as they can. That said, if upstream changes, sometimes you've got to change too.
There should be a mechanism for releasing breaking new major versions. And it is this:
1) Release a new version for all your DIRECT dependents. Ideally they should be subscribed to your updates.
2) After they have had ample time to test it, they will release an update for THEIR direct dependents.
At no time should C update A if C depends on B and B depends on A. In fact, ideally, if C depends on B1, ..., Bn then C will NOT upgrade A until all B's have upgraded. C should push the B's to do it and supply patches.
This means version pinning for all dependencies, my friends!!
The alternative is "dependency hell" or making multiple copies of A to live inside each B.
If some B's are taking their sweet time then it may be better for some C to submit a patch to B's repo, which even if not accepted can be pulled by other C's. The question is who "owns" or "maintains" a B project if they don't react to changes of some of their dependencies. The answer, I think, should be - fork the B if it's not being actively maintained.
Edit: I think HN needs a "reason for downvote" field, perhaps seen only by the person being downvoted. As it is, many downvotes convey very little useful information.
Re: A regression is the kernel not giving the same result with the same user space
#120I'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)
Annoying and hurtful, yes, but at the same time, he's not wrong - you fucked up, you did bad and you should feel bad. The upside of this rant too is that the author is not "fired", as such, but told to shape up or gtfo. In a lot of companies, mistakes are accepted, fixed, and forgiven without adding a bit of emotion to it. I think adding this kind of emotion will have a bigger impact and will make the receiving end d…
How? Really? Ask that to a child beaten up by their parents in the street. I am sure that child won't make the same mistake again. I am not interested about if Linus is right or wrong, many other people have done that already. I am more interested the way that he speaks. I am gonna go ahead and say it. The way he speaks in this email is ugly, wrong, and should never be encouraged. The language we use is important, even though sometimes it takes more effort, love takes effort, good things take effort, and good communication takes effort too. We should at least try to be nice. Otherwise life would be kak.