A regression is the kernel not giving the same result with the same user space
lkml.iu.edu
lkml.iu.edu
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://www.oracle.com/technetwork/java/javase/jdk-relnotes-i...
Of course, they are never at the level of a Python 3 release.
"Spec-ulation" - https://www.youtube.com/watch?v=oyLBGkS5ICk
Which I fully agree with, basically there are no major, minor, patch level changes, in reality every change is a possible breaking changes, because we don't control what downstream is doing with our software.
/me runs ...
https://news.ycombinator.com/item?id=15602658
https://news.ycombinator.com/item?id=15593069
My comment was intended to be a wry one referencing those very interesting discussions and hinting that if you have types then you can more easily make breaking changes internally that aren't visible externally.
Who's "we"? I'm talking about changing the implementation.
> Did you watch the video segment?
I watched the bit where he said if you add a constructor to a sum type you have to change everywhere it's pattern matched. True. I'd love to see Clojure's solution where you don't have to change any existing code!
EDIT: Oh wait, I think it's even worse than that. I think he's talking about product types. In which case you should use projection functions and indeed you need to make no changes to old code!
1 - Not all changes can be kept internal, for example adding a new case to an ADT
2 - Internal changes can still alter the semantic of the API, even if from the outside everything still looks the same from the type system point of view
It is "possible" that my blowing my nose will disturb butterflies in China.
Internal to the organization that produces the software, they are highly meaningful. Extended to user base that reads the documentation, it remains equally meaningful.
Downstream that resists information and can not be controlled is on its own. Good luck.
There should be a mechanism for releasing breaking new major versions. And it is this:
1) Release a new version for all your DIRECT dependents. Ideally they should be subscribed to your updates.
2) After they have had ample time to test it, they will release an update for THEIR direct dependents.
At no time should C update A if C depends on B and B depends on A. In fact, ideally, if C depends on B1, ..., Bn then C will NOT upgrade A until all B's have upgraded. C should push the B's to do it and supply patches.
This means version pinning for all dependencies, my friends!!
The alternative is "dependency hell" or making multiple copies of A to live inside each B.
If some B's are taking their sweet time then it may be better for some C to submit a patch to B's repo, which even if not accepted can be pulled by other C's. The question is who "owns" or "maintains" a B project if they don't react to changes of some of their dependencies. The answer, I think, should be - fork the B if it's not being actively maintained.
Edit: I think HN needs a "reason for downvote" field, perhaps seen only by the person being downvoted. As it is, many downvotes convey very little useful information.
I noticed this when recently writing a spec that defines backwards-compatibility. There's surprisingly few things you can do when you want to stay backwards-compatible.
With full backward compatibility, you agglomerate features, and changes are implemented as optional, with the default being the old behavior.
You can add layers that depend on existing code, but you cannot make existing code depend on those new layers.
https://killercup.github.io/bitrust/
This explains the Rust approach:
It's a spectrum:
Rust: recompile the world when you update the compiler
C++: recompile the world when you change ABIs or when the ABI changes (My understanding is that MSVC++ changes the ABI every ~2 years? I could be wrong.)
C: never recompile the world
It's not that we don't want the benefits of a stable ABI, but it's a monumental task, and there are more important things for now.
Don't forget that you can get a stable ABI today by using the C ABI. You just lose out on the fancier features Rust has.
This is only half true: every new release, the ABI of the runtime library changes. But the Visual C++ compiler ABI hasn't changed in decades.
If you design your own library ABIs so they don't pass std::foobars around, you can link C++ libraries built with VC++6 with ones built with the latest version, and the whole thing is going to work fine - the trick is that multiple versions of the runtime DLLs can coexist in the same process.
GCC/libstdc++ hasn't changed its ABI in more than a decade, since release 3.3 or 3.4; they even did incompatible changes to std::string in GCC 5 without breaking ABI:
https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c...
They literally run all tests against every crate published to the package ecosystem. That is amazing.
But the idea is far from it. Commercial compilers probably had this more than open source ones in the past. Though, oddly, it was probably a weakness in some respects, since it almost certainly slowed feature development/releases.
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?
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.
How does Linux manage to never break its API? For example in the event of a refactoring.
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.
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.
That way the app would be "backward compatible certified" if it used this layer. The layer would only run during deployment.
I guess an approximation is the Passing indicator on Travis or GitHub.
Developer can still have that freedom in most[1] situations. When you have a new idea for a better/faster implementation that is, unfortunately, incompatible with the existing interface, you can usually provide compatibility with a shim that implements the old interface using the new interface.
Sometimes this is little more than some #define renames and a handful of very-thin wrapper functions. Occasionally it will be a bit heavier, which might make the legacy interface slower, but this should be balanced (approximately) the faster underlying implementation. If the compatibility shim is significantly slower (or has other unavoidable runtime issues), an upgrade that is slower for legacy uses that still works is always better than breaking existing code.
For an example and opinionated discussion, see JWZ's post[2] about his OpenGL 1.3 -> OpenGL ES 1.1 header.
[1] Exceptions are cases where there is a *fundamentally unavoidable cost to providing the interface (e.g. where N is the total number of interface entry points, something in the critical path unavoidably MUST take >O(N) time or space, or N is limited externally to a small value ("we only have silicon for at most N instructions"))
edit: [1b] Another exception would be when the legacy interface itself is a serious security problem. If your legacy interface unfortunately forgot to include a way to supply credentials and simply accepts writes from anyone, a prompt fix that breaks that API is necessary and appropriate. Next time you're designing an interface, be sure to remember that security has to be baked in from the very beginning!
[2] https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-... (you might want to copy/paste that URL if your browser betrays where you came from with a Referer header)
That's more or less the thesis of Steve's blog post too.
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.
> Behavioral changes happen, and maybe we don't even support some feature any more. There's a number of fields in /proc/<pid>/stat that are printed out as zeroes, simply because they don't even exist in the kernel any more, or because showing them was a mistake (typically an information leak). But the numbers got replaced by zeroes, so that the code that used to parse the fields still works. The user might not see everything they used to see, and so behavior is clearly different, but things still _work_, even if they might no longer show sensitive (or no longer relevant) information.
I'm not sure I prefer the described result. If my application depends on some of those zero'd fields, it seems like that has potential to cause serious debugging problems, as opposed to just causing an error on the parse.
if your app didn't used to handle the 'zero' case (assuming zero was a "valid" value for said field), then the app was poorly written and would'be been broken in the first place. However, if the app _did_ handle the 'zero' case, then the app continued to work! The end user would've been none-the-wiser about the change (mostly), and some time later, the app could be upgraded to ignore those known fields.
Causing a parse error would mean the app stopped working altogether. Much worse a result for the end user.
Because you had to handle the zero case before right?
The idea is that in the worst case you get an error message, not an altogether crash.
If you present this argument to Linus, you will certainly get yelled at.
Not breaking the user space means not breaking the user space even when it's broken. A couple years back glibc broke Adobe Flash because Flash used memcpy wrong. Linus was quite vocal about it.
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
I love the 'Raymond Chen Camp's way of looking at things. xx
If they want desktop Linux to happen, they need to stop chasing eyecandy and stabilize the plumbing behavior, no matter how much that thought offends their developer pride.
Also, I think bigger challenges to desktop Linux are the degree of configurability, drivers (maybe that's better), and the fact that the GUI is never a first-class method of using the app but instead a hastily-written wrapper on top of a command line tool.
[0]https://blogs.msdn.microsoft.com/oldnewthing/20031015-00/?p=...
[1]https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=...
Succession is a weird concept with linux but the fact that it has always been more stable than the other OS' is I think the main reason it is been so successful in the internet age.
An example of a failed succession is Tim Cook; the guy is the complete opposite of Jobs. Just take a look at the apple website nowadays. A product guru would not sell three generations of iphones that are all cannibalizing each other and lack any real differences.
However, Rust is linker compatible with C, and can be runtimeless, so rewriting the kernel piecemeal over time instead could be great. ;-)
It's always been well understood the the same people who are typically good are starting companies aren't typically the best people to run them once they achieve a certain scale.
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.
out of curiosity, how does a policy like this translate to microkernel OSes (e.g. Redox) where most everything runs in userspace?
https://doc.redox-os.org/book/introduction/how_redox_compare...
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.
Plenty of other projects out there to hack on if getting yelled at when you disengage your brain is too much. Most of which don’t have the obsession with not breaking stuff for the end user...
Isn't this just swearing?
> the only thing keeping garbage code out of the kernel.
I'm not sure if I'm buying that. It's possible, sure but on the other hand: It's not because the other way (i.e. communicating in a nice way, without all the swearing and direct attacks - which is imo not the same as direct communication) hasn't been tried that somehow proves it won't work. E.g. I know repos where one maintainer is kind yet gets things done, and another one seems to have borrowed his communication style from Linus and gets less done. Because people just give up, being sick of being yelled at in an unpolite manner. Is it that hard to be respectful, even when disagreeing?
Linus is no role model. His imprecations are not what make Linux work.
(if A then B) AND (if not A then not B)
That's causation, surely.
> Every day, the rooster crows and the sun rises; that's not correlation.
Why not? That's literally (if A then B) according to your definition.
And we're trying to deny that his behavior is even correlated with Linux' success?
If someone prefers softer conduct, they are free to fork the kernel and start their own efforts.
The big issue I see people reacting to is profanity. You can be as hard on someone, given the nature of the infraction, without using profane language or denigrating someone.
If they don't comply, threaten exactly what Linus threatened, no more commits will be accepted.
While I don't disagree with Linus' right to speak as he does. He can be just as effective without the type of language he uses.
Some people don't care about "foul language" some others clearly do...
> It's telling a contributor that their contributions are worthless, cannot be fixed, and other ad-hominem angry insults that just fosters a macho, jockish atmosphere in Linux that has demonstrably alienated capable contributors.
I'll quote bits one at a time.
> It's telling a contributor that their contributions are worthless, cannot be fixed
What if they are? How do you handle the situation?
> and other ad-hominem angry insults
I would argue that saying some patch is worthless and cannot be fixed isn't ad-hominem.
But I'd like to get your view, since it seems you've read a lot on the topic and care about the OSS community.
(Edit: As an aside, my personal policy in this regard is temperance in my reaction, and this is especially easy when written.)
Linux is a project of such a massive scale that Linus has to accept kernel commits from circles of trust in his developer community. If someone demonstrates that they don't understand the fundamental goals of the project, and their contributions are accepted largely based on trust, then yes, their contributions are effectively worthless.
They have to be moved to a further out circle and have their work filtered up through others, and you have to second guess every piece of work that they've contributed.
I agree with you completely, but I can see how this can be accomplished, i.e. removal of trust and correction (public at that) without the need to demolish the person him/herself.
I think we can both agree that it's a fine line though.
Personally, "losing your temper" (i.e. something you have to apologize for later) is something that should be relegated to children. Adults should exhibit self-control in this regard.
You can get the "job" done without this. Some have to work harder at it than others. But saying that it's just okay to denigrate others is not correct.
I don't see this particular rant in question to be a personal attack though. Personally, I don't see a macho, jockish atmosphere to the Linux kernel community either. Also, I'm also not particularly concerned whether an environment is cultivated where anyone feels they can contribute. People contribute to the kernel out of need as well as want.
To directly address the part of the comment about otherwise capable contributors (and the Sarah Sharp example): There's multiple kinds of capability. Technical capability isn't the be-all, end-all in this industry. In fact, I think most of us would say that soft-skills are what differentiate high levels of success in this career. If a company's management culture disagrees with you, then you aren't capable of contributing in that atmosphere.
It's not a matter of either party being to blame but a matter of fit between two parties working towards a mutual goal. I don't think it's remotely fair to say that it's solely Linus's responsibility to facilitate a culture where anyone can feel comfortable contributing. Especially with a project as fundamentally necessary where people will have to contribute, regardless of the culture. If someone's incompatibility with the culture trumps their need to work in it, then yes, they should part ways and that should be perfectly okay.
The same applies to personal relationships, marriages, etc. I think it's good to step back from things from time to time and realize that, ultimately, you're dealing with people and they're not always going to value what you value and they're not always going to give you what you want.
Linus is BDFL. That's all you need to know in four letters. Why are people trying to give ultimatums to God? Seems pointless.
I feel it is imperialist for people from one culture to want people from other cultures to adhere to their way of communicating.
Culture ownership is a thing, and Linus and team were there first. Oncomers need to adapt, or go elsewhere. They certainly don't need to provide this constant distraction.
I don't think that would be a good argument to make from either perspective. If people who choose to leave the community don't contribute you can't really measure lost contribution.
That not being the crux of the issue, we should focus on the following.
Just because a product is successful does not mean that the abuse that happens during development of that product is good or okay. And I think that's really the gist of what people are saying.
It exists and is perpetuated in a culture's lex lingua precisely because it is an effective tool.
Expletives like this cut right through rational and emotional filters to trigger exactly the kind of response Linus was looking for -- after three weeks of arguing, the guy finally realized his mistake.
That's not the choice; there are other, more effective ways to produce quality code; they are well known and well tested. I would expect that Linux loses more quality code, from contributors who have better things to do than deal with unprofessional behavior, than it gains.
The evidence doesn't bear that out. I would expect more contributions from experienced developers who don't care about the words used in kernel mailing list discussions.
Acting out is actually dishonest and it's mostly about a hidden message. It's a failure to recognize and deal with your won frustrations which you then take out on others, usually when an opportunity presents itself to rationalize your behavior - someone does something you perceive as wrong, so they become a justifiable target for the anger that's already there. What I read in the email's message is, 'I'm out of control, I'm not able or willing to mange my emotions, so you better watch out'. That is a poor management and communication technique.
IMHO, a leader or manager should hold their leadership and management work product to the same standard that they hold their subordinates' technical work product. If they want the highest standards for the kernel code, they need to have the highest standards for their communication and other conduct.
A great challenge of being the boss is that there is nobody to hold you to high standards; you have to do it yourself and that's not something people are good at. As they say: Power corrupts, and absolute power corrupts absolutely. Clearly, this message could have been communicated much more effectively - while being truly honest and without hidden messages or room for interpretation - if the communicator chose to make an effort.
Finally, if this form of communication is effective, do others communicate to Linus in this manner? Does he ask them to?
- Speaks in platitudes about the topic in a way that shows a thin understanding of the context and only sounds smart to people that also aren't familiar with the context.
- Armchair psychiatry used to advance a moralizing message.
- All over the place while deep in a comment thread, seemingly more interested in hearing themselves talk than carrying on the conversation.
I considered those things myself before I posted it. However, I didn't see how to overcome them; some issues don't lend themselves to strong factual bases, and some are much more nuanced than can be addressed in a few words - issues such as leadership - and yet they still are important enough to discuss. The problems of the world don't always conveniently fit our model of how we prefer to address them. How else could these issues be addressed?
> It's a cliche hacker news comment
This I strongly disagree with; these issues are rarely addressed with much serious thought and that's one reason I posted it.
I couldn't agree more.
More than ten years ago I was involved in the Monotone project. It was a VCS which was an ancestor to Git and a contemporary of Mercurial.
That project really prioritised good conduct, and having a well functioning community. It was a huge awakening for me. Insisting, gently, upon respectful and kind behaviour made it a project I'm proud to have been a part of.
I'm still grateful to graydon, pcwalton and all the other folks that made it such a great project to be involved with. In free software we need more leaders like that, who set the right example.
Respect and kindness are great virtues when you're shipping widgets. If your product failing means that end-users are going to physically suffer and/or die, I don't think they're going to care one bit about those virtues or respond in kind though.
I'm not saying you can't run a big project without kindness and respect, but I'm saying that's way down the list of importance vs not harming your users. Whatever it takes to get that chief goal accomplished needs to be done. Linus' approach has clearly been working for decades now...and it especially is in this instance.
Linus is still a dick and it isn't funny, refreshing or cool.
If this was some Joe Schmo at a random company he'd be fired for treating co-workers like that. Since it's Linus it's hero worship.
There's a thicker-than-fine line between being hostile to new contributors and being unkind, and tolerating bad practices from people who ought to know better.
And behavior can be changed.
If someone criticized your code, taking it as a personal attack is YOUR problem. If your behavior is criticized, it means you can improve: acting like a fool may not mean you're a fool. It's on you to disprove it.
And he only responded this way after 3 weeks of unacceptable behavior. If he blew up out of nowhere after the very first report of a potential problem before it was even confirmed, that would be a different story (though that's something that probably happens in real companies every day).
I think you must have worked for some horribly unprofessional companies. I've worked places with tight deadlines before, but berating your colleagues or employees with profanity is just ridiculous. I would walk out on the spot if anyone spoke to me the way Linus did in that email.
I have for sure, but the worst of those companies was better than fortune 5 (if I said exactly, you'd know which company), so while primitive they obviously manage to get results that coddling hasn't.
EDIT: And as for walking out, if I were your manager and you broke customer systems and made excuses for 3 weeks about it I wouldn't be yelling at you. I'd be firing you.
The problem was fixed; nobody was harmed; lessons were learned. The sum total of effect of this "Linus tirade" seems overwhelmingly positive. But just because he didn't conform to your arbitrary standards, you write him off?
Linus is more humanist in this case than your policy apparently allows.
You stupid, mouthbreathing motherfucker. How can you sit there and say "nobody was harmed"? I was harmed by having to read that word-vomit, and I've been further harmed having to respond to your boundless idiocy. You have no idea how many people have been put off working on open source projects because they'd rather contribute nothing than have to interact with human shitstains like yourself or Linus.
How's this for a positive comment? Jesus Christ I hope I never have to work alongside a worthless rat bastard like you. Your family should be ashamed to have raised such a sack of shit.
[Look how clear and direct I've been! Isn't it great!]
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.
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.
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.
We tend to excuse people for being bratty assholes when they're smart and correct. Which Linus was here.
Doesn't make it right but it's not just a Linus problem (I mean, generally), it's a people problem.
> trying to shift the regressions somewhere else is bogus SHIT.
That's accurate and specifically points to the unacceptable behavior that needs to be fixed. Linus's "WE DON'T BREAK USERSPACE. EVER." policy is well known, documented, and mentioned frequently. It's reasonable to expect anyone submitting patches to understand this, which makes trying to shift the blame elsewhere... well... "bogus SHIT", regardless of the specific words you use to describe it.
> I will stop pulling apparmor requests until the people involved understand how kernel development is done.
Note that Linus is specifically indicating that this is fixable. Given John Johansen's very commendable apology (see link in grandparent comment), it looks like the message was understood. I suspect this will work out much better in the future.
--
edit: Diluting language to make it "nicer" can remove important information. See: "How a plan becomes policy" https://funnyshit.com.au/the_plan.html
The rule of thumb I've seen in your typical management oriented business books ( eg, your books / training like Crucial Conversations: https://www.vitalsmarts.com/crucial-conversations-training/ ) is to be "persuasive, not abrasive" as that site says. The issue with being abrasive is that one way people might react is by instinctively attacking back -- no matter how technically correct you are, f-bombs and personal attacks might tempt others to throw counterpoint f-bombs and personal attacks back. Another is that repeated behavior along these lines might drive away some people who would rather not see profanity and anger in their mailbox.
Everyone loses their temper occasionally, and John Johansen reacted in the way you should to someone who loses their temper.
Unfortunately, the Linux community as a whole has a reputation in some circles for being overly "hostile" and "toxic". Linus himself has this reputation. How much this reputation dents Linux contribution and usage isn't known, but I doubt anyone can say that this is a positive.
Except that it is still being used unlike the other "nice" projects. BeOS. For example.
What I know is that I've never read advice geared for managers which states that the route to success comes from being an abrasive boss.
I don't see how this is a personal attack. I call the quoted comment a plainly-stated critique of a developer's portfolio. If you have repeatedly demonstrated a problem following basic requirements (ref: "denying the regression now for three weeks"), that's a good reason to presume problems might exist (i.e. "your code cannot be relied upon"). Linus tends to write this type of "blunt" letter only after other ("nicer") attempts have repeatedly failed, and a pattern of problematic behavior exists.
Accurately describing someone's reputation based on their actual work and behavior is not a personal attack. Without false claims - aka actual slander or libel - you earn your own reputation which other people can and will include in their opinions about you.
> The profanity is also unnecessary.
I don't see any profanity in the quoted comment.
> the Linux community
...is another matter entirely, and a discussion for another thread.
From my viewpoint, the problem with the personal attack is the overreaching scope and the hostile wording, not necessarily the critique. It is easy to be firm about laying down the rules of development without getting into the realm of "your entire code and opinion".
There is absolutely nothing wrong with his later post on this in my opinion ( http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html ) and I don't think he's any less firm about the development rules here.
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.
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.
Wow. Now that's how you do an apology. If anything my confidence in this guy is increased.
Yeah, this is a _very_ professional response to a (typical for Linus tbh) very emotional (but correct) post that could be easy to react emotionally to.
There are ways to use that language without being a prick about it though. Linus does not have that ability.
My understanding is that some distros (e.g. OpenSUSE) ship with AppArmor in a whitelist mode where things have to be explicitly permitted by policy, otherwise they're denied by default. AppArmor introduced a new class of actions that wasn't there before, and with these restrictive policies it's causing daemons to crash (because it gets auto-denied).
The whole point of these policies is to not expose new attack surface if it's not needed by the software. It's going to break whenever AppArmor will start supporting more checks, unless policies get pinned to a specific version of AppArmor. But AppArmor doesn't currently support this (they refer to it as "features ABI" in the thread).
WAI?
On the other hand, if it's bad enough it certainly makes sense to treat it as a kernel bug. The difficulty lies in finding where to draw the line.
> All that afaics doesn't matter. If a new kernel breaks things for people > (that especially includes people that do not update their userland) > then it's a kernel regression, even if the root of the problem is in > usersland. Linus (CCed) said that often enough
[1] http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
It's clearly an error on the part of the kernel if the owner of said kernel has specific expectations of behaviour on upgrade with respect to user spaces and those are not being met.
The contract in this case is that there will always be a version number, and anyone who expects it not to change is an idiot or just being obtuse.
> anyone who expects it not to change is an idiot or just being obtuse
If this was the case, Microsoft would have never had to skip from Windows 8 to Windows 10 (see below in another comment: "starts with Windows 9" was used in the wild to detect Windows 95/98).
> anyone who expects it not to change
And you appear to be using an example of a version-change curiosity as a counterexample. It is not a counterexample, because the version number in question changed from 8 to 10. In my original formulation, anyone who claimed to worry that the number would stay 8 forever was being an idiot or being obtuse.
I think that holds up. It was not part of my comment, but someone who expected it to be 9 would not be an idiot or obtuse, because that would have been a reasonable guess, absent additional information. They were expecting it to change but were surprised by an exceptional circumstance.
But this is getting a bit silly; there may be someone out there who thinks version numbers should be immutable across versions, but I bet they're pretty lonely. It was an example picked up while making a wider point.
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]
[0] - http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
"There's a number of fields in /proc/<pid>/stat that are printed out as zeroes, simply because they don't even *exist* in
the kernel any more, or because showing them was a mistake (typically an information leak). But the numbers got replaced
by zeroes, so that the code that used to parse the fields still works."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.
1: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
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.
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.
From: https://felipec.wordpress.com/2013/10/07/the-linux-way/
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.
[ 14.586798] SELinux: Permission getrlimit in class process not defined in policy.
[...]
[ 14.586887] SELinux: Class infiniband_pkey not defined in policy.
[ 14.586888] SELinux: Class infiniband_endport not defined in policy.
[ 14.586888] SELinux: the above unknown classes and permissions will be allowed
It is. You get the security you explicitly ask for, no more, no less. If you want more, you get to know what new is there, and enable it.
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".
''' People should basically always feel like they can update their kernel and simply not have to worry about it.
I refuse to introduce "you can only update the kernel if you also update that other program" kind of limitations. If the kernel used to work for you, the rule is that it continues to work for you. '''
It's a very good summary of the Linux kernel userspace compatibility policy.
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.
> 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
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.
Edit: fix styling
Though it is annoying if you're at the receiving end of it, own up (the opposite of what the patch author was doing)
If that's the way problems get solved, then he's right in using it
If you ask nicely and people don't do it, or keep ignoring it then you up the tone
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.
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.
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.
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.
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.
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
> getting an incompetent bozo fired
> "bullying"
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?
Bluntly telling someone they really screwed up and need to stop denying it isn't bullying. Someone being mean isn't bullying.
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.
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.
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.
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.
"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.
> Especially factoring in grass roots support, he was more popular than Hillary
If that is objectively true, he should have won the primary. He didn't.
> and would have wiped the floor with Trump.
[CITATION NEEDED]
> If you allow > And then you still don't learn > if you insist
Why are you calling me out? I didn't vote for him. Go project somewhere else.
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.
Ass-chewing isn't generally beneficial as it makes people defensive and potentially angry themselves. The mea culpa is good: "And again sorry, I screwed up, it should not have happened, my perspective was incorrect and I know I need to make it right." This is a great response, defuses the conversation and makes it clear that it's going to be fixed.
As someone who's gotten chewed out before, all it does is leave a bad taste in your mouth and most likely going to quit the company or possibly the project. Honestly, the threat of rejecting future commits and/or rejecting his opinions was by far the best thing in Linus' response, b/c those cut straight to your potential to contribute to the project.
That seems to be his direct intent, and being angry does help get this point across.
> 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.
When online, people can't tell when you're being subtle.
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.
The people who don't have those tools control the horizontal, they control the vertical too. If they say your personality is wrong by definition, who are you to question them?
Without getting snarky, that's just the status quo right now. In some number of years they'll treat it like a big discovery that their previous assessment of all social interaction wasn't 100% perfect. Let's just hope that when it comes the pendulum swings our way and I get to stop wearing an emotionally-dishonest husk of a personality to the office.
[0] For the sake of avoiding predictable tangents, I mean aggression that is obviously not going to escalate to physical responses, or even anything more than rejecting patches.
But my dad was ex-military, then a logging contractor, then a heavy equipment mechanic, and I grew up working with him. When there are firearms, chainsaws, bulldozers, or heavy objects dangling from cranes, you don't have the luxury of couching your criticism in weasel-words or crafting the compliment-criticism sandwich. If somebody is fucking up, you let them know in no uncertain terms, because somebody could get hurt.
It is this that gave us things like smilies and Poe's Law.
This sums it up: https://news.ycombinator.com/item?id=15610108
[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.
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.
This part is probably globally true :D
It was shit. I left.
A boss who gets stressed out, or who transmits and amplifies other people's stress around the office, is not doing their job properly.
https://www.jwz.org/doc/worse-is-better.html (copy-paste the link in a new tab. Do not click on it)
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.
Wish this would be a goal for more of the application environment on Linux than just the kernel.
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's point of view on overall "professionalism": https://lkml.org/lkml/2013/7/15/547
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.
Remember when they changed behavior of memmove, which broke user code including the damn flash player, and then blamed users for that?
E.g., Drepper seems to be the person who is an opposite of Linus.
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.
Makes me scared to even _consider_ contributing...
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.
Linus then calmly and politely reminded him that the official policy of kernel development is that they never introduce changes that break applications.
It will only get worse over time.
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.
Pleasant and good mannered application programmers gasp when real men (aka systems programmers) communicate at each other.
Not hard to imagine at all. He could exercise the same amount of authority without losing his shit and would get exactly the same result.
It's one of his flaws and that's fine, but arguing that this kind of behaviour is somehow helpful is just ridiculous.
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.
The main rule for kernel development is "you don't break userspace'
And yet John did. I think Linus is hard on those that break this rule because he has stressed this rule time and time again in the past.
Also, refusal to own up to a regression is kind of infuriating.
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.