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 something for some users (and worse, even telling users that they shouldn’t have been doing that in the first place).
I keep going back to this blog post which I wish more people agreed with (Steve Losh is another person influenced by Mercurial):
"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 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.
With full backward compatibility, you agglomerate features, and changes are implemented as optional, with the default being the old behavior.
You can add layers that depend on existing code, but you cannot make existing code depend on those new layers.
/me runs ...
My comment was intended to be a wry one referencing those very interesting discussions and hinting that if you have types then you can more easily make breaking changes internally that aren't visible externally.
Who's "we"? I'm talking about changing the implementation.
> Did you watch the video segment?
I watched the bit where he said if you add a constructor to a sum type you have to change everywhere it's pattern matched. True. I'd love to see Clojure's solution where you don't have to change any existing code!
EDIT: Oh wait, I think it's even worse than that. I think he's talking about product types. In which case you should use projection functions and indeed you need to make no changes to old code!
1 - Not all changes can be kept internal, for example adding a new case to an ADT
2 - Internal changes can still alter the semantic of the API, even if from the outside everything still looks the same from the type system point of view
It is "possible" that my blowing my nose will disturb butterflies in China.
Internal to the organization that produces the software, they are highly meaningful. Extended to user base that reads the documentation, it remains equally meaningful.
Downstream that resists information and can not be controlled is on its own. Good luck.
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.
It matters less, IMHO, the further up the stack you get.
Being right at the bottom of every stack it matters most of all for the kernel, which is why Linus needs to be such a stickler. The amount of damage you can do by breaking userspace is vastly greater than the damage you do removing an hg command.
Of course, they are never at the level of a Python 3 release.
How does Linux manage to never break its API? For example in the event of a refactoring.
If you look closely at the kernel code it is easy to find two or more syscalls that have names and behaviors that are very similar, but where one is recommended above all the others.This is because the older syscall(s) were found to be flawed.
But rather than break existing software, they introduce a new syscall that fixes said flaws and leave the old one intact and recommend that in the future software use the new syscall.
It seems to me a lot of it boils down to "who gets impacted". If I have a bug in my kernel and a lot of apps are somehow relying on it, I need to be mindful of that and perhaps swallow the purity of the contract in order to provide a pragmatic fix.
Developer can still have that freedom in most 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 about his OpenGL 1.3 -> OpenGL ES 1.1 header.
 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!
 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)
