A kernel code of conduct enforcement action
The Linux Foundation Technical
Advisory Board (TAB) has decided to "restrict Kent Overstreet's
participation in the kernel development process during the Linux 6.13
kernel development cycle
" based on a recommendation from the Code of Conduct
committee. In particular, the scope of the restriction will be to "decline all pull
requests from Kent Overstreet
" during the development cycle.
Overstreet is the creator and maintainer of the bcachefs filesystem.
This
action stems from a message
Overstreet posted back in early September that was abusive toward another
kernel developer; there is a fair amount of back-and-forth about the
incident and the committee's attempts to extract a public apology from
Overstreet in that thread. Overstreet has published a lengthy blog post
describing his side of the story.
Posted Nov 23, 2024 2:12 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (20 responses)
The only reason I raised this as far as I did is because I think we do have some cultural issues worth talking about and seeing if I can address. I don't want individuals getting attacked; this was just a personal story to illustrate things that are not terribly atypical for LKML.
Posted Nov 24, 2024 14:49 UTC (Sun)
by lkundrak (subscriber, #43452)
[Link] (11 responses)
Posted Nov 24, 2024 15:05 UTC (Sun)
by pizza (subscriber, #46)
[Link] (4 responses)
While I applaud your attempt to be polite and insulting at the same time, 'hate' in this context has legal definitions, nearly always containing explicit threats of some sort, usually tied in with some sort of protected category (eg gender, race, disabilities, that sort of thing)
This may be "insulting" but calling it "hate" massively belittles those who have, and still do, receive vitriolic missives that all-too-frequently escalate into physical harm.
Posted Nov 24, 2024 15:21 UTC (Sun)
by intelfx (subscriber, #130118)
[Link]
This is most definitely not something that ought to be applauded.
Posted Nov 24, 2024 15:23 UTC (Sun)
by lkundrak (subscriber, #43452)
[Link]
My criterion was not a legal one. What I considered "hate" were insults with zero bearing on technical merit, that I could only understand as stemming from personal animosity.
Posted Nov 24, 2024 15:32 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
I'm more than willing to accept a legally imprecise use of the term considering that Kent's phrasing, word by word, *would* be considered hate speech in another context (for example if directed to an ethnic or gender minority).
Posted Nov 24, 2024 19:48 UTC (Sun)
by daroc (editor, #160859)
[Link]
Posted Nov 24, 2024 22:29 UTC (Sun)
by koverstreet (✭ supporter ✭, #4296)
[Link] (5 responses)
Obviously there has to be limits on this sort of thing; we can't be driving away and we can't be venting all the time. But on the "being nice" vs. "prioritizing our responsibilities" axis, I think the pendulum has swung a bit too far.
Certainly in bcachefs land I wouldn't mind hearing a bit more (well justified, high information content) rants and complaints.
Posted Nov 25, 2024 0:19 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
I've been funding bcachefs via Patreon for quite some time. I like what you're doing, and I'm actually on your side in this particular argument.
However, it was not the heated discussion that caused the action, but a direct personal attack on an individual. This is not acceptable, and it's never a good idea anyway.
Posted Nov 27, 2024 13:23 UTC (Wed)
by Rudd-O (guest, #61155)
[Link] (1 responses)
He had already sought to discuss and settle the matter with the individual. He also publicly acknowledged that he lost his cool.
Full context with receipts here:
https://www.youtube.com/watch?v=EeEo8Mg6fMg
I'm a long time ZFS user, but I think I will start contributing to Kent's Patreon now.
Posted Dec 20, 2024 17:18 UTC (Fri)
by tbird20d (subscriber, #1901)
[Link]
Posted Nov 26, 2024 1:25 UTC (Tue)
by AdamW (subscriber, #48457)
[Link] (1 responses)
Whether other people are okay with you doing it to them is up to *them*. Not you.
Posted Nov 30, 2024 23:19 UTC (Sat)
by raven667 (subscriber, #5198)
[Link]
To put a finer point on it, even if two people have the personal relationship and consent to speak more roughly with each other, as we sometimes do with close friends and colleagues, in a public forum that may not be appropriate behavior to model for the other participants as some will emulate that tone without context and others will quietly leave because they don't consent to be treated that way. The most senior and respected members of a forum set the tone in how they conduct themselves and what they accept from others.
Posted Nov 25, 2024 15:34 UTC (Mon)
by bmorel (guest, #138892)
[Link] (3 responses)
I do now know enough (nor am seriously interested into, really) of the drama to talk about it, but I have the impression that they changed the CoC so that they would be able to apply a sanction retro-actively? I do not know what the aim of the organisation is, but laws or rules being retroactively applied is one of the characteristics of terror-based government.
Posted Dec 14, 2024 20:51 UTC (Sat)
by jospoortvliet (guest, #33164)
[Link] (2 responses)
I'm sure not all people, when being asked or nudged to apologise publicly, appreciate that. But the kernel is a diverse and large community, and everybody has to adapt. Some people find it hard to recognise the effects of their own behavior and some are misbehaving because it strokes their ego to get away with it; or they feel a need to keep out others who they feel aren't up to their 'standards' by such behavior. Other people just always have to win, or get very stubborn when they encounter what they see as an authority. I can empathise with that last one, personally.
Whatever the reason, a single person who misbehaves can easily keep tens to hundres of people from engaging in the community - so, no matter how brilliant somebody is, if they can't play well with others the kernel will be better off without them.
Of course, the best solution would be for people to act like adults, learn and adapt - personal growth and all that. Or, if not, grumpily behave even if you don't agree. Sometimes you just have to take the loss. Again, I can emphatise.
I'm a little triggered by a piece in Kent's blog:
> But, my response was to say "no" to a public apology, for a variety of reasons: because this was the result of an ongoing situation that had now impacted two different teams and projects, and I think that issue needs attention - and I think there's broader issues at stake here, regarding the CoC board.
That really sounds like somebody who knows they are wrong but does not want to give in - does not want to 'lose' and thus tries to present it somehow as a "principled stand". And then, of course, we see him trying to present himself as the 'big guy' by telling everyone not to follow his example and also yell at the maintainer he yelled at. Expecting applause for telling everybody not to cut themselves on the knife you used to stab somebody? Hum, we're not in kindergarten.
Anyhow, that's why...
Posted Dec 15, 2024 1:17 UTC (Sun)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Yeah, like Viro and Torvalds and a few other senior maintainers who apparently get a free pass on any sort of verbal abuse, passive aggressiveness and all kinds of other underhanded behavior (cf. the recent Rust-for-Linux upheaval).
> Some people find it hard to recognise the effects of their own behavior and some are misbehaving because it strokes their ego to get away with it; or they feel a need to keep out others who they feel aren't up to their 'standards' by such behavior.
Yup, precisely.
I wish these stringent standards of conduct were applied to everybody equally, not just to the boogeymen du jour.
Posted Jan 16, 2025 23:25 UTC (Thu)
by jospoortvliet (guest, #33164)
[Link]
I'm not saying they're perfect, or ever were. But saying they got no pushback, or that they ignored said pushback, is just not true.
Posted Nov 26, 2024 7:08 UTC (Tue)
by mstsxfx (subscriber, #41804)
[Link] (2 responses)
Let me just add couple of notes and clarifications.
Michal Hocko
Posted Nov 26, 2024 8:16 UTC (Tue)
by koverstreet (✭ supporter ✭, #4296)
[Link] (1 responses)
Sorry I didn't end up doing the rewrite to incorporate your feedback - I ended up putting up what I had because at the last minute, when it seemed like things might go somewhere productive with the CoC, they didn't, so I felt I had to go with what I had, I'd pretty much lost energy to do more at that point.
Hoping we can get something done on PF_MEMALLOC_NORECLAIM for the Rust folks at some point - let me buy you a beer at LSF?
Posted Nov 26, 2024 8:39 UTC (Tue)
by mstsxfx (subscriber, #41804)
[Link]
TBH I am not even sure what this means. So please try to define the problem (why does Rust support need this). All ideally on the mailing list.
> let me buy you a beer at LSF?
I am always open to talk.
Posted Nov 30, 2024 1:56 UTC (Sat)
by ReDress (guest, #174819)
[Link]
You talk about productivity. You did talk about productivity a few times. In the blog post and probably also here in the comments.
This seems like a valid concern to me since we're yet to see how the CoC ages. It will probably age well but at the same time, leaving the allowance that it leads to reduced productivity might be a good idea until it is proven and it is evident that it does not. At the same time, since the otherwise is not proveably true, it doesn't seem fair to blame the CoC.
That aside, ideas on how to avoid reduced productivity in kernel development might be great. Ideas on how to improve productivity regardless of the CoC would be great.
PS: Anarchy is not known to increase productivity.
Posted Nov 23, 2024 2:24 UTC (Sat)
by JMB (guest, #74439)
[Link] (19 responses)
I would really like to have explanation why excluding Russian kernel hackers and deleting
Giving the impression that Russians may deserve that treatment just by warfare of their
The way Rust people were blocked to give a talk - nothing happened - and those videos were
And here it is on technical ground - and was treated on a much too high level - or
From my perspective there is no justification for this suspension ... and I don't see
Additionally - why had been mitigations (some of them without positive effect)
So I would like Mr. Corbet to give some insight of why this is played on that level in
If this should be fair - I would like to read about problematic behaviour and possible sanctions
Posted Nov 23, 2024 2:34 UTC (Sat)
by cypherpunks2 (guest, #152408)
[Link]
Posted Nov 23, 2024 8:52 UTC (Sat)
by patrick_g (subscriber, #44470)
[Link] (4 responses)
Because that's not what happened?
Posted Nov 23, 2024 18:55 UTC (Sat)
by geert (subscriber, #98403)
[Link] (1 responses)
Posted Nov 24, 2024 5:12 UTC (Sun)
by HenrikH (subscriber, #31152)
[Link]
Posted Nov 25, 2024 9:37 UTC (Mon)
by rbtree (guest, #129790)
[Link] (1 responses)
Posted Nov 25, 2024 13:18 UTC (Mon)
by daroc (editor, #160859)
[Link]
Posted Nov 23, 2024 9:33 UTC (Sat)
by tytso (subscriber, #9993)
[Link] (6 responses)
The problem was that the speakers chose an example which was too complicated; they may have been proud of the expressive power of Rust, but if the goal is to try to convince people that using Rust for file system code is a good idea, it might have been a tactical mistake. If the speakers had 2-3 hours to give.a tutorial on the Rust language; of its syntax and semantics, then as the climax of the talk, perhaps they could have shown off this super-clever construction. But they ran out of time, because they only had 30 minutes, and they pushed the audience into the deep end of the pool without any preparation --- is it any wonder that a lot of questions were asked and the discussion became tense?
So no, I don't think there was any Code of Conduct violation at the Rust session. It is not a CoC violation to have technical discussions; even tense technical discussions. It is fine to attack ideas; where it crosses a line is when people are attacked.
The technical points which Kent has raised, for example in his Patreon post, are really beside the point. Regardless of the technical arguments he might have been trying to make, it was the personal attack which went beyond the pale vis-a-vis the Code of Conduct. And while Kent might have been frustrated by the technical discussion, it didn't justify the public personal attack, and the way to repair the harm from a public attack is a public apology.
Finally, note that there have been other Code of Conduct violations over the past six years, and the Code of Conduct committee has investigated and stepped in to address them. The only reason why this situation has been exceptional is because it is the first time that an enforcement action has been needed; most of the time, coaching and education from the Code of Conduct committee is sufficient. See the Code of Conduct committee reports here: https://www.kernel.org/code-of-conduct.html
Posted Nov 24, 2024 12:14 UTC (Sun)
by rweikusat2 (subscriber, #117920)
[Link] (5 responses)
Criticizing other people's ideas will usually be interpreted as the strongest conceivable form of personal attack and will usually cause them to go completely ballistic when (as they believe they are) retaliating in kind and this behaviour will even usually gain almost unanimous public support.
Posted Nov 24, 2024 16:26 UTC (Sun)
by tytso (subscriber, #9993)
[Link] (3 responses)
If someone suggests an idea that might work for their subsystem, such as for example mm, but some other subsystem maintainer (say, bcachefs) thinks it doesn't work for them, and the bcachefs maintainer attacks the mm subsystem proposal, this is not a personal attack. It is an attack on an idea, not a person. And by the way, Kent has done this a lot, himself, but this is not why he was called out. He was called out because of his attack on a persom, not on how he argued his ideas.
It's also not true that such behavior will gain "unanimous public support". Even on Kent's Patreon page, some of his supporters/funders called him out as going too far. I am hope that perhaps if he were to meditate on how he has started to lose the room even among what should be his strongest supporters, maybe he might figure out that his behavior is ultimately self-defeating.
Posted Nov 24, 2024 18:33 UTC (Sun)
by rweikusat2 (subscriber, #117920)
[Link] (2 responses)
I totally agree with your point: That's how it should be. But in practice, it frequently ain't so.
¹ As I needed such a driver at that time, I picked this up as a starting point but ended up rewriting most of it to make better use of the features of the hardware.
Posted Nov 24, 2024 20:20 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (1 responses)
> I totally agree with your point: That's how it should be. But in practice, it frequently ain't so.
A lot of people are not comfortable working with open-source for various reasons, one of them being they have some level of emotional connection to their work and feel as you describe.
That's OK - there are plenty of closed-source jobs for them.
Posted Nov 25, 2024 9:39 UTC (Mon)
by rweikusat2 (subscriber, #117920)
[Link]
Posted Nov 26, 2024 15:34 UTC (Tue)
by nicbr (guest, #174696)
[Link]
You can choose to leave, sure, but ime the grass is rarely greener somewhere else.
I obviously know that open source is supposed to be guided by higher principles than for-profit software, but accepting that some ideas can get rejected should never be considered a personal attack. Even if the rejection itself is virulent.
Posted Nov 23, 2024 11:12 UTC (Sat)
by Lennie (subscriber, #49641)
[Link] (4 responses)
Sadly, because they were not allowed by the legal department.
Posted Nov 24, 2024 14:36 UTC (Sun)
by amarao (guest, #87073)
[Link] (3 responses)
Without all of it opensource is doomed to be a bunch of hackkers and nerds, and never be able to achieve enterprise enlightenment.
Posted Nov 24, 2024 15:44 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Posted Nov 24, 2024 16:07 UTC (Sun)
by amarao (guest, #87073)
[Link] (1 responses)
Posted Nov 24, 2024 20:25 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link]
(*) Things wouldn't be different for many other countries though
Posted Nov 23, 2024 13:01 UTC (Sat)
by daroc (editor, #160859)
[Link]
I am not Mr. Corbet, of course, but I will point out that LWN did in fact cover the situation that led to Wedson Almeida Filho retiring from the project [1], the removal of maintainers who work for sanctioned entities from the MAINTAINERS file [2], and, indeed, many other newsworthy events within the Linux community. It's true that we don't report on every mailing list fracas; this one is notable because it has caused a new response from the CoC committee, and because it may impact users of bcachefs.
If you have tips for stories that you think are particularly notable that we seem to have missed out on, you're welcome to email us at lwn@lwn.net.
[1]: https://lwn.net/Articles/987635/
Posted Nov 23, 2024 2:31 UTC (Sat)
by cypherpunks2 (guest, #152408)
[Link] (12 responses)
At least it's limited to only one development cycle.
Posted Nov 23, 2024 2:41 UTC (Sat)
by dskoll (subscriber, #1630)
[Link]
Yeah, it seemed out of proportion to me too, though I agree the language and tone was not acceptable. There was a public apology of sorts in the end in this message. But I guess it came after the sanction had already been decided.
Posted Nov 23, 2024 2:57 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (10 responses)
I'm wondering why no one seems to be able to imagine just saying "hey, this seems tense, what can we do to help", _before_ taking some sort of enforcement action.
Right now, when things on the list get heated, it often ends up as a dogpile - and then if it gets to that point the CoC just picks whoever mouthed off the worst and slaps them.
Hardly conducive to keeping technical discussions on track, wouldn't you say?
Posted Nov 23, 2024 3:18 UTC (Sat)
by cypherpunks2 (guest, #152408)
[Link] (7 responses)
That is a problem. I am hopeful that this action will make enough waves that people rethink the best way to keep things from getting too heated, so long as it doesn't attract so much controversy that development is further derailed. I expect that people will recognize the issues with what happened and will agree with you. I have hope that people will have enough of a nuanced view to understand that it is okay to criticize the TAB's actions without defending or minimizing inappropriate behavior.
Posted Nov 23, 2024 3:23 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (6 responses)
But the people at the top set the tone, so I think that would have to start there.
Secondarily, I do think focusing too much on avoiding heated words and not enough on deeper issues of being able to make progress is a real issue as well, because it means being dismissive in an argument is the safest option.
When things get heated I find that there's often something interesting underneath.
Posted Nov 23, 2024 3:35 UTC (Sat)
by cypherpunks2 (guest, #152408)
[Link] (2 responses)
In the past there has been almost nothing done to stop a community from becoming toxic and abusive behavior was accepted from people who were also long-term contributors. People are swinging too far in the opposite direction to fix things, prioritizing polite discourse to such an extent that it can actually inhibit useful contributions. That's not to say that we should go back to the wild west past, but we shouldn't over-correct and create an atmosphere where people fear not personal attacks, but enforcement actions from up high.
Posted Nov 23, 2024 3:40 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (1 responses)
And it's not just about striking a balance, that leads to very waffly "will we or won't we" enforcement that just drags things out, where the enforcers don't want to commit but everyone knows they're going to. The only way out is coming up with an idea of what we _do_ want to see.
Posted Nov 24, 2024 15:40 UTC (Sun)
by brchrisman (subscriber, #71769)
[Link]
Posted Nov 23, 2024 16:02 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (2 responses)
I think the CoC _is_ looking out for you and your colleagues by stepping in and giving you the opportunity to have a break from the stress, anxiety and subsequent anger that underlies the conflict, but your colleagues are ultimately not responsible for control of your feelings and choices in how you respond to frustrating situations, you need to figure out where the fear and anger come from and why it gets you off your game, I don't know you personally I hope you take the opportunity to decompress and come back with a fresh positive outlook. I'm not sure publicly debating randos in the comments on lwn is doing anything except aggravating a fresh wound, I don't think it's going to help you be the best collaborator, advocate and engineer for bcachefs that you clearly want to be.
Posted Nov 24, 2024 1:47 UTC (Sun)
by cypherpunks2 (guest, #152408)
[Link] (1 responses)
As of the time this comment was posted, I haven't seen Kent debate anyone. In fact, the threads here seem calm and rational. Most people seem to be largely in agreement with him (i.e. sharing an understanding that his response was indeed rude but that the TAB's actions were excessive nonetheless). None of the comments here seem even remotely bellicose.
Posted Nov 24, 2024 13:10 UTC (Sun)
by daroc (editor, #160859)
[Link]
Posted Nov 23, 2024 13:44 UTC (Sat)
by zeroheure (guest, #165859)
[Link]
Not exactly that, but the first reaction was Jonathan Corbet suggested "to calming down a bit". May be you missed his post ?
See https://lore.kernel.org/lkml/8734mitahm.fsf@trenco.lwn.net/
Posted Nov 24, 2024 19:53 UTC (Sun)
by chexo4 (subscriber, #169500)
[Link]
Posted Nov 23, 2024 6:39 UTC (Sat)
by geofft (subscriber, #59789)
[Link] (18 responses)
But I'm not sure I buy the argument that this sort of work inherently involves being acrimonious with each other in code reviews, even if you're otherwise chummy outside of that context.
"Filesystem work is a stressful job" is such an odd claim. Why? IIt's nothing like being a doctor or lawyer or general or diplomat or air traffic controller where situations can deteriorate in seconds and if you aren't doing your best work on zero notice, lives will be lost. It's not even like being an on-call sysadmin/SRE/etc. for a production server whose filesystem is misbehaving. The code in front of you isn't going to change until you run "git pull" and it's entirely at your discretion when to push, too. (Security vulnerabilities are an exception, but the post only talks about them in the context of designs that are known at the time of writing to lead to DoSes, not about a buffer overflow or speculation side channel being discovered and a race to patch it before it's exploited.) It may be a technically difficult and therefore mentally taxing job, but it should be no more stressful than being a sculptor or a carpenter or a poet.
I think Kent's examples actually argue that stress makes the job worse: if people hadn't been so acrimonious about the folio reviews, they might have kept conversing to the point of finding that they shared the same long-term vision without needing a third-party mediator to figure it out. In fact the email at issue here is another counterexample: there was nothing about the code itself nor the technical disagreement that required being acrimonious (as evidenced by Kent's levelheaded explanation of the issue in the blog post). There is nothing inherent about Kent nor his interlocutor that meant that conversations must get acrimonious. It was the increasing heat in the thread that made Kent, in his telling, lose his cool and send a message that is objectively beyond the pale (and, in my opinion, still merits an uncomplicated apology). So the answer is that the thread shouldn't have started to get hot in the first place, and people should have stepped in at the first sign of rancor.
And I do question the idea that people work best by yelling at each other over their code and then being friendly once it's over. In my experience there are some people who genuinely like intense arguments, and some who find them uncomfortable. There are people in this latter group who have nonetheless learned to perform the intense argument because they want to make some progress with people in the former group. But that does not at all mean they like doing so or that this process does not burn them out over time. If it really does work for a specific pair of people - they can yell at each other as much as they feel necessary over direct email without copying a list, over a call, or whatever, and then it's opt-in.
From the stories in the blog post it sounds like heated disagreement is often used not as a tool in itself but a way to push people to expand on technical detail when it isn't forthcoming - to push back against the spreadsheet of decisions without rationale, to cause people to realize that an uninvolved mediator was needed, etc. If this is indeed what's going on, then Linus and the TAB should step in here - maintainers should not be able to block patches without an explanation understandable to at least one of the patch submitter, Linus, or someone on the TAB (which is a _technical_ advisory board, despite its role in CoC enforcement). People who have long-term plans in mind should be encouraged to publicize them. And it seems odd to me to support bypassing a maintainer and landing the patch in Linus's or some other tree directly, while also letting the maintainer continue to hold that role. Either the maintainer had a justified objection, and bypassing will just cause the maintainer to pick up code they'll want to revert (as happened here), or the person should not actually be trusted with the ability to block patches.
I do agree with Kent's comments elsewhere in this comment section that this is an overall culture problem and kernel leadership could do a better job of setting the right tone from the beginning.
Posted Nov 23, 2024 7:24 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (14 responses)
The fight over whether XFS would have metadata checksumming split the team.
Posted Nov 23, 2024 22:25 UTC (Sat)
by Heretic_Blacksheep (guest, #169992)
[Link] (13 responses)
People can disagree without being abusive with each other. Just because the other side becomes abusive doesn't mean you must as well. People can lose an argument gracefully. There's no loss of face to not having one's ideas accepted or implemented - even if those ideas are rejected for what might appear to be silly reasons to you. Your apologies read as rationalizations rather than genuine apologies. You're doubling down on your behavior rather than altering it. It's coming to the point where the new community safeties are engaging because you're not altering your course.
Posted Nov 23, 2024 22:51 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (12 responses)
Sometimes the fight is worth having.
Posted Nov 23, 2024 23:30 UTC (Sat)
by geofft (subscriber, #59789)
[Link]
Posted Nov 24, 2024 3:14 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
Do you really think that those folks getting angry at each other *helped* them reach consensus?
Posted Nov 24, 2024 10:47 UTC (Sun)
by gmgod (guest, #143864)
[Link]
Yeah people are too hung up on apparences. They are denying other people's right to have opinions and feelings (especially sadness and anger), and their right to express them...
But in this case, ignoring the puritans, there is still a person that comes with grand claims and wants to change existing processes for himself while not giving the group time to acknowledge technical prowess nor intelligence. If you don't play by the rules, at least for a while, you'll have a hard time convincing anybody that they need be changed.
This comes atop of that. I cannot see it as anything other than a political move. CoCs are usually worded so subjectively that they cannot be used for anything else anyway.
I know it's frustrating to have excellent ideas and to see ways of improving things for everybody but with gatekeepers that prevent you from doing so for reasons they can't even articulate.
But at some point, everybody's human and that aspect has to be dealt with. No fights will be won if the group sees you as a disruptor, if the maintainers see you as demanding special casing and if people at large feel offended on behalf of others because of insinuations... I find it a shame that, having your wits, you've not yet understood that human dynamics, however stupid they might look, are a fact of life that you need to purposely navigate. Ignoring them won't serve you, nor your objectives, well.
Posted Nov 24, 2024 10:59 UTC (Sun)
by RX14 (subscriber, #123970)
[Link]
Posted Nov 24, 2024 20:04 UTC (Sun)
by rra (subscriber, #99804)
[Link] (3 responses)
And this is exactly the problem: you are at present unable to see how to have the fight without being abusive. No one is arguing against having the fight, only about how the fight is conducted.
I'm just some random person on the Internet who has been in a lot of technical fights (in Debian, not in kernel development, so the context is admittedly different). You don't know me and you have no reason to take my advice. But my natural tendency is the same: I want to have a blunt discussion at the same level that the other person is discussing things, and if a point is particularly important to me or if something the other person says seems particularly outrageous, I want to drive home my point with force. I invent all sorts of justifications and reasons in my mind for why this time I need to put all of my emotion in the response, because some things DESERVE that emotion, damn it.
It doesn't help. It just doesn't. As much as I try to convince myself that this time for sure it will serve a purpose, it doesn't, not really.
The emotion is a crutch. The abuse is a crutch. It is your subconscious telling you that your argument is not working. The natural human reaction is to just apply more force, but applying more force causes damage and risks breaking all the components of the system, including you.
Roughly speaking, there are four reasons why my arguments aren't working in a discussion and I become tempted to apply more force. My argument may be bad: insufficiently precise, insufficiently detailed, insufficiently supported. The topic may be a matter of subjective judgment or future prediction and the other person fully understands my argument and simply disagrees. The other person may be simply wrong and completely unwilling to see it. Or I may be simply wrong and completely unwilling to see it.
In every case, adding the abuse and emotion doesn't help and usually makes it worse. When you apply more force in the argument, not only do you inspire MORE resistance, not less, in the other person, you also harden your own position. You make it less likely that you will be capable of realizing when you're wrong because now you're emotionally invested and you would also have to admit your emotion was unjustified. If the argument is bad, no amount of additional force applied to it will make the argument better. And if the debate is over subjective judgment, you will not convince other people to substitute your judgment for theirs by being abusive, nor should you be able to.
Pounding on the keys harder doesn't make the bug go away. You have to actually find the bug and fix it, and pounding on the keys harder doesn't help and usually hurts. It's incredibly difficult to let the emotion go and instead try to calmly understand which of those cases applies and how to move forward, but that's what works. Sometimes I've gotten away with throwing a big enough tantrum that someone else stepped in and did the work for me, but that's not the person I want to be, and based on your writing I don't think that's the person you want to be either.
I will grant that there are some exceptions for social problems where what's required is, essentially, a revolution or a threatened revolution and you need emotion to get people out into the streets and threaten violence, but I don't think that's the situation in kernel development and based on your blog post I don't think you think it is either.
Posted Nov 24, 2024 23:13 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
This is well said. I've found out something similar after making this mistake several times and have learned to recognize when I feel that righteous anger "how could they be so incompetent and stupid to not see X, Y, Z" that I'm the one who needs to sit down and re-evaluate before going off because most times I've gone down the other road and chose escalation I have later found out that _I_ misunderstood something fundamental and made an ass of myself requiring an apology. I've said a lot fewer dumb things that I need to walk back since then ;-)
Posted Nov 25, 2024 12:11 UTC (Mon)
by beagnach (guest, #32987)
[Link]
Posted Dec 23, 2024 10:22 UTC (Mon)
by ras (subscriber, #33059)
[Link]
It's only worth doing when you've exchanged a few emails, so you've gone over a lot of ground but the temperature is rising. That is the time to re-read the exchange and re-imagine it from the point of view of a third party. Occasionally, you end up thinking "I'd be repeating myself and I don't want to bore these people", so I your email becomes "I have nothing more to add".
It has worked every time I've done it. Having the presence of mind to see through the red haze and apply it is not so certain.
Posted Nov 24, 2024 22:26 UTC (Sun)
by tome (subscriber, #3171)
[Link] (3 responses)
Apologies set the stage for a better future.
We apologize for offenses. An offense has a victim. The victim may very well have had it coming, but that has nothing to do with the apology. A genuine apology makes no excuses, makes no mention whatsoever of the victim's share of culpability. And it's good that it does not, because the circumstances that triggered the offense likely endure after the apology. An apology does nothing to diminish the force of inoffensive arguments made in the context of the offense. Quite the contrary, it removes a red herring.
Apologies are not easy. It takes courage to apologize. Apologizing shows courage.
An apology is disarming. It lets the victim and the offender come to their senses. It reduces strife and brings peace of mind to the apologizer.
There is no shame in apologizing, provided the apology is genuine. A genuine apology, made publicly, generates admiration for the apologizer, for honesty, sincerity, and good judgement.
It's not too late to apologize, Kent. You work hard and you argue hard. You deserve to enjoy the benefits of being a person who apologizes. You owe it to yourself to apologize.
Posted Nov 26, 2024 17:47 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
I agree with everything you say about the value of an apology. The only problem is that a real apology has to come from a genuine acknowledgment of having made a mistake. Someone who feels like they've done something wrong will want to apologize because they feel bad about what they've done and hope to make things better by admitting fault. The main reason so many apologies are bad is because they're insincere; the person making the apology refuses to admit fault and is only apologizing because they hope to placate the person they're apologizing to. Of course it fails because it's missing the main thing the person receiving the apology wants: an admission of wrongdoing.
Posted Nov 27, 2024 10:20 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (1 responses)
Plus, many “apologies” tend to be not “I'm sorry for what I did” but rather various versions of “I'm sorry you didn't like what I did” or “I'm sorry that I got caught doing what I did”.
Posted Nov 27, 2024 13:27 UTC (Wed)
by Rudd-O (guest, #61155)
[Link]
Posted Nov 25, 2024 13:48 UTC (Mon)
by nim-nim (subscriber, #34454)
[Link] (2 responses)
But most those professions rely on stored data, usually in a filesystem, and data corruption can cause those deteriorating situations sometimes years later when some corruption condition is met. That is why working on data storage is stressful, mistakes can have long delayed effects and mistakes are not restricted to risk-free professions because everyone uses general-purpose storage.
General data storage is one part of IT where you can not just reset things and forget about past bugs. That *is* stressful for anyone that cares.
Posted Nov 30, 2024 23:01 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Yes, but that stress doesn't have the *urgency* of the other examples, you can take months to figure out and discuss options before making a decision and changing the code, if things are getting heated you can afford the time to cool down and reflect before diving in again, that is a significant and substantial difference between examples such as surgeon or air traffic controller.
Posted Dec 1, 2024 17:11 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Posted Nov 23, 2024 10:36 UTC (Sat)
by dottedmag (subscriber, #18590)
[Link] (18 responses)
Posted Nov 23, 2024 15:32 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link] (17 responses)
It is not a matter of being "professional", whatever that means, it's a matter of being civil and it's perfectly fine to take action when the boundaries of civility are exceeded; no matter how thick the skin of the other person.
Posted Nov 23, 2024 16:58 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (15 responses)
Posted Nov 23, 2024 18:49 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link]
Posted Nov 23, 2024 20:33 UTC (Sat)
by tux3 (subscriber, #101245)
[Link] (13 responses)
But that other layer to the message is **very** important, to most people, and especially the other way around. Adding flame and personal attacks to something that could have just been a strong, cold disargeement over substance starts fights, when it doesn't discourage or scare people away.
You might have a point when you want to talk about deeper issues. But please also consider taking a bit more time to sleep on it, to let cooler words prevail. Even if all you care about is the code. It does end up making a difference.
Posted Nov 23, 2024 20:43 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (12 responses)
So I'm not really sure what you really expect.
Curious how it's always the person who gets frustrated who needs to "work on himself". Are we here just to be nice to each other, or is shipping working code important too?
Posted Nov 23, 2024 20:58 UTC (Sat)
by tux3 (subscriber, #101245)
[Link] (9 responses)
The unfair part is that it's much easier to call out a bright line violation than slow, continuous axe grinding.
For what it's worth, I've been a happy bcachefs user for some time now, I've peeked a little bit inside. I think I might have sent a trivial patch at some point. So I can tell the code is excellent. And I certainly can understand if you're getting a little tired of unrequited advice... Happy to stop here, if I'm bothering you. Much sympathies.
Posted Nov 23, 2024 21:01 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (8 responses)
Posted Nov 24, 2024 0:00 UTC (Sun)
by himi (subscriber, #340)
[Link] (7 responses)
Knowingly making stupid or unreasonable arguments is trolling. It can be a difficult thing to identify, particularly in the context of arcane technical debates and engineering discussions - making a convincing argument that someone you're dealing with is genuinely trolling can take a lot of work, and it's common for there to be disagreement about whether it *is* trolling or not, even after putting in that effort. But being difficult to prove conclusively doesn't stop it from being harassment - as much a form of harassment as intemperate language.
I don't know if Kent would necessarily agree with this characterisation, but my reading is that he feels he was being trolled, and by someone in a position with enough authority to nack his patches (adding significantly to the impact of the trolling). Regardless of whether his responses were within the bounds of acceptable behaviour, trolling should be treated the same as any other claim of harassment, and it seems like a large part of the problem here is that Kent feels that the trolling he's experienced is being downplayed or ignored, while his intemperate language is being emphasised and ultimately punished.
"Don't be nasty to people" is an easy thing to put in a code of conduct, and it's relatively easy to identify breaches and enforce consequences for those breaches.
"Don't troll" is also pretty easy to put in a code of conduct - in fact it's already one of the examples of unacceptable behaviour in the kernel code of conduct:
Examples of unacceptable behavior by participants include:
Whether reporting incidents to the Code of Conduct Committee would achieve anything I don't know.
Posted Nov 24, 2024 0:15 UTC (Sun)
by koverstreet (✭ supporter ✭, #4296)
[Link] (6 responses)
And, I think asking the committee for intervention even more would just turn things into a circular firing squad. Why can't we ask them to just take a slightly more nuanced approach when they do intervene?
The answers I've heard were all along the lines of "But that's work and we don't want to be bothered!". Well, yes, that does take more work than just being an authoritarian who smacks people, but it's the more community minded thing to do.
Posted Nov 24, 2024 0:50 UTC (Sun)
by tytso (subscriber, #9993)
[Link] (5 responses)
I think the mm developers' points were actually valid, and I will note that other file systems don't have a problem, or at least not as much of a problem, as bcachefs seems to have with how the mm subsystems handles thing. I've certainly had my disagreements with Michal in the past, but *I* never felt the need to resort to personal attacks, and we eventually worked out a compromise (in fact, it was over __GFP_NOFAIL)
With respect to the mm/bcacefs thread, it certainly smeed to me that both sides seemed to be talking past each other, and I could see how both sides might feel that the other was ignoring their clearly, obviously, valid points. Sometimes the answer to that is to try to hash things out over a video conference; or perhaps in person at an event like LSF/MM. Or perhaps by trying your best to restate the other party's argument in as charitable way possible, and stating where you agree, and then trying to identify the precise place where you disagree. But **never** via a personal attack.
Is that sufficiently nuanced?
Posted Nov 24, 2024 1:18 UTC (Sun)
by koverstreet (✭ supporter ✭, #4296)
[Link] (4 responses)
And you've been following me around with comments that are distinctly personal and not technical every time testing comes up, so - let's please stick to what I asked last night.
Posted Nov 25, 2024 4:55 UTC (Mon)
by zorro (subscriber, #45643)
[Link] (3 responses)
Posted Nov 25, 2024 5:49 UTC (Mon)
by koverstreet (✭ supporter ✭, #4296)
[Link] (2 responses)
They generally do an emergency shutdown of the filesystem, i.e. it's not an error that should ever happen in normal operation, but it won't take down the entire machine.
But if you kill the process, then you do take down the entire machine - because the only reason you use GFP_NOFAIL is if you're in a context where you can't unwind (without doing that emergency shutdown), and the reason you can't unwind is because you're holding locks.
So if you kill the process, those locks never get released, and the entire machine quickly grinds to a halt.
Posted Nov 25, 2024 18:38 UTC (Mon)
by mstsxfx (subscriber, #41804)
[Link] (1 responses)
Let me just reference https://lore.kernel.org/all/ZtV6OwlFRu4ZEuSG@tiehlicka/T/#u which is trying to explain the reasoning.
* %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
while some callsites might have a error path one would have to review all existing users and add error handling where it is missing.
So now there are not really many options how to deal with GFP_NOFAIL with the _current_ semantic.
Each of the model has its cons and pros. 1 and 2 would require reviewing all existing users and that is not really trivial task. Option 3 needs to be really careful about unsupportable allocation requests (e.g. non sleeping requests would require essentially a busy loop around allocator without any upper bound, or higher order request could simply put the machine down through OOM killer storm because of the memory fragmentation).
The crux of the disagreement was in how to deal with impossible. Failing a (by definition) non-failing allocation can result in security issues (silent memory corruptions as this is not guaranteed to OOPS). Killing the allocation process might leave locks behind with similar effect but the fact could be easier to observe in the kernel log (in a sense a guaranteed OOPs). Or keep retrying indefinitely and make the system unusable.
What makes this decision making really hard is wide variety of allocator users. I am not really happy about the existing gfp flags semantics we have because it is really hard to understand unless you take the deep tour into the implementation. This results in misunderstanding and wrong use of the allocator. I have seen that countless times and I am definitely not blaming authors of the incorrect code. But seeing all this I am really concerned about adding more confusion like GFP_NOFAIL that can actually fail.
I still believe that this kind of discussion is not completely insane.
Michal Hocko
Posted Nov 26, 2024 8:50 UTC (Tue)
by mchehab (subscriber, #41156)
[Link]
It sounds to me that maybe it is time to deprecate GFP_NOFAIL and replace it by other flag(s) that may have a better defined semantics.
Posted Nov 24, 2024 6:34 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
A very simple guide: just don't insult people. That's it. Calling the _ideas_ "stupid" is borderline, but is acceptable in the LKML. Calling people "stupid" is not.
Posted Nov 24, 2024 9:39 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
If direct engagement is not working, the next step is to escalate. Not escalate as in "escalate the argument," but escalate as in "appeal to a higher forum." That might be Linus, the TAB, or somebody else, I don't pretend to be an expert on Linux politics and procedure. The point is, there has to be somebody who is The Decider when discussion on LKML proves fruitless. That person is probably different depending on the scope of the disagreement (e.g. if two developers disagree about something that only affects subsystem XYZ, then the XYZ maintainer is probably The Decider for that particular disagreement, but code that touches multiple subsystems might need a Decider who is higher up the chain).
I also want to stress that escalation is a process, not an event. You don't just shoot off an angry email to the next person up the chain as soon as somebody disagrees with you. If I were going to escalate a technical issue, in my professional life, I would start by writing up a short document explaining my view and their view, where we seem to agree, where we seem to differ, and what aspects we each seem to consider more important. I would then politely ask the other person to review that document and either agree with it or recommend changes, and I would (probably) allow them to freely edit the sections which represent their views. During this process, it is entirely possible that the disagreement would be resolved, and no actual escalation would need to take place. Since I work at a big tech company, my next step would be to show the document to my manager and ask them to figure out what to do with it, but I imagine the process in a community-run system like LKML will differ. Presumably, you circulate the document publicly for a while, then when it's in good shape, you show it to whoever The Decider happens to be and ask them to make a decision.
There are a few failure modes to watch out for:
* If the other person gives a non-answer, such as just stating that my document is "wrong" or a "waste of time" without further information (or if they ghost me altogether), I would note their objection (and/or non-participation) in the document, ask them if they want to elaborate on it, and then proceed with the escalation anyway.
My big tech company has an HR department, so these failure modes are generally less of an issue for me (they don't do this "CoC" stuff in professional tech, they just tell you to cut it out or you're fired). They are included mostly for completeness.
Posted Nov 24, 2024 10:49 UTC (Sun)
by gmgod (guest, #143864)
[Link]
Posted Nov 23, 2024 11:33 UTC (Sat)
by leandro (guest, #1460)
[Link] (3 responses)
Our civilisation is dying, it would be delusional to think the free software culture would survive it, save a miracle. The next civilisation will hopefully learn from our foibles, but that would be a miracle too.
Posted Nov 23, 2024 22:05 UTC (Sat)
by dvdeug (guest, #10998)
[Link]
If we want the best kernel at the end of the day, you've got to take care of your contributors, and get new contributors to replace the ones that inevitably die or quit. Just saying "meritocratic" doesn't deal with the problem that some very skilled people don't enjoy arguments and won't get involved in a project with a lot of them. It doesn't do anything with the problem that he who yells the loudest and longest is not necessarily the most correct.
Posted Nov 24, 2024 3:23 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
Posted Nov 25, 2024 16:29 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Note that early definitions of the term "meritocracy" were in a dystopian context, describing how you could pervert a system intended to appoint the best people to the jobs into one where you appoint the politically well-connected.
Posted Nov 23, 2024 15:01 UTC (Sat)
by rbranco (subscriber, #129813)
[Link] (21 responses)
Refusing pull requests is nuts. What if the code contains a security fix? Paying a fine would be better. A win-win.
Enough with first world problems!
Posted Nov 23, 2024 15:13 UTC (Sat)
by corbet (editor, #1)
[Link] (5 responses)
Posted Nov 23, 2024 15:18 UTC (Sat)
by rbranco (subscriber, #129813)
[Link] (4 responses)
Posted Nov 23, 2024 16:15 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (1 responses)
That's an absurd distinction, the software projects aren't run by robots, they are run by human people and forks are created when people can't compromise and collaborate successfully on a shared vision. When people value different things that is a political disagreement not a technical one, miscatagorizing these things is going to lead to future misunderstanding of the fundamental nature of conflicts when collaboration breaks down.
Posted Nov 23, 2024 16:26 UTC (Sat)
by rbranco (subscriber, #129813)
[Link]
When everything is political, nothing is. The core differences were 100% technical and the forks were a win-win for everyone... Linux has multiple distributions for mostly technical reasons, but now we seem to afford to fork over petty politics.
Posted Nov 23, 2024 17:01 UTC (Sat)
by marcusb (guest, #16598)
[Link] (1 responses)
At least in the case of OpenBSD forking from NetBSD, that doesn't jive with history as I remember it.
See http://mail-index.netbsd.org/netbsd-users/1994/12/23/0000.html and https://www.theos.com/deraadt/coremail.html.
Posted Nov 23, 2024 18:19 UTC (Sat)
by malmedal (subscriber, #56172)
[Link]
I think a major difference is that with Linux nobody questions that Linus Torvalds made the thing, while with the BSDs there were several people who felt that they were the true inheritor of the BSD tradition.
Posted Nov 23, 2024 15:32 UTC (Sat)
by tuna (guest, #44480)
[Link] (14 responses)
Posted Nov 23, 2024 16:47 UTC (Sat)
by rbranco (subscriber, #129813)
[Link] (13 responses)
Is being pulled by Linus a privilege? That is also a very warped view.
Not being allowed to contribute for X amount of time is just crazy. But I guess this is the new normal these days and nothing surprises me anymore.
Posted Nov 23, 2024 21:30 UTC (Sat)
by ballombe (subscriber, #9523)
[Link] (9 responses)
Linus himself is not under sanction, so the TAB has no basis to force him to do or not anything.
The TAB is just pretending to have authority it does not have.
Posted Nov 24, 2024 11:22 UTC (Sun)
by Sesse (subscriber, #53779)
[Link] (4 responses)
Posted Nov 24, 2024 14:13 UTC (Sun)
by ballombe (subscriber, #9523)
[Link] (3 responses)
Posted Nov 24, 2024 19:16 UTC (Sun)
by kleptog (subscriber, #1183)
[Link] (2 responses)
That is very common in separation of powers situations. One party (the TAB) formulates a decision, and another party (Linus) is tasked with enforcing it. Linus could in theory refuse to implement, but that would trigger an immediate constitutional crisis. The question is if that's worth it.
Whichever way you look at it, the TAB is the one that renders the decision.
Similar to how in a constitutional monarchy the monarch has in theory the ability to ignore the will of parliament. In practice if they ever did that the resulting constitutional crisis would destroy one or both institutions.
Posted Nov 27, 2024 13:30 UTC (Wed)
by Rudd-O (guest, #61155)
[Link] (1 responses)
Yes, exactly. If the police refuse to abide by the judge's order, then the judge's order is irrelevant for all intents and purposes connected to reality.
"He has made his law. Let him enforce it."
Posted Nov 28, 2024 14:29 UTC (Thu)
by foom (subscriber, #14868)
[Link]
But in practice judges' rulings DO get enforced, and so do the TAB rulings (at least this time).
Posted Nov 24, 2024 22:17 UTC (Sun)
by ianmcc (subscriber, #88379)
[Link] (3 responses)
Posted Nov 25, 2024 0:15 UTC (Mon)
by sashal (✭ supporter ✭, #81842)
[Link] (2 responses)
It would make sense that Linus will choose to respect the TAB's judgment and opinion around community issues such as this, right? This is why the TAB is around to begin with. There's no crazy LF board of directors thing playing out behind the scenes, this is just a group of folks (Linus included) doing what they thing is best for the future of the community.
No one wants to be dealing with this, this is not why folks signed up to do kernel work, and ideally this is the last time that there is a CoC related action in kernel-land.
Posted Nov 25, 2024 11:02 UTC (Mon)
by ianmcc (subscriber, #88379)
[Link] (1 responses)
But in a hypothetical, if Linus had refused that decision, or subsequently chooses to accept code from Kent, then it puts the TAB and the LF Board in a very difficult position. That would ultimately the Board's decision to resolve, and it could go in a variety of ways, eg, the Board might overrule the TAB or terminate the TAB completely, or they might part ways with Linus.
https://wiki.linuxfoundation.org/tab/start
Posted Nov 25, 2024 17:05 UTC (Mon)
by sashal (✭ supporter ✭, #81842)
[Link]
I wouldn't say that the relationship between the parties you've mentioned are as strenuous as you might think.
Again, this is an example of everyone working together to agree on a course of action and implementing it. No one was forced into anything. This is purely for the benefit of the community.
Posted Nov 24, 2024 14:54 UTC (Sun)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
I always thought it very much is? You generally are asking someone to do something for you which you don't have a right to demand.
You really are not entitled for me to pull your code into my tree, or for Linus to pull Kent's code.
Posted Nov 26, 2024 7:44 UTC (Tue)
by ianmcc (subscriber, #88379)
[Link]
> > Is being pulled by Linus a privilege?
Is absolutely hilarious.
Posted Nov 24, 2024 16:34 UTC (Sun)
by tuna (guest, #44480)
[Link]
The only thing that has changed is that Linus T will not do a pull of Kent O's tree for this release cycle of Linux.
Posted Nov 23, 2024 21:53 UTC (Sat)
by sheepdestroyer (guest, #54968)
[Link]
But It would surely suffice to prevent a *demand* for a public apology ; or at least not before the insulted party having issued an apology for being wrong and uncooperative in the first place.
A blame only for not being nice/polite/SFW enough during a technical argument, regardless of who was technically right, is putting form over substance.
Posted Nov 24, 2024 1:37 UTC (Sun)
by cypherpunks2 (guest, #152408)
[Link] (35 responses)
Posted Nov 24, 2024 12:46 UTC (Sun)
by cytochrome (subscriber, #58718)
[Link] (26 responses)
Posted Nov 24, 2024 14:10 UTC (Sun)
by cypherpunks2 (guest, #152408)
[Link]
The harm caused by forced apologies is harm to all individuals involved, not just the person who will receive a bruised ego. An inauthentic apology is absolutely a disservice to the person on the receiving end. I was coming at this from the perspective of a recipient. Healing comes from mutual understanding, not from retribution against your interlocutor via public humiliation. It just so happens that a forced apology is an easy way to give the outward appearance of mutual understanding without actually achieving it, and to those not emotionally invested in the situation, the mien of understanding is just as good as the real thing.
Apologies should come from the heart, and to say so does not diminish the harm caused by callous behavior nor justify insulting others.
Posted Nov 26, 2024 8:29 UTC (Tue)
by ssmith32 (subscriber, #72404)
[Link] (22 responses)
However, it may help the person who did the insulting if they can be nudged to summon the willpower to put their pride aside in order for everyone to get back to insulting each other's specific ideas, instead of insulting the organ with which they create their ideas.
In short, this all seems to be taking place with actions and processes that assume everyone is operating at the emotional maturity level of a cloistered adolescent.
If a grown person can't stop from calling someone they work with an idiot in the middle of a debate about error handling, they lack the impulse control I would expect of an adult.
Conversely, if you're deeply hurt by someone you work with calling you an idiot, and consider yourself a "victim", I also would consider you emotionally immature. And you probably shouldn't take mass transit... or drive.. or ride a bike. All of which could result in people who are clueless calling you an idiot (e.g. I've been told to "get the f** off the road" and had cars swerve at me for being in a left turn lane on a bike... in areas where it would not only be illegal, but unsafe to pedestrians for me to be otherwise). So I ride on, leaving them to stew in traffic and ignorance.
If you sideline the person due to their poor impulse control and move on, that's fine. But you shouldn't be deeply hurt or regard yourself as a "victim".
I do wonder if all these people who talk how rough and tumble the world of kernel development is, and needs to be, has ever sat down with an MMA fighter, let alone boxed their friends. One of the calmest dudes I knew was an MMA instructor - who had no trouble apologizing and never called anyone an idiot in anger. But nor did he get particularly offended by insults. He certainly had no desire to fight someone over juvenile name-calling, whether physically or otherwise. Unless he was getting paid to ;)
Posted Nov 26, 2024 9:10 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
Apologies for mentioning it again, but there is also the little problem of cultural clash. I could never get involved in a - fact based - discussion of race on Groklaw, because what was acceptable English for me was unacceptable for GL's American, but what was acceptable to them was totally unacceptable for me. What do you do? An apology from me for offending them is meaningless, but they're not going to apologise for excluding me from the conversation.
Or I had a conversation with a co-worker (many moons ago). I got very stressed and agitated, and their manager complained to my manager about my "threatening behaviour". When I mentioned this to my co-worker she was shocked - she hadn't felt at all threatened (nor should she - it was obvious my stress-symptoms weren't aimed in her direction at all).
The only time an apology is going to work is when the apology-giver understands WHY an apology is necessary. I've learnt that - I use apologies to build trust. But if I'm going to "I'm sorry you're offended over nothing", I'm going to be extremely pissed off if I'm strong-armed into it. But if I realise the recipient is a shrinking violet - well it plays into my hands.
Cheers,
Posted Dec 14, 2024 21:06 UTC (Sat)
by jospoortvliet (guest, #33164)
[Link] (1 responses)
I think this is also a factor in the kernel community, as it is in any work space. People learn good behavior from each other - and if you misbehave, saying sorry in public shows others that 1. everybody makes mistakes and 2. just say sorry and we can all move on. That's a good, healthy way of working together. Conversely, being a stubborn d*** and getting away with it shows people that bullying gets you what you want. Don't be surprised if the result is a ton of bullying.
I'm not saying this is the only factor, just that it is one to consider. I do apologise sometimes for things I genuinely feel I didn't really do - to show a good example to others. What's the worst that can happen? I'm an adult and can (usually) handle a bruised ego; and being the bigger person never hurts.
Posted Dec 14, 2024 22:48 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Exactly - and that builds trust!
Two further examples, and I very much get the impression some people in the kernel community might benefit from learning this ... bear in mind I'm borderline autistic.
And in both cases, the other party was a woman. Like many women, they naturally feel intimidated in the presence of a man - especially someone slightly "bull in a china shop" like me. But fortunately, they both felt able to tell me they felt I was talking down to them. I was shocked (I shouldn't have been). Cue a bit of trust building - apologise for making them feel this way (no blame! Whether I intended it or not, that was the consequences of my actions, I don't need to feel guilty, what's wrong with a *genuine* "I'm sorry I made you feel that way"?).
Then a little bit of psychology - if I treat you as an equal, I will feel you are treating me the same even if you aren't. If you feel inferior, you will feel that way even if I don't feel I'm treating you that way. But those two conversations were brilliant for me. And as far as I can tell for them too. They now know they can push back at me, and I'll respect them for it. They know my words are advice not orders. I've learnt to say my piece and *step* *back* (I think one of my - female of course - workers keeps doing daft things, but I advise and walk away, she needs to find out from OTHER people that I'm right :-) it'll harm ME if I push matters.
I still mess up, of course, but the result is a good working relationship. They know I'll say my piece - they know they can say their piece! (and they do) - but importantly they know that - at the end of the day - I *won't* interfere. They know I want them to get it right, but they know I want them to get it right THEIR way (and I know if they do it MY way, it's going to be a mess, anyway! :-)
Cheers,
Posted Nov 27, 2024 0:52 UTC (Wed)
by interalia (subscriber, #26615)
[Link] (8 responses)
I feel you're reading too much into the word "victim", I look at it as being casually factual. If someone steals from me, I'm a victim of theft; if someone punches me, I'm a victim of assault. This isn't some deep assertion of victimhood on my part, but something I think you'd agree is trivially true. If someone yells an insult at me then I'm a victim of verbal abuse, in the literal sense of the sentence "Person A verbally abused person B".
It's just factual that misconduct of the above kinds has a perpetrator and a victim (and sometimes bystanders/witnesses), and I was the victim. If the misconduct was a personal insult that doesn't mean I am saying I was deeply hurt or traumatised by it, but I'm also not going to deny it. Misconduct happens with widely varying severity and trauma but at low trauma levels there isn't suddenly a lack of a victim, and I don't feel people should decline to use the word.
Posted Nov 27, 2024 13:17 UTC (Wed)
by nye (subscriber, #51576)
[Link] (7 responses)
I disagree with this really quite strongly.
Pushing somebody to breaking point so you can get the satisfaction of watching them lose their cool does not in any sensible definition make you a victim. I don't think *this* instance was actually deliberate trolling, but it *very frequently* is.
Posted Nov 27, 2024 14:03 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
PLEASE don't confuse victim with perpetrator. READ WHAT THE GP WROTE.
Cheers,
Posted Nov 28, 2024 10:11 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
The only value you provide at all is that people can now pay to mute you - maybe this has caused an increase in subscriber counts? Please consider this the next time you try yelling at somebody because you don't understand them and are too narcissistic to consider that perhaps the misunderstanding is yours.
(I rewrote this post four times and this is the most polite I could manage. You don't want to know what was in the first draft.)
Posted Nov 28, 2024 15:22 UTC (Thu)
by sdalley (subscriber, #18550)
[Link]
Posted Nov 27, 2024 16:42 UTC (Wed)
by interalia (subscriber, #26615)
[Link] (3 responses)
None of that was said in my comment or implied, as far as I can tell.
But consider that saying "victim of assault" does not have to imply "was morally right", and that victims and perpetrators are not an exclusive-or situation... nothing stops people from being victims sometimes but perpetrators at other times or even at the same time e.g. two people in a fistfight might well be both the victim of assault and also a perpetrator of it.
Posted Nov 28, 2024 10:23 UTC (Thu)
by nye (subscriber, #51576)
[Link] (2 responses)
That's what I took from "If someone yells an insult at me then I'm a victim of verbal abuse" as an absolute statement.
I don't agree that yelling an insult is necessarily abuse, and I don't agree that the word "victim" can be used to describe this without stretching it so far that it has no meaning any more.
> saying "victim of assault" does not have to imply "was morally right"
Sure, but it does strongly and unavoidably imply that the person doing it was morally wrong.
It sounds like you mean the word to be essentially equivalent to "recipient", but if that's really what you want it to mean, would you say that I'm a victim of my Amazon delivery? I think most people would not.
(This isn't just a semantic aside BTW, but something that I think is on topic - I feel like I'm perhaps the only person in this thread who sees Kent's mail as the rash but understandable impulse of somebody pushed past breaking point, even if that wasn't the intent.)
Posted Nov 28, 2024 15:06 UTC (Thu)
by interalia (subscriber, #26615)
[Link]
In my original comment I was using myself in an abstract hypothetical where someone yelled an insult at me, so to me it seemed rather odd that suddenly the reason for the insult in my hypothetical was because I had pushed someone else to breaking point so I could get them to lose their cool.
I wrote some text replying to the rest of it but deleted it, I get some of your point but don't care enough to hash that out further so will leave it there. Thanks for the discussion.
Posted Dec 3, 2024 5:18 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link]
So now we're going to run LKML on the theory of "two wrongs make a right?"
You cannot abuse people, even if they purportedly "deserve" it. If someone is misbehaving, then you either ignore it or escalate it to the CoC people (which may entail drafting a policy to actually prohibit the conduct in the first place, but that's a detail). You are not entitled to simply assume that someone is engaging in bad faith and assign a punishment of verbal abuse on the spot.
Posted Nov 27, 2024 1:40 UTC (Wed)
by pizza (subscriber, #46)
[Link] (9 responses)
The point of forcing apologies is an overt demonstration of *power*, nothing more.
Posted Nov 27, 2024 2:17 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (8 responses)
But unless a committee charged with enforcing a code of conduct can demonstrate power, it's completely useless.
Posted Nov 27, 2024 4:35 UTC (Wed)
by pizza (subscriber, #46)
[Link] (7 responses)
Yet counter-intuitively, every time they exercise said power they actually weaken it.
...The only power they have is to exclude folks from "their" sandbox, but the harsh reality is that the overwhelming majority of the folks working on Linux are doing so in non-mainline vendor-controlled sandboxes.
Posted Nov 27, 2024 17:54 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (6 responses)
> Yet counter-intuitively, every time they exercise said power they actually weaken it.
How so? I'm not following. Given what happened, do you think the action of the committee will make it more likely, less likely or about the same that someone else will make a public personal attack against someone? I think it will make it less likely, in which case the action had its intended effect.
Posted Nov 27, 2024 19:55 UTC (Wed)
by pizza (subscriber, #46)
[Link] (5 responses)
The only power they have is that of exclusion.. but it's purely performative act by a paper tiger. They can't actually "fire" anyone; they can't prevent anyone from working on Linux, or anyone else from using said work or otherwise collaborating with them.
After all, these excluded folks have countless other places to accomplish their (still continuing) work, and downstream distributors of Linux overwhelmingly routinely apply non-mainline patchsets.
Another question with complicated ramifications -- what's going to happen when there's high priority CVE but the maintainer behind the subsystem/etc in question is still in timeout? Does someone else have to submit the work of the excluded person for a fix to land?
If you're going to suspend or otherwise kick people out of your sandbox, you'd better have a plan to replace them. After all, ripping out entire drivers/subsystems will be a blatant, fragrant "breaking userspace". Is that really a "better for the community" outcome?
> Do you think the action of the committee will make it more likely, less likely or about the same that someone else will make a public personal attack against someone
I think all of this is just performative BS. When nearly everyone out there is already running a non-mainline fork, all this will demonstrate is how little power you actually have.
Posted Nov 27, 2024 22:31 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (4 responses)
The only power they have is that of exclusion.. but it's purely performative act by a paper tiger
Actually, no. People hate being excluded. It is actually a serious punishment; this is hard-coded into our DNA from our days of surviving in small groups in a hostile prehistoric environment. It's why banishment has been a serious punishment for thousands of years across many different cultures.
I think all of this is just performative BS. When nearly everyone out there is already running a non-mainline fork, all this will demonstrate is how little power you actually have. So you didn't answer my question, but I'm assuming you think it won't make any difference. I disagree. There's a lot more cachet to having your code in the mainline kernel rather than a fork, and I think the action will make people think twice before embarking on public personal attacks.
Posted Nov 28, 2024 1:06 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
Are you seriously saying that being "Excluded from working on the mainline by the linux foundation" matters one iota when (1) your salary isn't being paid by said linux foundation, and (2) your actual employer is overwhelmingly likely to be shipping their own non-mainline fork?
Seriously.
Posted Nov 28, 2024 1:58 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Nov 28, 2024 14:09 UTC (Thu)
by dskoll (subscriber, #1630)
[Link]
Are you seriously saying that being "Excluded from working on the mainline by the linux foundation" matters one iota when (1) your salary isn't being paid by said linux foundation, and (2) your actual employer is overwhelmingly likely to be shipping their own non-mainline fork? Yes, that's exactly what I'm saying. It might not matter financially in the short-term, but it does impact your career (public meltdowns are never good when you are job-seeking) and it matters personally. Additionally, any employer shipping its own kernel would be much happier if the employee was not excluded from working on the mainline; this greatly simplifies maintenance of any fork.
If it really "didn't matter one iota", then this thread would have two comments on it instead of dozens/hundreds.
Posted Nov 28, 2024 3:06 UTC (Thu)
by intelfx (subscriber, #130118)
[Link]
I wish it would. But that’s not going to happen as long as these actions are only carried out against the boogeymen du jour, while Real Kernel Maintainers™ (starting with Linus) continue to insult their peers (see the sister thread about comm[]) at every opportunity and do so with absolute impunity. Rules for thee and not for me.
Posted Nov 27, 2024 13:33 UTC (Wed)
by Rudd-O (guest, #61155)
[Link] (1 responses)
The victim can decide whether a public apology is needed. It's categorically not the purview of the committee to decide for the victim. If the victim has not requested such a thing, then it's transparently evident that the committee only demands that for humiliation / flaunting power purposes.
Posted Dec 20, 2024 18:34 UTC (Fri)
by tbird20d (subscriber, #1901)
[Link]
I strenuously disagree. Victims are often in the least favorable position to request an apology. They may not even recognize the value
> If the victim has not requested such a thing, then it's transparently evident that the committee only demands that for humiliation / flaunting power purposes.
Posted Nov 24, 2024 15:26 UTC (Sun)
by mattdm (subscriber, #18)
[Link] (7 responses)
The goals should be: ongoing community health, restitution and repair for the victim if necessary and possible, and a sincere change in future behavior. A genuine apology is a good step towards all of those, but it needs to come from self-reflection, recognition of common community purpose, understanding that apology alone isn't sufficient — and acceptance that this goes two ways: even a total, heartfelt apology doesn't get forced forgiveness.
Otherwise, you just have playground situation where parents make a bully stand and mumble "sorry" and the victim say "I forgive you" — and the same thing the next day, and the next.
Posted Nov 25, 2024 0:19 UTC (Mon)
by sashal (✭ supporter ✭, #81842)
[Link] (6 responses)
I don't think that the offended party necessarily has to accept the apology, and I can see cases where the offended party may choose not to interact with an individual anymore.
The apology is mostly for the benefit of the community.
Posted Nov 25, 2024 7:04 UTC (Mon)
by tytso (subscriber, #9993)
[Link] (5 responses)
[1] https://www.health.harvard.edu/blog/the-art-of-a-heartfel...
If one follows the four key steps of a real apology as described in [1]
* Acknowledge the offense
... it can't help but affect the writers' thinking. It's a lot more than just saying, "Sorry! I'm forced to say it. Satisfied?"
Also of note from [2]:
McCarthy adds that a bad apology can even make things worse.
"It's akin to the cover-up being worse than a crime, if you make an
So an apology which is buried in a long message explaining how the victim was wrong and unreasonable in many different ways, is not really a real apology, or is at best a really a bad apology.
Posted Nov 25, 2024 8:51 UTC (Mon)
by cypherpunks2 (guest, #152408)
[Link] (4 responses)
Posted Nov 25, 2024 13:57 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
Step up, take a measured look at what went wrong (and DON'T assume you're in the right - you could both be, or you could both be in the wrong ...).
Then ask yourself "how do I offer an olive branch?". Looking for an olive branch benefits YOU, and if the other guy won't accept it, more fool them. Fault is rarely one-sided, it's easy to find something to proffer, and when it's not expected it places you firmly on the moral high ground IN OTHER PEOPLES' EYES.
Cheers,
Posted Nov 25, 2024 14:10 UTC (Mon)
by pizza (subscriber, #46)
[Link]
More fool them, but you're still the one that gets punished.
Posted Nov 25, 2024 17:11 UTC (Mon)
by sashal (✭ supporter ✭, #81842)
[Link] (1 responses)
The point in asking for an apology is really an attempt at clarifying that a certain behavior in unacceptable in our community, and the apology part is acceptance and understanding of these terms.
Is it even better if the apology is real and true? Sure!
Posted Nov 25, 2024 18:16 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
Posted Nov 25, 2024 8:55 UTC (Mon)
by jd (guest, #26381)
[Link]
I don't see that the code of conduct committee had any good options and I suspect that they did what they believed would do the most good with least harm - but it's never possible to be sure if that's how it will play out.
Posted Nov 25, 2024 12:44 UTC (Mon)
by snajpa (subscriber, #73467)
[Link] (13 responses)
And no, that Facebook uses it isn't an argument. With their army of developers, they could be using whatever, straight from git master, no need to care about anything because they'll just fix the problems they encounter. What they don't encounter they obviously don't fix but hey Facebook uses it, it's a good filesystem!
Whatever. Community built on allowed toxicity is dispelling a rather newcomer for trying to use that toxicity to improve the community. Best of luck.
Posted Nov 25, 2024 12:52 UTC (Mon)
by pizza (subscriber, #46)
[Link]
"improvements" in the eyes of the beholder, that is.
'how can anyone govern a country with 246 varieties of cheese? ' -- Charles de Gaulle
Posted Nov 25, 2024 14:53 UTC (Mon)
by jd (guest, #26381)
[Link]
Those old enough will remember that this is precisely why PGCC failed utterly against EGCS and why the original branch of GCC failed against both of them.
In the end, you design for the community at large or into a brick wall.
I'm not going to get into the whole good/bad thing, but it seems obvious that the corps have lost sight of why contributing to Linux was useful.
Posted Nov 26, 2024 15:06 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Posted Nov 27, 2024 13:34 UTC (Wed)
by Rudd-O (guest, #61155)
[Link] (1 responses)
We CAN have nice things.
Posted Nov 28, 2024 3:53 UTC (Thu)
by cypherpunks2 (guest, #152408)
[Link]
Posted Nov 27, 2024 20:26 UTC (Wed)
by tuna (guest, #44480)
[Link] (7 responses)
Posted Nov 27, 2024 22:19 UTC (Wed)
by snajpa (subscriber, #73467)
[Link] (6 responses)
some of them do stuff like consider CDDL compatible with GPL (I mean, sue me if that's how you wish to be remembered)... some of them replace the need for ugly lxcfs... some of them make containers feel more like what containers should be
I'm pretty happy with it :) no arguments, no bikeshedding needed to get to a point where I'm pretty happy with our deployment... as for your attempt to demonstrate why I won't engage, if you enjoy such fallacies as when I have stuff to criticize, your first impulse is to tell me to go away... well, thank you for that demonstration
Posted Nov 28, 2024 10:40 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (5 responses)
So long as you're the end user, who's going to sue? Who will have standing? Who will even have a case!
If you're the end user, the GPL is irrelevant to you (unless you were involved in illegalities whilst acquiring the program). I guess the same is true of CDDL.
So yep. Some random Joe could sue you. They could sue you for anything. Doesn't mean they have a case.
Cheers,
Posted Nov 28, 2024 11:08 UTC (Thu)
by snajpa (subscriber, #73467)
[Link] (4 responses)
We do redistribute tho, you can download the iso and give it a try - https://vpsadminos.org - and it's all on GitHub.
Most of the arguments that still make the circles whenever ZFS pops up are just... FUD. It all starts with the rumor that supposedly engineers at Sun wanted a licence that is incompatible with GPL, well... people just took that as the base truth and it's done forever, when in fact... a source of that claim is a person who was supposed to be close to the process, but the guy who was her boss at the time says the exact opposite, the engineers wanted something BSD like and so the CDDL is a result of a corporate process, while the supposed GPL incompatibility was never a goal.
It was never tried in court, same as the EXPORT_SYMBOL_GPL and this "it combines in memory so it is a derivative work" stuff. My impulse whenever this comes up would be to fork Linux, publish it under a different name, with all this nerds-be-playing-lawyers-or-otherwise-gatekeep-because-NIH stuff gone. When I see how they treated Kent, that impulse is higher than ever. And AFAIK I would still be within my rights to do that, without creating any limitations on anyone's other's rights.
This nerd says that in OpenZFS case, CDDL is effectively practically compatible with GPL, because in spirit they truly are and that's the only thing that matters in the end, NIH or not.
Posted Nov 28, 2024 11:23 UTC (Thu)
by snajpa (subscriber, #73467)
[Link]
Posted Nov 29, 2024 14:01 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
Former Sun engineer here. I was not senior enough to be one of the engineers in the licence discussions for what became OpenSolaris, but the senior engineer in my group was. And he who told me that Sun management had wanted the GPL, but a number of very prominent Solaris engineers said "hell no". A similar account has been related by, IIRC, one or both of Simon Phipps and Danese Cooper (I forgot which). That account further describes that a group of said prominent senior engineers had threatened to quit Sun if management proceeded with the GPL.
So, this is something that has been described by multiple different people here on LWN - at least 1 of whom was in those meetings.
The one bit that is misdescribed there is that Sun wanted a licence "incompatible with the GPL". That part is not - TTBOMK - correct. At least, that was not a deliberate initial goal TTBOMK. For Sun management wanted the GPL itself, AIUI. However, various senior Sun engineers had a strong dislike of the GPL - most of them came from the BSD world. They did not want the GPL at all. They actually wanted Solaris to be placed under the BSD licence! (Is how my senior colleague told it to me anyway). A permissive licence was never going to fly for management.
So the constraints were (here I mix in /my summarisements/ with the facts I know of above):
- Management wanted to go open-source, as did engineering.
I don't know if anyone spotted the compatibility issues. There was extensive consultation about the CDDL within Sun prior to the decision. We were all - within the Solaris engineering group - given the opportunity to review it and give comments internally. I remember looking at it, I don't remember thinking about compatibility or seeing the issue, unfortunately. Surely someone had thought about it, one way or another though.
I think - with hindsight, applying my own speculative analysis - the decision to go with the CDDL, and in particular to *not* use the CDDL, is all about senior Sun engineers wanting to rescue their baby, Solaris. They could see the Sun setting, and that it could well go down. They wanted to extract their beloved software, Solaris, which they had spent years and years on, from the setting Sun before it was too late. To be able to take Solaris and keep working on it, and start new businesses around it, after Sun was gone. And I think a key thing for them to achieve that rescue was they either wanted unfettered access to the code (i.e. BSD) OR failing that they wanted to ensure it would be distinct from Linux.
That's just my subjective analysis. Cause it's the only thing that can make some sense of what happened. Going with a GPL-incompatible licence made no sense for Sun Microsystems, Inc. as a business. All it achieved was bad press and bad blood - despite Sun management being favourable towards the GPL. Sun released nearly all of Java under the GPL in '07. So clearly there wasn't an issue with upper-level management with the GPL. Yet Solaris went with the CDDL. It made no sense at all, except in the context that a bunch of high-profile Sun engineers just hated the GPL.
Posted Nov 29, 2024 14:12 UTC (Fri)
by paulj (subscriber, #341)
[Link]
> Sun wanted a licence that is incompatible with GPL
At least, if you read "Sun management" for Sun. That said, based on what I wrote you /could/ argue there /may/ have been some subset of Sun (likely in Solaris engineering) who wanted that. However, I have _no_ direct evidence for that - I have not read any account of this. All I know is that a group of leading Solaris engineers vehemently opposed GPLing Solaris - I have read that account from either Phipps or Cooped (an account reported on on LWN) and I heard the exact same thing well before they had put that online straight from the mouth of someone who was there.
Posted Dec 3, 2024 5:39 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link]
At least under US law, the only plausible reason for this *not* being allowed would be one or both of 17 USC 1201 ("Circumvention of copyright protection systems") and 1202 ("Integrity of copyright management information"). GPL version 3 expressly waives 1201 (and equivalents in other countries), but version 2 predates the whole concept by several years, so it does not have such a waiver. You can probably still argue that GPL version 2 either implicitly waives that law, or at least that it gives rise to equitable defenses against a supposed violation.
As for 1202, it is probably waived by the modification rights given in both versions of the GPL, but I'm not sure how specific that waiver needs to be in order to be effective. If doing this professionally, it might be wise to consult a lawyer.
Posted Dec 1, 2024 18:26 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (1 responses)
I have a very shallow understanding of the technical debate but I found it very interesting that it is about... error paths: always the least designed area with the worst implementations and least test coverage. I only skimmed the discussion yet I was impressed by the numbers of "what ifs". The best antidote to "what ifs" is test code: either the test passes or not; no hypothetical. Sometimes the test is wrong? Fine: fix it first and then resubmit your change. But thoroughly testing error paths tends to be very hard hence seldom done. Add a bit of concurrency on top and testing becomes even harder.
Obviously, this is all happening in C: one of those ancient languages that gives the developer absolutely zero tool or any sort of help to handle errors.
From https://www.patreon.com/posts/116412665
Again, these "theoretical breakages" and "silent data corruptions" become much less drama when reproducing them is as easy as pushing some test buttons. If the test is correct and fails then the change gets immediately reverted with a warning not to forget to run the whole test suite next time. Test suites don't have difficult personalities or bruised egos.
Unfortunately, you too rarely become a rock star or get a promotion by writing difficult test code. Not even by writing production code easier to test for that matter.
Posted Dec 1, 2024 18:35 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Forgot to say: at least now you may be able to make some money by finding vulnerabilities in untested error paths. That's some form of progress I guess.
A note
A note
A note
A note
A note
A note
A note
A note
A note
A note
A note
A note
A note
> Whether other people are okay with you doing it to them is up to *them*. Not you.
one question
one question
one question
one question
A note
- I didn't contact anyone to enforce the Code of Conduct in this case. I'm mentioning this because of some private accusations I've received about using the Code of Conduct to exert power.
- I'm fine with robust technical discussions and don't mind strong language directed at me. My cultural background is much closer to a direct and a potentially strong sounding wording than what would be considered much more politically correct by others. Personal attacks are neither productive nor they should be acceptable though. Any discussion stops there for me.
- Sometimes there's no single right solution, and the most clever one isn't always the best way forward. Differences of opinion between reviewers/maintainers and patch submitters are expected. Therefore different POV between reviewers/maintainers and patch submitters is normal and we should be able to sort those during a factual discussion. Our process puts more burden on submitter to defend their approach. That might sounds unfair but this is a generally recognized process by the community. On the other hand maintainers should be always fair, respectful and open to arguments.
- My response to Kent's public call out about feedback process is here https://lore.kernel.org/all/Zz7yqeI0RatH4ao5@tiehlicka/T/#u. I have tried to reference main entry points to discussions and I am open to hear specific feedback where my acting as a maintainer/reviewer could have been better or where it was unacceptable as Kent has concluded.
- I was in private discussions with Kent prior publishing his Patreon post. I have tried to clarify my thinking process in discussions that he has pointed out in his blog post. I felt like this could help to narrow down the disconnect. I also had some disagreement in the description of those discussions and asked him to put direct references to those discussions so that curious readers could follow them without an additional burden of digging those up from archives.
- The Code of Conduct committee contacted me last week for my opinion. I am not going to partially quote from that discussion but TL;DR summary would be that I do not insist on public apology nor I am a great proponent of enforced actions against individuals. I would much rather appreciate a private moderation while the discussion is tense and evolving in an unproductive way than punishment after the fact.
- I do not want to judge CoC cmte decision in this case, though, because I was not part of private discussions. It is really hard to make an opinion without having the full context IMHO.
A note
A note
About productivity
Why only here ...
that words (only in private ... yes - but never in public), it is not extraordinary for LKML.
them from the maintainers file - without any personal communication - was not officially
dealt with by CoC - from my point of view this would be obligatory!
This was much more severe - especially if it is true that some of them were not include
in any list (which was reported by some news).
gouvenment is also not justifyable in an international environment - except they could change
those things or had been involved personally. I understand bad blood - but not such an abuse!
sent on exiting the kernel community - and CoC did ... nothing.
Sorry, but this is really bad - and will harm the kernel community.
did that happen before? Why now - after so many much worse stories went viral.
that a line is drawn and explained to really do justice - and help in improving the tone
to have more professional diskussions on LKML.
So from my perspective this was just a bad show ...
entering in a hurry without -rc? - and bcachefs being experimental can not be worked
on when real user problems emerged and can only fixed by rewriting passages.
Code touching other regions should be limited to the merge window - of cause.
But I would understand big code changes if to help users of that FS.
comparison with much severe problems seen on videos etc. - and other things
were not even brought to light.
And if one can bring this to perspective so CoC is not a bad show but helping
better understanding each other ... an being a more healthy community - this piece
is totally missing from my perspective.
before these are first used!
It is hard to get real information about the line which should be respected.
And thus it smells very fishy ... and I could cite a lot of other examples where CoC should
have interfered ... but nothing happened.
Why only here ...
Why only here ...
As far as I know some kernel hackers were excluded because they were employed by firms under international sanctions. The nationality of the hackers are irrelevant. They can be Russian or Japanese or Norwegian, it doesn't matter. What matters is the fact that they were employed by a firm under international sanctions.
And Russian hackers working for firms NOT under sanctions were NOT excluded.
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
them from the maintainers file - without any personal communication
Why only here ...
Why only here ...
Why only here ...
Why only here ...
Why only here ...
comparison with much severe problems seen on videos etc. - and other things
were not even brought to light.
[2]: https://lwn.net/Articles/995186/
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Excessive action
Right now, when things on the list get heated, it often ends up as a dogpile - and then if it gets to that point the CoC just picks whoever mouthed off the worst and slaps them.
Okay… have you considered, I don’t know, not being the one mouthing off the worst?
You’re going to kill your own project, and none of it’s technical merits will save it from your behavior.
Kent's blog post
Kent's blog post
Kent's blog post
Kent's blog post
Kent's blog post
Acrimony does not enable forward progress
Kent's blog post
Kent's blog post
Kent's blog post
> Sometimes the fight is worth having.
Kent's blog post
Kent's blog post
Kent's blog post
Apologies are underrated
Apologies are underrated
Apologies are underrated
Apologies are underrated
Kent's blog post
Kent's blog post
Kent's blog post
How did it all start?
How did it all start?
How did it all start?
How did it all start?
How did it all start?
How did it all start?
How did it all start?
I do think you have a point about the axe grinding, and it might do some good if you can start that deeper discussion about being put in frustrating situations.
There does have to be some point where there are bright line rules, still.
How did it all start?
How did it all start?
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others’ private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
How did it all start?
How did it all start?
How did it all start?
How did it all start?
How did it all start?
How did it all start?
GFP_NOFAIL is documented as never failing:
* cannot handle allocation failures. The allocation could block
* indefinitely but will never return with failure. Testing for
* failure is pointless.
* It _must_ be blockable and used together with __GFP_DIRECT_RECLAIM.
* It should _never_ be used in non-sleepable contexts.
* New users should be evaluated carefully (and the flag should be
* used only when there is no reasonable failure policy) but it is
* definitely preferable to use the flag rather than opencode endless
* loop around allocator.
* Allocating pages from the buddy with __GFP_NOFAIL and order > 1 is
* not supported. Please consider using kvmalloc() instead.
1) drop __GFP_NOFAIL and get back to the situation that existing callers will revert to their endless loop around the allocator or simply rely on GFP_KERNEL effectively never fails semantic for non-costly (order < 4) allocations.
2) change the existing semantic and make it almost never fail - with a good definition of "almost"
3) keep the strict never fail semantic that is currently documented.
How did it all start?
> 1) drop __GFP_NOFAIL and get back to the situation that existing callers will revert to their endless loop around the allocator or simply rely on GFP_KERNEL effectively never fails semantic for non-costly (order < 4) allocations.
> 2) change the existing semantic and make it almost never fail - with a good definition of "almost"
> 3) keep the strict never fail semantic that is currently documented.
How did it all start?
How did it all start?
* If the other person is The Decider and there is no higher authority... look, sooner or later, somebody has to lose one of these arguments. If you've already escalated all the way to the top and Linus/the TAB/whoever still thinks you're wrong, it's time to fold and either live with the decision or discontinue the affected work. If you feel really strongly, you could fork the kernel or carry an out-of-tree patch.
* If the other person resorts to insults or other aggressive behavior, don't respond in kind. Ignore them or report them, as you see fit, and continue to discuss the substantive issue without regard for the insults.
How did it all start?
Bound to happen
Bound to happen
Meritocracy is a scam
Meritocracy is a scam
Non-sense
The "*BSD crowd" is actually an interesting case in point. Have a look at the origin stories for some of those BSD variants and think about whether that's what you really want for Linux, or if it's maybe better for us to figure out how to get along with each other?
BSD
BSD
BSD
BSD
BSD
BSD
Non-sense
Non-sense
Non-sense
Linus could pull Kent tree and the TAB would not be able to do anything about it, or the TAB could rescind the sanction, and Linus could still refuse to pull Kent tree.
Non-sense
Non-sense
Non-sense
Non-sense
Non-sense
Non-sense
Non-sense
Non-sense
Non-sense
Non-sense
Non-sense
Non-sense
Form over substance ; weird asymmetry
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Wol
Forced apologies are harmful
Forced apologies are harmful
Wol
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Wol
Forced apologies are harmful
not so shouty as he seems
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
Does the COC decision work? (was Forced apologies are harmful)
Does the COC decision work? (was Forced apologies are harmful)
Does the COC decision work? (was Forced apologies are harmful)
Does the COC decision work? (was Forced apologies are harmful)
Does the COC decision work? (was Forced apologies are harmful)
Forced apologies are harmful
Forced apologies are harmful
to the community that a public apology would provide.
It's not transparently evident to me. All CoC deliberations I've been privy to have been about communicating to the rest of the
community the boundaries of acceptable behavior, and getting those involved back to productive activity as smoothly and quickly as possible.
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
[2] https://www.npr.org/2023/01/25/1150972343/how-to-say-sorr...
* Explain what happened (WITHOUT excusing the behavior)
*. Express remorse
* Offer to make amends
apology that says, you know, 'You shouldn't even have a white sofa,'
or, 'You shouldn't have been standing there,'" she said.
Forced apologies are harmful
Forced apologies are harmful
Wol
Forced apologies are harmful
Forced apologies are harmful
Forced apologies are harmful
A very difficult topic
BTRFS and Facebook
BTRFS and Facebook
BTRFS and Facebook
BTRFS and Facebook
BTRFS and Facebook
ZFS on Linux is great, but it has three serious issues (two of which are Linux-specific):BTRFS and Facebook
There are other, smaller issues such as unlink() operations being particularly slow and the CDDL license pushing all development out-of-tree, but those are not too problematic and are pretty much unavoidable anyway. The other issues are more severe. That doesn't mean that ZFS is a bad filesystem, to the contrary I think it is the best filesystem for Linux for reliability as its reliability features go far beyond merely checksumming all data and metadata. But we should all keep in mind that there is room for improvement, especially on Linux.
BTRFS and Facebook
BTRFS and Facebook
BTRFS and Facebook
Wol
BTRFS and Facebook
BTRFS and Facebook
BTRFS and Facebook
- Management were not prepared to totally give away Solaris (i.e. no BSD licence), they wanted the strongest possible licence, i.e. copyleft
-- Schwarz had written favourably about the GPL
-- I believe management's initial idea was to use the GPL
- Engineering hated the GPL and absolutely refused to go with that (I don't think there's a rational reason for this, just cultural factors from BSD leanings)
- So... management decided to come up with some new licence
-- Possibly legal also liked the idea of being able to write a new licence, and weren't fans of the GPL
--- Though, some in Sun legal did help with input to the GPLv3 drafting process
- We got the CDDL
BTRFS and Facebook
BTRFS and Facebook
GFP_NOFAIL and error handling
> Besides dramatic accusations of breakage - theoretical in this case, from a developer with a history of introducing silent data corruption bugs into code I've written...
GFP_NOFAIL and error handling