Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts
lkml.org
lkml.org
Personally, I think this level of disappointment/anger/trust issue would be best dealt with face-to-face or via a phone or Skype call, or at least an off-list email. However, given the unique situation of the Linux kernel, I think it was appropriate to send to the public list.
The only line I'd remove or finesse is "Yeah, this is complete garbage." Otherwise, I think this is a great example of how to convey anger without personally attacking anyone. Linus doesn't swear, he doesn't call Eric stupid or curse him out, but he still says what he means: The behavior was out of line, it has to stop, and, most importantly, it represents a breach of trust.
He's not saying Eric is a bad, stupid or worthless person - he is saying that in this instance, Eric's behavior is bad. That's the key difference.
Still too aggressive, still too personal. The reprimand part of this email really shouldn’t have been made public. The tone used was not necessary to convey the ideas he was trying to communicate.
Don’t get me wrong, the lack of direct insults/namecalling is definitely an improvement, but I’d personally still hate to work with someone who chooses to communicate to their subordinates this way.
If Linus doesn't put his trusted submaintainers into line, they'll think they can violate core rules of kernel maintenance ~ something as bad breaking userspace.
Linus was right to reply exactly the way he did for such breakage.
There's nothing terrible about reprimanding someone you trusted, especially in front of everyone else.
Helps to tell people to not repeat this level of mistake.
The basic principle that I think Linus is trying to follow is, "criticize the <subject matter>, not the person" (whether you're criticizing someone's ideas, someone's work, or someone's behavior). Linus isn't saying that Eric is complete garbage, he's saying that a specifically quoted statement is complete garbage for reasons that he expands on later.
I have seen things like this interpreted as personal attacks before, even though they don't actually parse out that way logically, but for someone (like me) who has to learn these rules instead of instinctively knowing them by feel, this is an easy mistake to make.
He indicates that trust has been breached, temporarily, withdraws his willingness to accept patches due to the breach of trust, and specifies precisely how Eric can rebuild trust:
> until you have made it clear that you comprehend this very fundamental issue
So fundamentally we have the same practical problem as with personal attacks: that it's bypassing what should be a discussion on technical merit. Maybe Eric's feelings aren't hurt, but it's still not clear we're building the best kernel we could.
> () Yes, there are exceptions. We have had situations where some interface was simply just a huge security issue or had some other fundamental issue. And we've had cases where the breakage was just so old that it was no longer fixable. So even rule #1 can sometimes have things that hold it back. But it is very* rare. Certainly nothing like this.
Strong words are best way to convey the issue in a way that leaves no room for inaccuracies.
Sugarcoating it helps no-one as some people might inaccurately think it was not a big fuckup. If you use words from the very end of the expressivenes range there is no room left to doubt
It is entirely possible, as we see here, to convey the criticality of something without crossing over into personal attacks.
Absolutely.
...
Convey to the intended recipient, with his inevitable personal/emotional/etc. attachments to the topic, in such a way that it takes the intended effect?
A pending question-of-fact, and one that can only be answered very indirectly and in the long run.
Heck, if the answer really is "no", then it's possible we may never know! (until the NSA pwns us all, or at least pwns the subset of us who didn't kowtow to whoever the central socio-econo-political authority of that era will be)
That depends on the context. When you're talking about changing ingrained behaviors, emotional shock and awe can definitely be necessary and the shortest, most painless path to resolution.
the underlying incorrect assumption is that everyone will do the right thing, if only nicely and logically talked to. This is not true and obvious to anyone with experience managing large amounts of people, especially so when firing is not an easy option.
I've yet to see abusive management tactics work in the long term. It might work in the short term, but people with the means will take it as a signal to jump ship because no adult is going to accept abuse if they don't have to.
I've heard your exact sentiment echoed by people who aspire towards management, and it always comes across as a weird power trip fantasy.
Like I said, depends on the context. Being mean has it's place, as does being nice. Those are the extremes and the Lions share in the middle is non-emotional transactionalism.
This sort of cold-blooded rational takedown is way more effective.
Iteractions between different permissions and conditions is getting ever more complex
But yeah, kernel shouldn't break userspace, and this should have been internalized already by the maintainers
Unfortunately, unless there is a single, united team focussed on this single goal (kernel is not by design). Then some fingers will be burned, because of the complexity of getting it right.
Some contributors will struggle, and others will fail at it. Unfortunately, that’s just stats.
I wish they’d just move back to the original unix permission scheme, plus jails.
BSD and solaris did much better jobs of this a decade ago. Hopefully one of those will eventually take over again.
(Unless your chosen metric-of-value relies on feelings instead of actual concrete results.)
Compare to: https://lkml.org/lkml/2012/3/8/495 That's the same guy, so clearly, the swearing didn't have much lasting effect :)
Hopefully this won't happen, but it's entirely possible that this change will result in Linus finding himself with a much greater number of broken, half-broken and/or subtly-broken PRs to review than ever before, increasing the chances of something like https://lwn.net/Articles/57135/ succeeding.
And having a kernel backdoor ship worldwide is way worse than having a few recalcitrant kernel developers be exposed to - oh no! - coarse language. Results > the "fee fees".
https://www.recurse.com/manual#sub-sec-social-rules (via Pony lang CoC)
In my books, Linus was always alright, but I like more polite yet firm Linus even more. Best of both worlds.
Merry Christmas to Linus and all Linux contributors (!), and thanks for one of the greatest gifts of modern time.
It‘s too direct but easily understandable.
Seems like the new style comes across as just heavily disappointed and with a breach of trust, which I guess compared to the plain anger of old is easier to convey without swearing and vivid imagery.
I think I personally would still prefer to receive one of the old style messages, but that's probably just because I better handle people angry with me than disappointed.
This, so much this.
I was raised in a hot-headed european household where people would get angry and argue energetically, often using coarse language. It clearly demonstrated care, passion, and a willingness and desire to continue suffering together.
The low-energy disappointed response sends a very different message. It's probably my upbringing, but it leaves me feeling like the collaboration is over and I should pack up my things.
That's actually not that unusual. I actually found this email a lot harsher, in a certain sense.
When you losing your temper and swear at people, it's scary and intimidating because the hindbrain recognizes that behavior as, "this person is very likely to hit me". And since hindbrains are hindbrains, this reaction still happens even if it's over the internet. But you also end up making a big fool of yourself and leading people to discount what you're saying out of hand, because obviously you're angry and worked up. People losing their temper are hilarious from a safe distance, which is among other things the basic premise of Lewis Black's entire career as a comedian.
When you calmly and methodically communicate using only facts and logic, you do lose the hindbrain "this guy is going to hit me" reaction. But you get something more powerful. Heated anger indicates an unresolved problem. That's why you're all worked up--you have a nice little adrenaline rush going because you've detected a problem and you're fired up to go fix it. Being calm, even cold, is much more final: it indicates that everything is resolved. This approach completely disarms the defense mechanism of saying "Linus is just a dick" or thinking that he only said what he said out of anger.
People get angry over things they care about, but they'll cool off, and you'll learn what matters to them. However, if you're playing by The Rules and break them, you'll carry that mark for years, regardless of whether or not who's enforcing got over the incident.
Several months ago at work I found a vendor app that was calling listen(0), i.e., listen for up to 0 connections, and worked fine on older kernels because they rounded to a minimum of 8. Newer kernels stopped doing that. Nobody cared. Nobody got criticized, constructively or unconstructively. (By the time we noticed it was several kernel releases upstream so bringing it up would just be asking for another change to userspace.)
Linus himself broke userspace once in the hope nobody would notice. Spoiler: they did. https://lkml.org/lkml/2017/5/29/541
And that's not counting all the things that aren't part of the stable interface like procfs and sysfs nodes, device names, etc. There is a clear version of what Linus is trying to say. He's just never said it.
My fan controller used the sysfs paths mentioned in the commit message directly. So while the commit is probably correct that users of the lm-sensors library would not be affected, my application was.
It was relatively easy to fix since I was the only user of the application, so I didn't care about being compatible with older kernels.
If Linus didn't fanatically enforce backward compatibility, nobody could rely on Linux for mission-critical systems.
This is factually untrue. CentOS 5's glibc makes system calls using the vsyscall page, which is off by default in e.g. Debian stable kernels because it's a huge security risk (it's a page at a fixed address that makes syscalls, it's an obvious ROP target and makes ASLR completely irrelevant, and it also contains fixed data so it's a useful target for other attacker-controlled pointers too). So CentOS 5 containers do not run on up-to-date Debian systems unless you reboot and change a kernel option.
I think vsyscalls are on by default in Linus's tree but no distributor is gonna turn them on and take the security risk. The knob was put there so it could be turned off.