That's more or less the thesis of Steve's blog post too.
In these cases, a Zero Regressions policy is a bit silly. You can flip things around and look at the new code as baseline and from that perspective the old code has many more regressions relative to it.
There seems to be a pretty stark divide between these mindsets.
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.
This explains the Rust approach:
They literally run all tests against every crate published to the package ecosystem. That is amazing.
But the idea is far from it. Commercial compilers probably had this more than open source ones in the past. Though, oddly, it was probably a weakness in some respects, since it almost certainly slowed feature development/releases.
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.
This is only half true: every new release, the ABI of the runtime library changes. But the Visual C++ compiler ABI hasn't changed in decades.
If you design your own library ABIs so they don't pass std::foobars around, you can link C++ libraries built with VC++6 with ones built with the latest version, and the whole thing is going to work fine - the trick is that multiple versions of the runtime DLLs can coexist in the same process.
GCC/libstdc++ hasn't changed its ABI in more than a decade, since release 3.3 or 3.4; they even did incompatible changes to std::string in GCC 5 without breaking ABI:
Or have their been issues with minor releases? I haven't come across any I can remember, but I might be wrong. Maybe some things were deprecated and then removed?
Behavioral changes happen, and maybe we don't even support some
feature any more. There's a number of fields in /proc/<pid>/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 not
see everything they used to see, and so behavior is clearly different,
but things still _work_, even if they might no longer show sensitive
(or no longer relevant) information.
I'm not sure I prefer the described result. If my application depends on some of those zero'd fields, it seems like that has potential to cause serious debugging problems, as opposed to just causing an error on the parse.
if your app didn't used to handle the 'zero' case (assuming zero was a "valid" value for said field), then the app was poorly written and would'be been broken in the first place. However, if the app _did_ handle the 'zero' case, then the app continued to work! The end user would've been none-the-wiser about the change (mostly), and some time later, the app could be upgraded to ignore those known fields.
Causing a parse error would mean the app stopped working altogether. Much worse a result for the end user.
Because you had to handle the zero case before right?
The idea is that in the worst case you get an error message, not an altogether crash.
If you present this argument to Linus, you will certainly get yelled at.
Not breaking the user space means not breaking the user space even when it's broken. A couple years back glibc broke Adobe Flash because Flash used memcpy wrong. Linus was quite vocal about it.
I love the 'Raymond Chen Camp's way of looking at things. xx
If they want desktop Linux to happen, they need to stop chasing eyecandy and stabilize the plumbing behavior, no matter how much that thought offends their developer pride.
Also, I think bigger challenges to desktop Linux are the degree of configurability, drivers (maybe that's better), and the fact that the GUI is never a first-class method of using the app but instead a hastily-written wrapper on top of a command line tool.
Succession is a weird concept with linux but the fact that it has always been more stable than the other OS' is I think the main reason it is been so successful in the internet age.
An example of a failed succession is Tim Cook; the guy is the complete opposite of Jobs. Just take a look at the apple website nowadays. A product guru would not sell three generations of iphones that are all cannibalizing each other and lack any real differences.
However, Rust is linker compatible with C, and can be runtimeless, so rewriting the kernel piecemeal over time instead could be great. ;-)
It's always been well understood the the same people who are typically good are starting companies aren't typically the best people to run them once they achieve a certain scale.
Wow. Now that's how you do an apology. If anything my confidence in this guy is increased.
Yeah, this is a _very_ professional response to a (typical for Linus tbh) very emotional (but correct) post that could be easy to react emotionally to.
There are ways to use that language without being a prick about it though. Linus does not have that ability.
out of curiosity, how does a policy like this translate to microkernel OSes (e.g. Redox) where most everything runs in userspace?
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.
> trying to shift the regressions somewhere else is bogus SHIT.
That's accurate and specifically points to the unacceptable behavior that needs to be fixed. Linus's "WE DON'T BREAK USERSPACE. EVER." policy is well known, documented, and mentioned frequently. It's reasonable to expect anyone submitting patches to understand this, which makes trying to shift the blame elsewhere... well... "bogus SHIT", regardless of the specific words you use to describe it.
> I will stop pulling apparmor requests until the people involved understand how kernel development is done.
Note that Linus is specifically indicating that this is fixable. Given John Johansen's very commendable apology (see link in grandparent comment), it looks like the message was understood. I suspect this will work out much better in the future.
edit: Diluting language to make it "nicer" can remove important information. See: "How a plan becomes policy" https://funnyshit.com.au/the_plan.html
The rule of thumb I've seen in your typical management oriented business books ( eg, your books / training like Crucial Conversations: https://www.vitalsmarts.com/crucial-conversations-training/ ) is to be "persuasive, not abrasive" as that site says. The issue with being abrasive is that one way people might react is by instinctively attacking back -- no matter how technically correct you are, f-bombs and personal attacks might tempt others to throw counterpoint f-bombs and personal attacks back. Another is that repeated behavior along these lines might drive away some people who would rather not see profanity and anger in their mailbox.
Everyone loses their temper occasionally, and John Johansen reacted in the way you should to someone who loses their temper.
Unfortunately, the Linux community as a whole has a reputation in some circles for being overly "hostile" and "toxic". Linus himself has this reputation. How much this reputation dents Linux contribution and usage isn't known, but I doubt anyone can say that this is a positive.
If you're driven away from having the job of transforming specific concrete direction into action for a large important organization then you should probably find a different job. Not everyone needs to put up with that, although if you have ambitions as a manager of people it will probably be career limiting.
The only strange thing about the Linux kernel is how it's all done in public instead of face to face.
Except that it is still being used unlike the other "nice" projects. BeOS. For example.
What I know is that I've never read advice geared for managers which states that the route to success comes from being an abrasive boss.
I don't see how this is a personal attack. I call the quoted comment a plainly-stated critique of a developer's portfolio. If you have repeatedly demonstrated a problem following basic requirements (ref: "denying the regression now for three weeks"), that's a good reason to presume problems might exist (i.e. "your code cannot be relied upon"). Linus tends to write this type of "blunt" letter only after other ("nicer") attempts have repeatedly failed, and a pattern of problematic behavior exists.
Accurately describing someone's reputation based on their actual work and behavior is not a personal attack. Without false claims - aka actual slander or libel - you earn your own reputation which other people can and will include in their opinions about you.
> The profanity is also unnecessary.
I don't see any profanity in the quoted comment.
> the Linux community
...is another matter entirely, and a discussion for another thread.
From my viewpoint, the problem with the personal attack is the overreaching scope and the hostile wording, not necessarily the critique. It is easy to be firm about laying down the rules of development without getting into the realm of "your entire code and opinion".
There is absolutely nothing wrong with his later post on this in my opinion ( http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html ) and I don't think he's any less firm about the development rules here.
This is the Sphinx asking you an easy question, and if you don't simply give the correct answer she helpfully provided in advance, you get burned to ash. You don't get to stand there arguing, and you certainly don't pass through. Instead complaining about it while someone is still doing it, learn to become so principled where it matters for the time when he can't do it anymore. That's infinitely more important than not swearing if you're older than 6. Have you looked around the world you're living in? Plenty of nuts people with plenty of vested interests. Plenty of weak people feeding them. If "not hurting feelings" is a priority to you, you are a hostage to those who will fake feelings until the cows come home. In turn you do not get to hold those hostage who see through it.
How much of what people use, how much profit does Linux enable? But oh no, the bad man is swearing. Unbelievable. Uninstall everything that has traces of it in it, but spare me your advice on what I need to "stop excusing". There is no aggregate by the way, "we" doesn't have to agree with anything because it doesn't exist. I have my stance, you don't even propose yours.
Linus is still a dick and it isn't funny, refreshing or cool.
There's a thicker-than-fine line between being hostile to new contributors and being unkind, and tolerating bad practices from people who ought to know better.
And behavior can be changed.
If someone criticized your code, taking it as a personal attack is YOUR problem. If your behavior is criticized, it means you can improve: acting like a fool may not mean you're a fool. It's on you to disprove it.
If this was some Joe Schmo at a random company he'd be fired for treating co-workers like that. Since it's Linus it's hero worship.
Acting out is actually dishonest and it's mostly about a hidden message. It's a failure to recognize and deal with your won frustrations which you then take out on others, usually when an opportunity presents itself to rationalize your behavior - someone does something you perceive as wrong, so they become a justifiable target for the anger that's already there. What I read in the email's message is, 'I'm out of control, I'm not able or willing to mange my emotions, so you better watch out'. That is a poor management and communication technique.
IMHO, a leader or manager should hold their leadership and management work product to the same standard that they hold their subordinates' technical work product. If they want the highest standards for the kernel code, they need to have the highest standards for their communication and other conduct.
A great challenge of being the boss is that there is nobody to hold you to high standards; you have to do it yourself and that's not something people are good at. As they say: Power corrupts, and absolute power corrupts absolutely. Clearly, this message could have been communicated much more effectively - while being truly honest and without hidden messages or room for interpretation - if the communicator chose to make an effort.
Finally, if this form of communication is effective, do others communicate to Linus in this manner? Does he ask them to?
- Speaks in platitudes about the topic in a way that shows a thin understanding of the context and only sounds smart to people that also aren't familiar with the context.
- Armchair psychiatry used to advance a moralizing message.
- All over the place while deep in a comment thread, seemingly more interested in hearing themselves talk than carrying on the conversation.
I considered those things myself before I posted it. However, I didn't see how to overcome them; some issues don't lend themselves to strong factual bases, and some are much more nuanced than can be addressed in a few words - issues such as leadership - and yet they still are important enough to discuss. The problems of the world don't always conveniently fit our model of how we prefer to address them. How else could these issues be addressed?
> It's a cliche hacker news comment
This I strongly disagree with; these issues are rarely addressed with much serious thought and that's one reason I posted it.
We're happy to unban accounts if you email us at firstname.lastname@example.org and we believe you'll post civilly and substantively in the future.
>That's obviously not happening with his attitude.
Seems he's making a lot of things happen with his attitude as evidenced by the thread that was linked.
I'm not selfish enough to want something to work for me and only me, thank you. That's why I submitted a bug report.
And that ends up just providing another reason why Linux is a crap OS - everything is done entirely backwards as if everyone on the team learned their entire education the same way RPN is written.
And he only responded this way after 3 weeks of unacceptable behavior. If he blew up out of nowhere after the very first report of a potential problem before it was even confirmed, that would be a different story (though that's something that probably happens in real companies every day).
I think you must have worked for some horribly unprofessional companies. I've worked places with tight deadlines before, but berating your colleagues or employees with profanity is just ridiculous. I would walk out on the spot if anyone spoke to me the way Linus did in that email.
I have for sure, but the worst of those companies was better than fortune 5 (if I said exactly, you'd know which company), so while primitive they obviously manage to get results that coddling hasn't.
EDIT: And as for walking out, if I were your manager and you broke customer systems and made excuses for 3 weeks about it I wouldn't be yelling at you. I'd be firing you.
The problem was fixed; nobody was harmed; lessons were learned. The sum total of effect of this "Linus tirade" seems overwhelmingly positive. But just because he didn't conform to your arbitrary standards, you write him off?
Linus is more humanist in this case than your policy apparently allows.
You stupid, mouthbreathing motherfucker. How can you sit there and say "nobody was harmed"? I was harmed by having to read that word-vomit, and I've been further harmed having to respond to your boundless idiocy. You have no idea how many people have been put off working on open source projects because they'd rather contribute nothing than have to interact with human shitstains like yourself or Linus.
How's this for a positive comment? Jesus Christ I hope I never have to work alongside a worthless rat bastard like you. Your family should be ashamed to have raised such a sack of shit.
[Look how clear and direct I've been! Isn't it great!]
A major difference between your comment here and Linus' rant is that Linus didn't deliver personal attacks. Notice how all his vitriol is aimed at the code and not the person:
"Stop gthis (sic) fcking idiocy", not "You are an idiot"
"You trying to shift regressions somewhere else is bogus SHT", not "You are bogus sh*t"
Your comment on the other hand is mainly full of empty name-calling. Besides the fact that it accomplishes nothing, it's a personal attack instead of a clear message that "XYZ behaviour is Bad!"
That said, you are indeed indirectly evidencing that a good many people have trouble seeing a difference.
I'm trying to highlight that maybe it's not so great if you're on the receiving end of it.
I'm sure a bunch of hypocrites will flag me down, though.
I couldn't agree more.
More than ten years ago I was involved in the Monotone project. It was a VCS which was an ancestor to Git and a contemporary of Mercurial.
That project really prioritised good conduct, and having a well functioning community. It was a huge awakening for me. Insisting, gently, upon respectful and kind behaviour made it a project I'm proud to have been a part of.
I'm still grateful to graydon, pcwalton and all the other folks that made it such a great project to be involved with. In free software we need more leaders like that, who set the right example.
Respect and kindness are great virtues when you're shipping widgets. If your product failing means that end-users are going to physically suffer and/or die, I don't think they're going to care one bit about those virtues or respond in kind though.
I'm not saying you can't run a big project without kindness and respect, but I'm saying that's way down the list of importance vs not harming your users. Whatever it takes to get that chief goal accomplished needs to be done. Linus' approach has clearly been working for decades now...and it especially is in this instance.
We tend to excuse people for being bratty assholes when they're smart and correct. Which Linus was here.
Doesn't make it right but it's not just a Linus problem (I mean, generally), it's a people problem.
We need more behavior like this. The reason why the modern software tend to be a pile of garbage is because it is managed like popularity contest of the project managers instead of people who want to get shit done.
Plenty of other projects out there to hack on if getting yelled at when you disengage your brain is too much. Most of which don’t have the obsession with not breaking stuff for the end user...
Isn't this just swearing?
> the only thing keeping garbage code out of the kernel.
I'm not sure if I'm buying that. It's possible, sure but on the other hand: It's not because the other way (i.e. communicating in a nice way, without all the swearing and direct attacks - which is imo not the same as direct communication) hasn't been tried that somehow proves it won't work.
E.g. I know repos where one maintainer is kind yet gets things done, and another one seems to have borrowed his communication style from Linus and gets less done. Because people just give up, being sick of being yelled at in an unpolite manner. Is it that hard to be respectful, even when disagreeing?
Linus is no role model. His imprecations are not what make Linux work.
(if A then B) AND (if not A then not B)
That's causation, surely.
> Every day, the rooster crows and the sun rises; that's not correlation.
Why not? That's literally (if A then B) according to your definition.
And we're trying to deny that his behavior is even correlated with Linux' success?
If someone prefers softer conduct, they are free to fork the kernel and start their own efforts.
The big issue I see people reacting to is profanity. You can be as hard on someone, given the nature of the infraction, without using profane language or denigrating someone.
If they don't comply, threaten exactly what Linus threatened, no more commits will be accepted.
While I don't disagree with Linus' right to speak as he does. He can be just as effective without the type of language he uses.
Some people don't care about "foul language" some others clearly do...
I feel it is imperialist for people from one culture to want people from other cultures to adhere to their way of communicating.
Culture ownership is a thing, and Linus and team were there first. Oncomers need to adapt, or go elsewhere. They certainly don't need to provide this constant distraction.
I don't think that would be a good argument to make from either perspective. If people who choose to leave the community don't contribute you can't really measure lost contribution.
That not being the crux of the issue, we should focus on the following.
Just because a product is successful does not mean that the abuse that happens during development of that product is good or okay. And I think that's really the gist of what people are saying.
It exists and is perpetuated in a culture's lex lingua precisely because it is an effective tool.
Expletives like this cut right through rational and emotional filters to trigger exactly the kind of response Linus was looking for -- after three weeks of arguing, the guy finally realized his mistake.
> It's telling a contributor that their contributions are worthless, cannot be fixed, and other ad-hominem angry insults that just fosters a macho, jockish atmosphere in Linux that has demonstrably alienated capable contributors.
I'll quote bits one at a time.
> It's telling a contributor that their contributions are worthless, cannot be fixed
What if they are? How do you handle the situation?
> and other ad-hominem angry insults
I would argue that saying some patch is worthless and cannot be fixed isn't ad-hominem.
But I'd like to get your view, since it seems you've read a lot on the topic and care about the OSS community.
(Edit: As an aside, my personal policy in this regard is temperance in my reaction, and this is especially easy when written.)
Linux is a project of such a massive scale that Linus has to accept kernel commits from circles of trust in his developer community. If someone demonstrates that they don't understand the fundamental goals of the project, and their contributions are accepted largely based on trust, then yes, their contributions are effectively worthless.
They have to be moved to a further out circle and have their work filtered up through others, and you have to second guess every piece of work that they've contributed.
I agree with you completely, but I can see how this can be accomplished, i.e. removal of trust and correction (public at that) without the need to demolish the person him/herself.
I think we can both agree that it's a fine line though.
Personally, "losing your temper" (i.e. something you have to apologize for later) is something that should be relegated to children. Adults should exhibit self-control in this regard.
You can get the "job" done without this. Some have to work harder at it than others. But saying that it's just okay to denigrate others is not correct.
I don't see this particular rant in question to be a personal attack though. Personally, I don't see a macho, jockish atmosphere to the Linux kernel community either. Also, I'm also not particularly concerned whether an environment is cultivated where anyone feels they can contribute. People contribute to the kernel out of need as well as want.
To directly address the part of the comment about otherwise capable contributors (and the Sarah Sharp example): There's multiple kinds of capability. Technical capability isn't the be-all, end-all in this industry. In fact, I think most of us would say that soft-skills are what differentiate high levels of success in this career. If a company's management culture disagrees with you, then you aren't capable of contributing in that atmosphere.
It's not a matter of either party being to blame but a matter of fit between two parties working towards a mutual goal. I don't think it's remotely fair to say that it's solely Linus's responsibility to facilitate a culture where anyone can feel comfortable contributing. Especially with a project as fundamentally necessary where people will have to contribute, regardless of the culture. If someone's incompatibility with the culture trumps their need to work in it, then yes, they should part ways and that should be perfectly okay.
The same applies to personal relationships, marriages, etc. I think it's good to step back from things from time to time and realize that, ultimately, you're dealing with people and they're not always going to value what you value and they're not always going to give you what you want.
Linus is BDFL. That's all you need to know in four letters. Why are people trying to give ultimatums to God? Seems pointless.
That's not the choice; there are other, more effective ways to produce quality code; they are well known and well tested. I would expect that Linux loses more quality code, from contributors who have better things to do than deal with unprofessional behavior, than it gains.
The evidence doesn't bear that out. I would expect more contributions from experienced developers who don't care about the words used in kernel mailing list discussions.
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.
According to Linus: THE KERNEL NOT GIVING THE SAME END RESULT WITH THE SAME USER SPACE
According to Wikipedia: A software regression is a software bug that makes a feature stop functioning as intended after a certain event (for example, a system upgrade, system patching or a change to daylight saving time).
Seems like the two definitions are similar. There's no requirement that the defect be one that was seen earlier, fixed, and then reappears.
No, it's when a change results in unintentional behavior that breaks previously supported scenarios. You might want to double-check your definition. I think you're actually referring to a recurring issue.
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, and with these restrictive policies it's causing daemons to crash (because it gets auto-denied).
The whole point of these policies is to not expose new attack surface if it's not needed by the software. It's going to break whenever AppArmor will start supporting more checks, unless policies get pinned to a specific version of AppArmor. But AppArmor doesn't currently support this (they refer to it as "features ABI" in the thread).
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".
[ 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.586888] SELinux: the above unknown classes and permissions will be allowed
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.
On the other hand, if it's bad enough it certainly makes sense to treat it as a kernel bug. The difficulty lies in finding where to draw the line.
> 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
You're welcome to assume forever that there will be a version field, if it ever becomes the case that this simply makes no sense anymore then a sensible dummy value will be placed in
 - http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
"There's a number of fields in /proc/<pid>/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."
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.
It's clearly an error on the part of the kernel if the owner of said kernel has specific expectations of behaviour on upgrade with respect to user spaces and those are not being met.
The contract in this case is that there will always be a version number, and anyone who expects it not to change is an idiot or just being obtuse.
> anyone who expects it not to change is an idiot or just being obtuse
If this was the case, Microsoft would have never had to skip from Windows 8 to Windows 10 (see below in another comment: "starts with Windows 9" was used in the wild to detect Windows 95/98).
> anyone who expects it not to change
And you appear to be using an example of a version-change curiosity as a counterexample. It is not a counterexample, because the version number in question changed from 8 to 10. In my original formulation, anyone who claimed to worry that the number would stay 8 forever was being an idiot or being obtuse.
I think that holds up. It was not part of my comment, but someone who expected it to be 9 would not be an idiot or obtuse, because that would have been a reasonable guess, absent additional information. They were expecting it to change but were surprised by an exceptional circumstance.
But this is getting a bit silly; there may be someone out there who thinks version numbers should be immutable across versions, but I bet they're pretty lonely. It was an example picked up while making a wider point.
So yes, if you had a significantly deployed app that segfaults because the version number >= 4.14, Linux probably would seriously consider workarounds for your app.
Damn it, you can still install Windows 10 in 32-bit form on a modern x86 CPU and expect win16 binaries to work.
The only reason there is a problem with the 64-bit form is that AMD made the 64-bit mode and the 16-bit mode mutually exclusive. You can jump from 64-bit to 32-bit mode, or from 32 to 16, but not from 64 to 16.
The problem is that apparently this is true for all of OpenSUSE, Debian and Ubuntu, and that's when a userspace bug becomes in practice a kernel regression.