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 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):
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.
> there are no major, minor, patch level changes, in reality every change is a possible breaking changes
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.
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.
>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 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.
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).
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.
Certain parts of the API once able to respond with a value now just spit out '0', it means that whatever application that used it just continue to work even though that part is deprecated.
> 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!
There are cases where a major change to a software project caused a handful of minor regressions but added new functionality, vastly improved performance in the majority of cases, etc.
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.
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.)
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:
Do they not? It certainly seems to be a guiding principle of C# compiler developers, who have almost always opted to preserve unintended quirks of the compiler/spec rather than "fix" them.
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...
You're missing that Python 3 is clearly labeled as a breaking change? He is talking about changes that are not labeled as breaking changes but do infact break things.
One major breaking release in how many years, clearly announced as such and with parallel support for the old version for a long time (so you didn't just update python and it broke). Fits quite well under "almost never breaks".
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?
Can't edit orig comment...yes I misunderstood the point about explicit breaking changes. I recently watched Rich Hickey's "spec-ulation" talk referenced elsewhere in this thread, which takes an extreme view (tl;dr SemVer sucks and we shouldn't have breaking changes ever), so that's where my mind was. Thanks for the clarity, all.
>
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 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.
Having had to fix a number of production issues where a change happened XX days ago but the code just silently kept going rather than breaking, I’m sorta of the mind to agree with you. I’d almost rather it break hard, so then I know it’s broke and can fix it. Very nuanced situation though and as such definitely not one size fits all.
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
If your code had actually broken with the change to a zero (for example it didn't just report 0 of some resource in use in the log, but spawned an unlimited amount of threads until it crashed or something) then you could have reported it as a kernel regression, and it would have been fixed in another way.
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.
Someone needs to codify this shit for when he leaves. Its surprising that he still needs to scream at people after two decades of kernel work. I don't have a lot of faith that whoever comes after him will be as proud of the kernel as he is given they just inherited most of it.
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.
God, I hope not. Ground-up rewrites (when they even succeed) typically lose features, performance, and security, since they don't have the benefit of 20+ years of correcting mistakes. Plus you lose all your contributors.
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.
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.
Simple. Contrite. To the point. No excuses, just solutions.
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.
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.
Microkernels still need syscalls for usermode to interface with, so it is just as important. Kernels exist to serve userspace, not the other way around. Though, given the relative immaturity of Redox I assume this is less important compared to Linux.
I've never programmed a microkernel OS (and I've only done minimal Linux kernel programming), but I would assume it's even _more_ important, as a single change would impact almost every component of the system.
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.
What behavior? Linus's comments were carefully directed at the bad behavior that needed to be fixed. I don't see any personal attacks. Linus is a manager, and part of being a manager includes putting your foot down when someone is causing problems. Ideally, the situation should be handled directly and unambiguously ("The thing you're doing is incorrect and causing problems. Stop doing that.") before the problems become worse.
> 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.
How about stopping to try to throw wrenches into what he's doing? It's not a hard concept, don't break user space under no circumstances ever, if you do it's a bug. If you cannot understand and know this by heart, don't even fire up your editor, you are not wanted in Linux kernel development. Fork it and PROVE he is not doing it the correct way by spending weeks and months and years of arguing with people who simply will not stop arguing, because you can't tell them to fuck off.
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.
He has previously been unnecessarily insulting, which I don't excuse, but in this case someone caused a problem, and after 3 weeks still does not understand how serious a problem it is. He's addressing it bluntly because that is what is required. He's not being unreasonable.
I agree with how he's saying it. He's being honest. He's letting you know where he stands and what the rule is, without any kind of hidden message or room for interpretation. The other guy? Not being so honest.
No, what we need to do is stop listening to fragile cry babies. If you ever work for a real company with real deadlines you'll get a lot worse than what he gave.
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've seen messages where I thought he went over the top (personal attacks), but this seemed mostly focused on the issue at hand -- didn't bother me. (Not that it would matter if it did.)
> 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.
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.
> 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.
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.
Disagree. It seems like Linus’ acerbic and direct means of communicating is the only thing keeping garbage code out of the kernel. He’s also made his views on “why not be nicer” well known. People need to get over it - his project, his rules.
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...
Everyone excused Johansen's behavior -- which broke Linux for users, until Linus stepped in and told Johansen to stop making excuses for hurting users. Johansen apologized for his mistake. Sniping at the team --
the people doing actual work -- from the sidelines is inappropriate
It's sad that often the only thing that stops a developer from spinning out more yarns of rationalization is Linus coming in and barking the first rule of kernel development at them.
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.
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, 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 principal here is not technical, it is cultural. It exists to prevent the community from having to having to debate this class of pseudo-issue. There is reasonable logic on both sides and the choice of one or the other is somewhat arbitrary. Being part of the Linux kernel community means doing it in one arbitrary way and not the other.
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".
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.586888] SELinux: the above unknown classes and permissions will be allowed
That is, the kernel part of SELinux supports more checks, but since the policy is old and doesn't know about them, they are allowed by default.
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
'''
People should basically always feel like they can update their kernel
and simply not have to worry about it.
I refuse to introduce "you can only update the kernel if you also
update that other program" kind of limitations. If the kernel used to
work for you, the rule is that it continues to work for you.
'''
> There have been exceptions, but they are few and far between, and they generally have some major and fundamental reasons for having happened, that were basically entirely unavoidable, and people _tried_hard_ to avoid them. Maybe we can't practically support the hardware any more after it is decades old and nobody uses it with modern kernels any more. Maybe there's a serious security issue with how we did things, and people actually depended on that fundamentally broken model. Maybe there was some fundamental other breakage that just _had_ to have a flag day for very core and fundamental reasons.
> And notice that this is very much about breaking peoples environments.
So breaking userland is possible if there is literally no other way, but
1. it's the "nuclear option "of kernel changes
2. it will be acknowledged as breaking users's environments
That's one of the specific exceptions he mentions.
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.
i.e. the kernel may not do what it did before but your tool shouldn't crash. It may not have all the info you used to see though ...
He can afford to be politically incorrect because he makes all the decision, and because nobody else than him can make decisions. He is the expert.
There are very few places in software where an expert/engineer have full authority on the development/how things are done/specifications. You often see money/markets/trends take over.
I really wonder what linux will become without Torvalds when he will go away. I hope he already thought about it, because it will really require somebody with huge confidence about what to do.
Most of his current generals are very much the confident type (occasionally even too much so), so I don’t really see a problem there. As long as Linus doesn’t anoint a RedHat employee, things will just keep chugging along.
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 do better.
Pleasantly, the patch author seems to have taken it pretty well and apologized, while Linus further explained his view with a bit less zeal. Looks like a pretty good ending all around.
There's room to talk about how much zeal is too much, but it certainly seems far better than the "silence till firing" approach people describe at some big companies.
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.
Amongst the emotion, Linus essentially says "I'll reject your kernel patches until you acknowledge my point (rule)". I suspect that had more to do with it than the profanity or the emotion.
you would want to work with someone like this? I think he comes off as a giant asshole. there's tons of ways to get your point across and be passionate about your work without treating people this way. if this email came out at any company I've worked at it would be a serious problem, HR involved immediately
no amount of skills gives you a free pass to treat people like shit. I would not want to work with anyone who has this attitude
Linus is such a breath of fresh air. I'll take an honest, emotional, impossible to misconstrue, ass-chewing over the alternatives. Too often there's an avoidance of straightforward, blunt speech that conveys exactly what is meant. I really have better things to do than try to parse nonspecific beating-around-the-bush and deconstruct word-castles.
The emotion definitely shows how angry he is, but it is possible to express yourself without getting angry; to be clear, concise, and impossible to misconstrue.
Ass-chewing isn't generally beneficial as it makes people defensive and potentially angry themselves. The mea culpa is good: "And again sorry, I screwed up, it should not have happened, my perspective was incorrect and I know I need to make it right." This is a great response, defuses the conversation and makes it clear that it's going to be fixed.
As someone who's gotten chewed out before, all it does is leave a bad taste in your mouth and most likely going to quit the company or possibly the project. Honestly, the threat of rejecting future commits and/or rejecting his opinions was by far the best thing in Linus' response, b/c those cut straight to your potential to contribute to the project.
> As someone who's gotten chewed out before, all it does is leave a bad taste in your mouth and most likely going to quit the company or possibly the project.
That seems to be his direct intent, and being angry does help get this point across.
Your comment shows the downside of assholes being effective. People so often have to deal with ineffectiveness, they come to feel happy with anything they can get that works, forgetting that’s it almost always possible to be just as direct, blunt, and compelling with different rhetoric.
Assholism is not the solution to great leadership. It’s one of many techniques leaders use. Some leaders are effective using it frequently, but it’s important to note it’s usually not required because there are trade offs and downsides, both morally and amorally from a pure efficiency standpoint.
> Pretty much the same reason everybody voted for Trump.
"Everybody"? Sanders also said a bunch of things like they are, and he said them politely. Especially factoring in grass roots support, he was more popular than Hillary and would have wiped the floor with Trump.
If you allow your media and "leaders" to sweep people like Sanders under the rug, you make people like Trump inevitable. And then you still don't learn. There can be worse things than Trump, so much infinitely worse; and they will come to pass if you insist on this trajectory.
There are people who have the mental tools for being in a conversation where someone displays anger and aggression [0], and those who don't. One person's world-endingly stressful and uncomfortable interaction is another's colorful productive disagreement.
The people who don't have those tools control the horizontal, they control the vertical too. If they say your personality is wrong by definition, who are you to question them?
Without getting snarky, that's just the status quo right now. In some number of years they'll treat it like a big discovery that their previous assessment of all social interaction wasn't 100% perfect. Let's just hope that when it comes the pendulum swings our way and I get to stop wearing an emotionally-dishonest husk of a personality to the office.
[0] For the sake of avoiding predictable tangents, I mean aggression that is obviously not going to escalate to physical responses, or even anything more than rejecting patches.
For me, it is really the circuitousness that people will go through to avoid saying anything that might be taken as damaging to somebody's feels. It's exhausting, and confusing, and I wish people would just cut the shit and say what they mean.
But my dad was ex-military, then a logging contractor, then a heavy equipment mechanic, and I grew up working with him. When there are firearms, chainsaws, bulldozers, or heavy objects dangling from cranes, you don't have the luxury of couching your criticism in weasel-words or crafting the compliment-criticism sandwich. If somebody is fucking up, you let them know in no uncertain terms, because somebody could get hurt.
Readit News
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):
http://stevelosh.com/blog/2012/04/volatile-software/
"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.
/me runs ...
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.
http://www.oracle.com/technetwork/java/javase/jdk-relnotes-i...
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.
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)
That's more or less the thesis of Steve's blog post too.
Deleted Comment
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.
https://killercup.github.io/bitrust/
This explains the Rust approach:
https://blog.rust-lang.org/2014/10/30/Stability.html
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?
http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
> 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.
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.
Deleted Comment
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.
out of curiosity, how does a policy like this translate to microkernel OSes (e.g. Redox) where most everything runs in userspace?
Dead Comment
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
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.
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 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.
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...
Deleted Comment
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.
Dead Comment
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).
WAI?
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".
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
[1] http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
''' People should basically always feel like they can update their kernel and simply not have to worry about it.
I refuse to introduce "you can only update the kernel if you also update that other program" kind of limitations. If the kernel used to work for you, the rule is that it continues to work for you. '''
It's a very good summary of the Linux kernel userspace compatibility policy.
> There have been exceptions, but they are few and far between, and they generally have some major and fundamental reasons for having happened, that were basically entirely unavoidable, and people _tried_hard_ to avoid them. Maybe we can't practically support the hardware any more after it is decades old and nobody uses it with modern kernels any more. Maybe there's a serious security issue with how we did things, and people actually depended on that fundamentally broken model. Maybe there was some fundamental other breakage that just _had_ to have a flag day for very core and fundamental reasons.
> And notice that this is very much about breaking peoples environments.
So breaking userland is possible if there is literally no other way, but
1. it's the "nuclear option "of kernel changes
2. it will be acknowledged as breaking users's environments
Edit: fix styling
Though it is annoying if you're at the receiving end of it, own up (the opposite of what the patch author was doing)
There are very few places in software where an expert/engineer have full authority on the development/how things are done/specifications. You often see money/markets/trends take over.
I really wonder what linux will become without Torvalds when he will go away. I hope he already thought about it, because it will really require somebody with huge confidence about what to do.
There's room to talk about how much zeal is too much, but it certainly seems far better than the "silence till firing" approach people describe at some big companies.
no amount of skills gives you a free pass to treat people like shit. I would not want to work with anyone who has this attitude
Ass-chewing isn't generally beneficial as it makes people defensive and potentially angry themselves. The mea culpa is good: "And again sorry, I screwed up, it should not have happened, my perspective was incorrect and I know I need to make it right." This is a great response, defuses the conversation and makes it clear that it's going to be fixed.
As someone who's gotten chewed out before, all it does is leave a bad taste in your mouth and most likely going to quit the company or possibly the project. Honestly, the threat of rejecting future commits and/or rejecting his opinions was by far the best thing in Linus' response, b/c those cut straight to your potential to contribute to the project.
That seems to be his direct intent, and being angry does help get this point across.
Bluntly telling someone they really screwed up and need to stop denying it isn't bullying. Someone being mean isn't bullying.
> getting an incompetent bozo fired
> "bullying"
Assholism is not the solution to great leadership. It’s one of many techniques leaders use. Some leaders are effective using it frequently, but it’s important to note it’s usually not required because there are trade offs and downsides, both morally and amorally from a pure efficiency standpoint.
"Everybody"? Sanders also said a bunch of things like they are, and he said them politely. Especially factoring in grass roots support, he was more popular than Hillary and would have wiped the floor with Trump.
If you allow your media and "leaders" to sweep people like Sanders under the rug, you make people like Trump inevitable. And then you still don't learn. There can be worse things than Trump, so much infinitely worse; and they will come to pass if you insist on this trajectory.
The people who don't have those tools control the horizontal, they control the vertical too. If they say your personality is wrong by definition, who are you to question them?
Without getting snarky, that's just the status quo right now. In some number of years they'll treat it like a big discovery that their previous assessment of all social interaction wasn't 100% perfect. Let's just hope that when it comes the pendulum swings our way and I get to stop wearing an emotionally-dishonest husk of a personality to the office.
[0] For the sake of avoiding predictable tangents, I mean aggression that is obviously not going to escalate to physical responses, or even anything more than rejecting patches.
But my dad was ex-military, then a logging contractor, then a heavy equipment mechanic, and I grew up working with him. When there are firearms, chainsaws, bulldozers, or heavy objects dangling from cranes, you don't have the luxury of couching your criticism in weasel-words or crafting the compliment-criticism sandwich. If somebody is fucking up, you let them know in no uncertain terms, because somebody could get hurt.