61–70 of 408 posts
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.
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…
As much as I think the general principle of "no userspace visible change" is great, I can't make up my mind on whom I agree with the most in this specific instance. My understanding is that some distros (e.g. OpenSUSE) ship with AppArmor in a whitelist mode where things have to be explicitly permitted by policy, otherwise they're denied by default. AppArmor introduced a new class of actions that wasn't there before,…
The convention provides organizational efficiency. This is an example of Torvaldes saying exactly what everyone knew he would say about the technical issue and knowing exactly what Torvaldes would say about the technical issue means core developers don't have to waste his time asking him and the feature developers don't have to waste the core developers' time asking them and those with limited commit rights don't have to waste time debating with people submitting outside patches.
In the end, having a clear principal pushes people predisposed to argue their nonconforming point of view is valid or better toward the periphery of the kernel community because the behavior is deemed unproductive. The community operates because there is trust that people won't waste each other's time. That's the violation here...e.g. "three weeks".
Earlier quoted context omitted.
It's interesting to see how it works with SELinux. The Fedora distribution upgrades to a new kernel version often, so after a few months you start seeing lines like these in the kernel log: [ 14.586798] SELinux: Permission getrlimit in class process not defined in policy. [...] [ 14.586887] SELinux: Class infiniband_pkey not defined in policy. [ 14.586888] SELinux: Class infiniband_endport not defined in policy. [ 14…
That's not good from a security point of view but I guess it does avoid breakages.
It is. You get the security you explicitly ask for, no more, no less. If you want more, you get to know what new is there, and enable it.
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?
Eli5, What is kernel regression? Does he mean breaking backward compatibility?
Linus then calmly and politely reminded him that the official policy of kernel development is that they never introduce changes that break applications.
Eli5, What is kernel regression? Does he mean breaking backward compatibility?
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.
It's like Fight Club, except instead of fighting all the characters keep asking Brad Pitt's character why they can't perform a one-man show on Broadway about fight club.
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…
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...
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…