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.
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.
I'm not sure what you mean. I thought it was self-evident that if your interface is an abstract type then you can change the implementation without breaking consumers. If you don't think it's true then please can you explain how?
I thought the Clojure argument is not that types don't provide beneficial encapsulation, but that it's not worth paying the cost for them. Again if you know any different I'd be pleased to hear.
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!
As a simple example, suppose I swap out one container type with another one in the internal code. Both implement the same interface/traits, so the change isn't visible to users. But the time complexity of the container operations are different on the new type, and the user was depending upon the time characteristics of the old container. E.g., deletions are now O(n) instead of O(1). I've violated a user expectation without breaking type safety.
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
> 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.
That is a situation they work towards never happening, by never leaving a behavior change in the wild long enough for such a situation to develop.
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.
The bug they fix is the bug that keeps the API contract intact. The first application gets its bug fixed, and the second application breaks because it was relying on a bug that didn't match the API contract.
You program to an API, not to an implementation. The second application did the latter, and will therefore pay the price.
That's not Linus' position. The "API contract" for the kernel is "we don't break userspace code," not "we don't break userspace code that follows the specs." He would bounce (and flame) the fix you're suggesting.
If you can afford to do that, it's nice to do it indeed. It can get messy and hairy quite quickly though.
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.
Sure, it's not a strategy without costs and Microsoft goes to an extreme. But there's probably a middle way in there; if you're aware that tons of programs now depend on the buggy behavior you probably want to deal with it. But if you're working on Windows or the Linux kernel the tolerance for breaks is probably much lower.
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:
Rust also uses a sizable fraction of all publicly-available Rust code as a regression suite for compiler updates. This allows them to check edge cases that are "breaking in theory" to find out if there's actually any code that would be broken, or if the edge case had literally not yet been encountered.
I'm curious why this is seen as a new idea. The capability to pull it off is somewhat new. In particular, at such a large scale.
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.
Rust also has yet to develop a stable ABI, I know they’re hard at work on so many things so I don’t say this as some snide remark - but until this is the case and Rust supports proper dynamic linking there’s whole domains of tasks I’m not comfortable using it for.
Well, Rust has a stable ABI in the same sense that C++ has a stable ABI: you get a stable ABI if you use an extern "C" and repr(C) layer at the linkage level, or you use the same version of the compiler to compile all your code. It's not ideal for some use cases (though I think not having a stable ABI is the right decision at this stage), but it's not worse than C++.
This is a thing I've been wondering about. Is dynamic linking (in the way that C/C++ programs use it all the time) not a usecase that Rust wants to cover?
You can do dynamic linking, you just can't do it across compiler versions. This is how all of the Linux distros are doing it, for example.
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.
> 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.)
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:
Unfortunate, but expected. On that note, would there be any breakage loading multiple Rust .so's with differing compiler/stdlib versions into the same process? This is one of my main concerns about the lack of ABI stability and the static-linking-first design of Rust. With C++ at the very least I know Red Hat isn't going to break the ABI within a major release, but the Rust 1.21 packages are already in epel-testing.
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?
I get the idea, but this is user hostile. If it shouldn't be seen as an upgrade, it should have had a new name. :( Especially if it is going to be a forced migration someday? (I'm assuming python2 support will eventually stop?)
Sure, they're similar enough that a single file can be valid in both with less effort than most language pairs. That doesn't mean it's an update, any more than C is an upgrade to Lisp because I can make a file that's valid in both.
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.
There are many cases where continuing with invalid data is much worse than a parse error. Perhaps that's less likely in this case (hopefully your credit card payment doesn't depend on the values in /proc/<pid>/stat), but as a rule, silently continuing with meaningless data is scary.
Yea that's what I was thinking. If the behavior changes, what "works" entirely depends on the context of that specific application. I can understand mitigating complete failures as much as possible, but trying to trick programs into thinking that they're running the same as they were before seems.. well, scary as hell. I'm honestly not sure what's worse - breaking the application, or making it think everything is fine.
Zero could be a perfectly "valid" value and still break your application if changing the function to always return zero breaks an implicit contract. Suppose the previous behavior of the function returned something you could use as an ID for some internal representation in a database that you could look up and write to. Before, the ID you got back depended on the input, but now it doesn't. And you can't tell you're not getting real IDs back anymore, so you just happily write to the database.
Now you're corrupting your database because the implicit behavioral contract you were relying on was broken - I'd MUCH rather the program just crash than for it to continue "working" in a way that irrecoverably corrupts data.
> then the app was poorly written and would'be been broken in the first place.
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 guess that depends on whether or not zeros were valid in the first instance. My post assumed they were. I agree with your point if zero would be outside of the valid range in the first instance.
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.
That's fine when it's code that you wrote, but it would be really annoying to me as a user if htop (for example) started crashing on a kernel upgrade (instead of one the columns suddenly being zero).
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
I really wish all those people chasing the "desktop Linux" mirage while breaking APIs at whim would internalize this.
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.
That's really not a problem of the kernel, though, is it?
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.
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.
Fair point, but I'm coming round to the idea that emotional 'anger' might be a very effective tool to use when in charge of things. It seems well applied in this case.
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.
Yes, exactly. Linus does things his way. Others (OpenBSD and maybe other BSDs for example) view the kernel + userland as a complete release and you upgrade everything together.
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.
"Seriously, it's the kind of garbage that makes me think your opinion and your code cannot be relied on" is, quite bluntly, a personal attack, directly commenting on an entire developer's code history and knowledge based on one single issue. This could be worded a lot better. The profanity is also unnecessary.
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.
Linus isn't a manager, he's in charge. Persuading people to move in the same direction is a critical management skill but fundamentally not the job of someone actually steering things, and it's entirely common for the person in that role to just bluntly do the decision loop thing and let someone else put a happy face on it.
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.
> 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.
Except that it is still being used unlike the other "nice" projects. BeOS. For example.
To be fair, BeOS was killed by Microsoft threatening OEMs into refusing to carry their product. Linux only escaped because it wasn't owned by a corporation that needed revenue to survive.
It is possible to be technically brilliant and wildly succeed in your project, and usually do overall good when it comes to project management... and yet have certain personality flaws that may hinder your management skills.
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.
The profanity is in the original post ("Stop gthis f*cking idiocy already!", "bogus SHIT").
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".
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.
If it was anyone else we'd be calling them an utter asshole and then citing them as reasons why Silicon Valley has a reputation for <insert bad behaviour here>.
Linus is still a dick and it isn't funny, refreshing or cool.
I've called Linus an utter asshole many times before, I have no problem calling him an asshole when he is one. I've made big career changes because I was sick of certain toxic people in open source projects. I'm not defending Assholes In OpenSource(TM). I just don't think this is an instance. He isn't personally insulting the person, the person was defending a choice that anyone exposed to kernel development should know does not meet fundamental expectations. After 3 weeks, that requires some bluntness.
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.
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.
And if an employee pushed for 3 weeks ignoring the company's leader's best-known rule for not screwing over customers - what does that say about the employee? How would you deal with it if they haven't listened to anyone else? It's like you're not even reading anyone's responses to understand why they disagree with you...
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.
There's an implicit idea around our culture that the more uncontrolled emotional content that someone communicates, especially anger, the more 'honest' they are - I think because it's intimidating, leaving less room for debate; it makes reasoning very difficult, leaving even less room for a rational approach; it's message is of being uncompromising, which also cuts off any thinking or discussion. By eliminating thinking and discussion, it's simple, and I don't mean that in a good way, but that makes it appealing to people too lazy to deal with the necessary complexity of situations and who are not committed to getting the best outcomes. But it's not honest at all and it's not hard to see how it leads to bad results.
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?
It's a cliche hacker news comment that adds nothing to the conversation:
- 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.
As the author of the comment in question, I think some of parent comment is fair criticism - that my comment is general and too superficial, without a strong basis in fact and it doesn't contribute much hard knowledge; it's all analysis. Also, it's long.
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.
Is this like an alt account to issue apologia for unpopular comments? You literally went through the comment tree and rehashed your personal opinion on the comment over and over again.
Are you able to provide a patch for the aforementioned elementary grade mistakes to the open source kernel project without introducing any kind of regression in user space?
But they're elementary bugs you could have just fixed for yourself. You clearly were trying to do something and the mistakes that were made were easily spotted, I'm confused as to why you just didn't do it at the very least for yourself?
>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.
"But they're elementary bugs you could have just fixed for yourself"
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.
As it's used almost everywhere in coding circles, regression means a patch that made things worse than it was before. No implication of the worse state being there before.
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).
> If you ever work for a real company with real deadlines you'll get a lot worse than what he gave.
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 think you must have worked for some horribly unprofessional companies.
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 have no idea who was harmed. Treating other human beings with this kind of flagrant disrespect is childish and unprofessional. It's ridiculous how many people are making excuses for his behavior here.
As an experiment, let's see if this comment gets flagged...
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.
What is the point of your experiment? Insults like this are routinely flagged on HN. If it weren't, I suspect it would only be because it hadn't been seen by enough members or the mods.
My point is that tons of people in this thread seem to think this style of communication is really great because it's emphatic and gets the point across clearly or something.
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've noticed others mention that it's context dependent: what's acceptable in some communities is not acceptable in others. Your comment, if meant in earnest, while it may be acceptable when uttered by Linus on the kernel mailing list (I'm extrapolating here based on the few comments I've perused in this thread), is not acceptable on HN. Given the different conditions, I don't think it would produce anything meaningful, whether it gets flagged or not. And given that you've prefaced it with "As an experiment, let's see if this comment gets flagged...", I suspect some that would otherwise flag it won't because it's clear it's not meant in earnest.
Yeah, obviously comments on this shitty message board should have a much higher standard for civility and professionalism than the development process of a major operating system. /s
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.
How would you rate the downstream impact of delivery failures in this project?
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 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...
> 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?
This isn’t a “disagreement” talk in the op. This is a “you screwed up and then lied about it and now I have to work around your bad faith” talk. Different purposes.
Though I don't disagree with Linus' words. He could convey the same thoughts without swearing. I don't swear and I'm very capable of correcting people when they mess up.
Matt Mackall, another cranky kernel hacker, showed me a lot about how it's possible to say "no" to many eager changes that would have broken Mercurial and not be yelling obscenities about it.
Linus is no role model. His imprecations are not what make Linux work.
You can have lots of theories about what would or wouldn't make Linux work, but the facts on the ground are that Linux is wildly successful, and Linus behaves as he does. The latter has been an integral part of the former.
Just because Linus is effective at communicating what he wants doesn't mean his way is the best way. Why wouldn't it be even better if he alienated contributors less?
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...
How was the contributor in this case "denigrated"? There's a difference between calling someone stupid and calling their actions stupid. I've seen plenty of the latter from Linus, but never the former.
I understand where you're coming from. It's important to take the cultures and expectations of each participant if one's goal is to communicate effectively. And that goes both ways. Both the speaker and the listener need to take this into account. If one's dogmatic, believing that requiring any change on their own part to accommodate the listener, that gets in the way of the goal of communicating effectively, just as expecting a speaker to conform to one's own standards as a listener. It really needs to be looked at from each person's perspective.
And part of that is understanding when those perspectives are valuable and when they are irrelevant noise. I'd wager (but have no way of proving) that the quality of the Linux kernel has not been negatively impacted by a lack of people who get upset over word choice.
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.
> quality of the Linux kernel has not been negatively impacted
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.
Profanity, like any other piece of language, is a tool.
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.
Profanity by itself isn't the problem. I don't have a problem with shit piss cunt fuck either. 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'm sorry that Sarah Sharp is no longer maintaining the USB modules because of Linus's attitude, because I've never seen anyone else who knows as much about USB as she does.
Let's put this in a vacuum (since I'm not too familiar with the whole saga over time and I'd like to see an honest response.)
> 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.)
> 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.
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 think you're addressing the first half of his objection to Linus' behaviour, not the second half though.
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.
He has lost his temper needlessly in the past and acknowledged it as something to work on and from my limited perspective it looks like he has.
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.
Because enforcing politeness and civility in large groups is impossible without top down leadership enforcing it, which Linus doesn’t appear to want to do. He has chosen code over comfort as the de facto leader of the project.
That's not an argument for why Linus's way is the best way to lead a project, or why we can't have civility and high quality. You just restated what he has chosen to do.
> high quality kernel code is more important than not alienating contributors
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.
> 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.
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.
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.
> It's not a regression unless something was broken first, then fixed, then the SAME ISSUE comes back in a later code change.
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.
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.
No, it is neutral from a security point of view: previously you couldn't configure the new thing at all, now you upgrade to where you can configure it, but isn't you didn't configure it the last time you configured everything (because you couldn't) so it default to as if you had enabled it. When you come back latter and think about this again you enable the new configuration with the right whitelist, but until then things work just as well as before.
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
Another example is what happened when Linux moved to 3.0; some programs expected a 2.x version, or even 2.6.x, these programs were clearly buggy, as they should check that the version is greater than 2.x, however, the bugs were already there, and people didn’t want to recompile their binaries, and they might not even be able to do that. It would be stupid for Linux to report 2.6.x, when in fact it’s 3.x, but that’s exactly what they did. They added an option so the kernel would report a 2.6.x version, so the users would have the option to keep running these old buggy binaries. Link here.
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[0]
"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."
When the Opera browser updated from 9.60 to 10.0, they found that some sites stopped working because they blocked user-agents with low versions of Opera... and they checked versions by looking at only the first digit after "Opera." So version 10 looked to them like version 1.
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.
You're just being disingenuous, what does that help?
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.
It is just as disingenuous as saying "details don't matter". bonzini's comment was saying a line needs to be drawn, and I agree with that. It's pretty clear the line needs to not include "breaking on version number updates", less clear what it also needs to not include.
Well, I do kernel dev. I am the maintainer of KVM. :)
> 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).
I still don't get it; either I'm remarkably dense today, or there's a disconnect. I wrote:
> 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.
Windows contains code like "If SimCity is running, allow it to use memory after it's been freed"[1]
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.
Also, Microsoft skipped releasing Windows 9 because so much code out there think anything labeled "Windows 9..." is of the Windows 95/98 lineage.
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.
And the other key quote from John: "It is a userspace configuration issue. Your userspace is set up to basically do policy development".
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.
'''
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
A number of years ago some dillhole became annoyed that strings in the kernel inconsistently capitalized null, sometimes it was "null" sometimes "NULL". So they submitted a patch to make them consistent. This broke the iscsi userland. As far as I know, it was never reverted.
I do think there's an enormous difference between breaking changes of the form "hey, this is important and it's going to break shit, we can't find an alternative, be prepared" and "oops, we broke it, good luck!"
Rare, planned breaking changes are a reasonable answer to improving security and usability. Python 2 -> 3 and the Mac PowerPC switch both seem like examples: they caused real inconvenience, but they were very clearly announced and had real benefits.
Sporadically screwing over users, though, really is unforgivable. Last time I updated Windows it escalated a minor graphics card issue from "automatically recovers" to "kills your session to collect error data". It's like the patch author comes into my house once a week and unplugs my machine, just for their own amusement.
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.
There are a few that even though they are not RH employees, are very close to RH employees to the point that they would likely look the other way rather than confront like Linus would do.
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.
Equating this email to a parent beating their child is a false equivalency. Firstly, because Linus has not physically attacked the developer, and secondly, because the developer--unlike the child--should know better. This is more like Gordon Ramsay going off on a chef who has just told a customer off for not liking his burnt toast.
I agree with the first part, but not with the second part. I believe equating John's behaviour to a chef who has told a customer off is just as distant as mine.
If I was looking exact equivalent, I would just send the same link to the same email.
I am using empathy here. I don't know you guys, you may feel ok if you get shouted when you do wrong when contributing to a project, but I would feel bad, and as a human, I don't think my feelings are not important. If it is coming from an important person like Linus Torvalds, this would hurt even more, and really I don't see anything disrespectful to anyone in John's email.
I would argue that the best response to an expert telling you that you are wrong is to fix the problem. While your feelings do matter, the stability of the kernel matters more, and you cannot discount Linus's message because you think it is too emotional in tone. At the end of the day, Linus is right, Linus created the project, Linus is leading the project, and he is using strong language to inform you that he needs John to change his approach to this problem for the sake of the project.
On a slightly more pragmatic note, Linus would not be angry if John hadn't been trying to break Rule Number 1 for three weeks in a row, so an alternative solution is to simply not break the rules. Granted, if you disagree with the rules on a fundamental level, that doesn't work--so, third solution: leave and start your own project.
Not only your users are important, people who help you are also important.
> If you ask nicely and people don't do it, or keep ignoring it then you up the tone
I am sure it can be done much better with a little effort. Being smart, or being someone who has done something important shouldn't exempt you from being nice to other people.
>Being smart, or being someone who has done something important shouldn't exempt you from being nice to other people.
Absolutely. However, not being nice to someone does not mean you are wrong. One can be an asshole and still be correct, and one can have one's feelings hurt by the truth (indeed, psychologists will tell you that if it upsets you it absolutely is something you need to dig deeper on).
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.
I don’t think that’s really what Linus wants (obviously we’re speculating here). He was trying to make it clear that breaking the first rule of kernel development is not negotiable. Anger and swearing isn’t needed to express that, let me reiterate, this is what does that:
> 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.
Agreed, and if this a fundamental concept in kernel development, as he says it is, I believe he has every right to feel frustrated as the debate thread has been going on for three weeks.
Linus has been known to have some hostility to 'security developers' in the past, so I'm also going in with some skepticism. But I'm not seeing him be unreasonable here.
These are human processes, a lot of personality, dedication, and sacrifice is involved in these projects.
Brutal honesty isn't for everyone. I personally grew up with friends who would deal out this kind of thing and I wouldn't feel bullied or humiliated. Sometimes it got to you but, there's no way around that, but over time you learned to develop thicker skin and bounce back without getting feelings hurt.
Especially when it's a personality style combined with the fact it comes from a place of caring deeply about the subject... then the motivation is not just trying to hurt the other person. This is the maturity, the point you learn to see in people.
Clearly Linus is heavily attached to the project and the person he replied to has been pushing an unpopular position for 3 weeks. It didn't come out of nowhere. He's also not new to this game. He's not some new intern, who doesn't know the deal, getting bullied by a CEO.
There has been a big culture trend to treat every small comment as potentially devastatingly hurtful, training kids to be thin skinned, and in my opinion, this highly disincentivizes honesty and will create a lot of inefficiency in business. As it requires a significant time investment to make sure even seemingly harmless statements are not 'hurtful', employing subtlety and skirting around an issue indirectly requires significant cognitive load. In a high volume, high pressure projects like the Linux mailing list this could really add up and generate bad decision making, as people will rather avoid an issue then invest in saying it carefully.
The ROI in that trend is questionable, as you can train people to see beyond the words and look at the person's real motivation and meaning, as it is not a given raw honesty is coming from a place of personal attack.
That said, obviously otherwise real hurtful and mean attacks, without an underlying purpose and genuine motivation other than to hurt the person, should never be tolerated. But sacrificing full honesty and non-heavily filtered emotional opinions in order to never have these personal attacks is just not worth it IMO.
Yeah but the thing is, I don't see how our points conflict.
Yes, by all means people should try to develop a thick skin and would benefit from that throughout life. That would lead to X% improvement and Y% who still were dealt with in a counterproductive way.
There's a wide range of capacity for dealing with this stuff. General Macarthur was infinitely strong minded, but when he saw someone with war induced PTSD in a hospital bed he slapped him across the face for being a coward. I give him the benefit of the doubt that his own strength made it difficult to see what was a much less understood thing back then. This case is not even close to PTSD, but the concept is the same in that emotional capacity varies widely, even when we practice resiliency.
Linus caring passionately about the project I think is irrelevant, the question is what leadership approach yields the desired results with the least downsides.
>...a culture trend to treat every small comment as potentially devastatingly hurtful,
>training kids to be thin skinned...this highly disincentivizes honesty and will...
>create a lot of inefficiency in business...
That's the fallacy right there. There's nothing stopping people from demanding excellence, demanding results. Indeed, high standards should be the bar, and if their are multiple ways apparent to achieve them, the one with the least negatives should be applied. That's smart for both business and morality.
>>sacrificing full honesty and non-heavily filtered emotional opinions in order
>>to never have these personal attacks is just not worth it
This is another critical point. I do not advocate (and I think many others as well) for one second that honesty, directness, fidelity, and impact of communication be sacrificed. I think in some cases you do have to break eggs to make an omelette. I just believe the cases where being an asshole is required to achieve a certain level of effectiveness is in general exceptional, and that it also wasn't the only way in this particular case.
Btw, none of this is really a critique of Linus. Yes I think he could have done better, but there are thousands of conversations like this everyday. This just happens to be a mini case study in leadership styles and the options for achieving the required results.
> General Macarthur was infinitely strong minded, but when he saw someone with war induced PTSD in a hospital bed he slapped him across the face for being a coward. I give him the benefit of the doubt that his own strength made it difficult to see what was a much less understood thing back then. This case is not even close to PTSD, but the concept is the same in that emotional capacity varies widely, even when we practice resiliency.
I believe you mean General Patton here, not Macarthur. I know this story well and I don't think this came from a place of personal attack either. It came from a place of misunderstanding. This is the critical difference I'm getting at. The personal motivation is what matters, not the lack of preemptive filtering of the words or actions themselves.
The solution there was an evolution of the understanding of PTSD. The General was caring deeply about such an important thing, such as not letting well-trained soldier be a coward and hiding in the hospital when other men are dying in the field. And he saw many young kids die and it made him raw.
It's also been said the General may have had his own PTSD and emotional problems, and he wanted to attack the weaker man who made HIM feel that way.
Ultimately he was wrong factually, for misunderstanding the motivations of the soldier. The soldier wasn't being a coward (AFAIK) but suffering from serious mental trauma. If this happened in 2017 it would be a different story because Patton should have known better and what he did was abusive in that context. AND Patton could also have been better informed about his own risks of behavioral problems if he had modern science and education.
Does this mean Patton's brutal honesty was the problem? Or was it the general understanding of PTSD? I believe the latter.
Ultimately this doesn't mean Patton shouldn't have been brutally honest with his regular troops on the battlefield. Which he was, and he was also brutally effective at running the war too, and he was loved for it by his troops. The guy in the hospital is a different story and should have never happened, but I don't think I would have sacrificed Patton's honesty because society and common sense was wrong about a few subjects.
However the point was not Patton did wrong, as I mentioned I believe he just wasn’t aware.
The point was people have massively different reactions to emotional stress. This is why two people with identical wat experience may or may not get ptsd. Training for emotional stress has limits.
You keep saying you wouldn’t want to change the virtues of these leaders. I’m trying to say (forget Patton) most times their virtues don’t come inherently from being an asshole. Their virtues come many personality traits, strength, courage, talent. We don’t have to, and shouldn’t give up thes virtues. That doesn’t meant they can never be optimized.
I think most people agree with you, he screwed up more with his handling of the situation. Occasional good faith mistakes shouldn’t get people in trouble, but he was weaseling.
The interesting issue is more of leadership.
1) Is it possible to get equally direct and effective results in a different style?
2) Does Linus care about the answer to question (1), or would he act out of emotion even if he knew knew there was a equal or more productive way?
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.
Unprovable counterfactual (and disputed by actual facts but ho hum.)
> you make people like Trump inevitable.
No, it was nothing to do with Sanders - it was Comey, gerrymandering, gutting the VRA, voter suppression, a complicit media, an electoral system that vastly overpowers the southern states, and astonishing institutionalised countrywide racism and sexism.
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.
Also, it is quite likely that Torvalds would not word it like this in person. He uses it on the mailing list specifically because the written form do not allow body language and other such clues.
It is this that gave us things like smilies and Poe's Law.
I'm always eager to read Linus's rants. I wish more of my coworkers were like him. I hate the environment where nobody reacts strongly to anything! If somebody fucks up hard and refuses to own up, I (or whoever's in charge) should be able to shout at them. It's only natural.
I disagree. To me he usually comes across as an asshole, albeit an extremely smart and accomplished one. A working environment where the person at the top can be relied upon to react to human failings with an aggressive, sweary [1] rant is not somewhere I ever want to work.
[1] I'm aware that use of profanity in everyday speech is common in Finland. I don't mind swearing per se, but I find its over-use a bit tedious.
Anecdata: I grew up in Finland. It's common if you're 15-16 and in middle school, but I've rarely heard adults swear in the workplace or in public (unless inebriated).
If Linus wants to use perkele management, then I guess it's his project. Doesn't mean it's the right way to do things.
> [1] I'm aware that use of profanity in everyday speech is common in Finland. I don't mind swearing per se, but I find its over-use a bit tedious.
Actually what you are unaware of, might be that the use of profanity in everyday speech is actually very common pretty much anywhere in the world other than in the US&A where mince words and puritanism are still king.
The problem is that often things are not so clear-cut... what seems like a fuckup at first glance or from one perspective might be something different (perhaps one thing is messed up but it was to fix another thing, or perhaps you are mistaken and things are just different but not "fucked up", etc). As soon as you start shouting at someone, they will tend to get defensive and dig in their heels, thus making it more difficult to get to the bottom of what actually happened and why.
For most of us in software, our jobs are not saving lives or anything -- it's not worth creating a toxic culture just so you can feel good about yourself by shouting at someone.
I have the same problem where I work. If someone messes up it starts a long game of passive aggressiveness. I'd much rather people come right out and tell me I'm causing an issue. In this way I can change course or work on convincing the other party this is what needs to change.
I agree. But there's a difference between being straight-to-the-point versus "shouting" at people. You can be direct without being mean or belittling about it.
I can understand and empathize with both perspectives here. On the margin, is it better to have consistent interfaces, or simpler implementation? This debate reminds me of the worse-is-better design style, which is supposedly at the root of Unix's success.
The worse-is-better philosophy is only slightly different:
- Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
- Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
- Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
- Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.
However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.
That "worse-is-better" link redirects to a rather rude Imgur image. I'm guessing the author dislikes HN. Following the same link from a Google result did not redirect to the Imgur image.
Indeed. I upgraded a Ubuntu installation a while ago. The network just stopped working because the developers of NetworkManager had decided that NM should no longer manage wired network connections on some Ubuntu configurations.
That is just a crappy attitude and I have to say NetworkManager is generally one of the buggiest and most unreliable pieces of software I have ever used. And I'm actually making a great effort to be polite here.
Linus is right but his choice of words seems unprofessional bordering on harassment. Almost sounds childish in parts, especially the ALL CAPS screaming he does. Its cool to be passionate but also be civil.
It seems to be kind of a running gag, and I wonder what else do people imagine is what the kernel is supposed to satisfy than as many other people's expectations as possible?
The only time Linus gets talked about here is in context of conflicts. This creates a fabricated one sided image of a person who has now given us Linux and Git.
Its not a corporation, the tradition and history is completely different, the levels of formality are much lower and the context and culture is completely new.
There is no traditional hierarchy and the authoritarian structure that most including commentators here work under in the corporate world.
No one works for Linus and he has zero power over anyone. Commentators pretend its all roses in their world yet the corporate world is full of people who have power over others and are actually abusive.
Linus's emails are tame stuff and those casually comparing this to abusive behavior are simply devaluing actual abusive behavior that becomes possible under non transparent authoritarian structures.
I was recludant to agree woth Linus at first. Why should we avoid break hard? I understand we wany to avoid breaking user interface as much as possible - who would want to use an unstable API? But why is it better off to let things fail silently? For example he cited certain obsolete fields in /proc/stats return zeros.
Is it because Kernel is used by so many people and projects we can’t afford having some <insert your favorite Linuz utilit> broken after upgrading to a new kernel. Replace Linux kernel with OSX or Android etc
Yes of course. But I feel the consequence of never break your interface and never blame userland is to force the users to write tests that can report changed behavior.
Plenty of people claim that they're scared to contribute because Linus might yell at them. That's unfounded for a lot of reasons.
TL;DR: Test your code before you submit it. Don't accept or acknowledge patches from others that haven't been reviewed or tested. And if you make a mistake, own up quick and he's not going to yell at you. It's pretty simple.
He will occasionally jump in and yell when people aren't accepting responsibility for problems they caused. Especially when they won't accept nicer, less authoritative criticism from their peers.
That's what happened in this case. Check the follow-up message in the thread where Linus explains his dissatisfaction (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02507.html). The contributor who caused the regression was caught denying that there was even a regression. His patch had already long been identified as the culprit and reverted. But over the course of three weeks he was insisting that it was not a kernel regression. Essentially he dug in for 22 days saying that it wasn't his problem. And he wasted tons of valuable contributor time where people were nicely telling him that, yes, it was indeed a regression.
Multiple people were telling him about the "don't break userspace" policy and how it was a regression. And yet that contributor was still deflecting responsibility for the problems caused. But the problem is that this patch would leave the distros in the lurch - scrambling to update their configuration before the kernel breaks behavior. And that's without any ETA on their "long term ... flexible solution" (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/00380.html). Thousands of people with varying levels of technical competency would have had their systems break in unexpected ways.
Quite frankly, he earned the dressing down. And plenty of people tried to be nice to him about it. It just didn't take hold in his mind until Linus dropped in to rudely remind him that even "correct" behavior is a regression if it breaks userspace. Also note that Linus said the issue had been escalated to him. Someone explicitly brought this to his attention because there was a distinct lack of progress due to CYA responsibility deflection.
Torvalds gets upset about people messing things up because he cares. He reminds me of Gordon Ramsey, who also gets a bunch of shit for being an asshole to people who ruin food in his kitchen -- but Ramsey has more Michelin stars than anyone else...
I read Linus' reply and it's not clear to me if he is ok with the regression, is not ok with the regression, or even if he considers it a regression. I wish he'd stop trying to be so diplomatic.
A change was made to the kernel that broke some applications - this is called a regression (a bug introduced in an update). The developer who made the change that caused the bug in the downstream application tried to argue that it was the application's fault, not the kernel.
Linus then calmly and politely reminded him that the official policy of kernel development is that they never introduce changes that break applications.
You only say "calmly and politely" because Linus is a known pottymouth and frequently "tears people a new one". An email like this might get you demoted or fired in some workplaces.
If the interface was simple, such as seL4's, we wouldn't have to see it become a clusterfuck which, to maintain userspace compatibility, can't be fixed.
Linux is what it is because of the passion and principle that fuel rants like this. I hope he continues to be just the way he is, and never gives an inch.
This sounds like a reasonable definition, but quickly it turns out to be completely insane.
Lets start somewhere far away from Linux, as far away as possible.
Windows XP SP2 blocked access to raw sockets for non-administrators. It also blocked access to \Device\PhysicalMemory to all user-mode code, regardless of the user running it. Linus would say this is a regression.
Fine, lets try something else.
I wrote some C++ code that violated the strict aliasing rule. It worked for me 15 years ago when compilers weren't optimizing so aggressively. I tried to compile it using the latest GCC and got strange results. Should I file a bug with GCC? Sounds like a bug according to Linus's definition. It used to work and now it doesn't. Who cares that I violated the rules in the first place?
"Now, hold on" I head you say. "We were talking about kernel and user, not compiling C++ code. That completely different!"
Well, sure, it's different. But it's also similar. I maintain that the point is the same, but lets go back to Windows for a second.
Lets say we have a program that used to parse the PEB.Ldr structs for whatever reason. In Windows 8 they went through a major change. This program no longer works. Is this a regression?
Raymond Chen has had to deal with this nonsense enough. For example: https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=... And his blog is full of example of dumb programmers counting on internal, undocumented, subject to change and actually changing structs.
If you, the reader, think you're very clever and say it's dissimilar because the LDR structs are user- rather than kernel-owned and -managed structs I give you the same example with EPROCESS. Take a look: http://terminus.rewolf.pl/terminus/structures/ntdll/_EPROCES...
The point is that "breaking" code that does things it wasn't supposed to to should be - and can reasonably be - considered a regression.
The very first example - with raw sockets - may be considered a regression, though I prefer the term "breaking change", since "regression" is a form of a bug, and this is not a bug, even if you think it's a bad policy.
The other examples don't even fall under the "Breaking change" the category. Nothing THAT WAS GUARANTEED was changed. If you counted on things that nobody promised you that would remain the same to actually remain the same that's your problem.
And back to Windows for a moment. Lets say someone uses the UpdateProcThreadAttribute API to set the mitigation policy on a child process it creates. Instead of only setting the bits he want (like PROCESS_CREATION_MITIGATION_POLICY_FORCE_RELOCATE_IMAGES_ALWAYS_ON to force ASLR on all modules, PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON to block win32k calls and PROCESS_CREATION_MITIGATION_POLICY_EXTENSION_POINT_DISABLE_ALWAYS_ON to prevent injection by the system of a couple sorts of plugins) he goes on to pass 0xFFFFFFFFFFFFFFFF. He wants all the possible mitigations! He's that smart!
Then comes along Windows 10 with its binary signature policy mitigation and (0x00000003ui64 << 44) is interpreted as PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALLOW_STORE. His child process can't load any of his DLLs. Clearly a regression under the Linus rules. Obviously not a regression.
From what I understand the situation is very similar to this. I'm quoting from John Johansen message on the thread:
It is entirely possible to use the 4.14 kernel on suse without having
to modify policy if the policy version/feature set is pinned. However
this is not a feature that suse seems to be using. Instead suse policy
is tracking and enforcing all kernel supported features when they
become available, regardless of whether the policy has been updated.
The clever folks at SUSE decided to enable all the protections/mitigations/features/whatever of AppArmor, including those that didn't even exist when they wrote this stupid policy. It's completely reasonable to think that a program restriction infrastructure's new feature won't restrict programs more. Sure. If it does that's a regression.
No, a software regression is when you fix a specific problem and re-introduce it later on in a code revision. That's literally the definition of a regression bug. That definition has been around since the 70s and I don't think any of you have the designated rights or privileges to change or modify or append that definition.
Wiki's references are books from the 2000s. Sorry, the term has been around way longer than that - we had this term locked down in the 70s, and that's certainly not the proper usage. Regression only happens when you fix a specific bug and re-introduce it in later code revisions. If it happens the first time, it's just a bug. If you fix it and it happens a second time, THEN it becomes a regression.
How is it normative? Although that's a bit of a rabbit hole, since presumably you won't allow me to appeal to the definition of 'normative'.
Torvalds lambasts a developer for making a mistake, swears at him, and tells him the first rule of kernel development is that you don't make mistakes. Great.
Probably also worth specifying that it's not just any developer, but a maintainer. Accordingly, it's reasonable to have higher expectations of mistakes with respect to "The First Rule", let alone acknowledging them as such.
>and the corollary is that when regressions do occur, we should admit to them and fix them, instead of blaming user space
Clearly he is aware that they did cause a regression as the mailing list post he responds to would not exist otherwise. Reading these two statements descriptively renders him an idiot.
The first rule is that you don't break userspace, not that you don't make mistakes. Commits go through a process before being put into the kernel, and if yours is going to break userspace, it won't get in, so don't expect it to. You can make mistakes, but if they're found, you're expected not to say "well, commit it anyway". It's not the mistake that the violation of the rule, but the cavalier attitude.
In any other kind of social/business arrangement he would be politely but firmly escorted out, possibly by security, for this kind of behavior. Being right or wrong is irrelevant.
Even when he's effectively CEO, visionary, and end-responsible for the business? He's the Big Boss of Linux, there is nobody above him in the chain of command. You're used to traditional businesses when there is no single end-responsible person, and when there is a public face for the company (like Jobs, Gates, etc), there is still a group of faceless shareholders above them that can choose to remove them. Not in this case. I like it myself, a dictatorship is a much more effective form of managing a software product.
Let me guess, you do not take any responsibility for what you do at work. I know plenty of folks who would love to make decisions and like thinking that they can do better, yet when their decision takes everyone down, they refuse to share any responsibility for a bad decision. And if you are not being held accountable that means someone else pays for your mistakes in business.
Linus lashing out about something is usually tamer than most social and business blowups I have seen. The thing that really stands out is that he is usually right, gives clear direction, and only cares about the project.
You need to work in a wider variety of workplaces, if you genuinely believe that. Perhaps put another way: were Jobs or Ballmer ever escorted out for their obnoxious behaviours?
The events of the past few weeks should serve as a reminder that what's historically been considered 'normal' behaviour in a workplace just because people have gotten away with it doesn't mean it's morally, ethically or legally justifiable.
When you create something and someone else comes and tries to improve it but fucks up and then tries to fix that by breaking some of the use cases for which you'd created your something in the first place, I'm going to cut you some slack if you go on a rant about what the correct solution is for your product.
I would expect you to do the same for Linus and his Linux, just as so many people do (did) for Steve Jobs and his Apple products.
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/