What he said wasn't even nearly as bad as what I've seen Linus say in other threads over the years. Is / was Linus Torvalds ever subject to a "tribunal" like Kent just was?
In the end, it's the users that end up suffering. The guy (Hocko) kept making mistake after mistake and Kent struggled to get him to do anything remotely net positive with regard to the issues in that original thread.
I'm not arguing that what Kent did was right or wrong, but I would be curious to hear what other ways people work with remote developers who are awful, especially when they work for other companies. You can't just fire them, so I understand the frustration here.
And I would say on a whole his behavior after 2018 has been less rude although he is still quite frank when necessary. I think it’s a positive change.
I think Linus’s message from 2018 is good perspective here: when someone behaves in a way that harms the mission of the kernel it’s better to try to change that behavior at the expensive of that person’s contributions for a limited time, rather than having the bad behavior negatively impact all other contributors forever.
The current CoC came out from a particularly bad incident with Linus, which he signed off on at the same time as he went into therapy and started working on himself. There is a remarkable difference in the before and after.
> I'm not arguing that what Kent did was right or wrong, but I would be curious to hear what other ways people work with remote developers who are awful, especially when they work for other companies. You can't just fire them, so I understand the frustration here.
They absolutely can "fire" them, by making a decision not to accept any contribution from them.
Around the time the CoC was being established, Linus went to therapy. If I recall correctly, some people had spoke to him about his behaviors and he decided to do something about it. I think it was done in private so it's unclear how much of it was pressure vs his own decision. His tone has become much less aggressive since.
Honesty is often unpleasant, especially when someone tells us that our work isn't good enough. But it is a required thing from a leader. The important thing is that he's cut down on needless personal insults.
But Linus isn't honest. I'm sure he thinks he is, but he's not always "objective". So while he thinks he's being honest, what he's saying can be untrue anyway.
And of course he's Linus and you're a nobody so nobody will ever listen to the other side of the completely subjective "facts"
Being honest doesn’t have anything to do with being objectively correct, unless a person is presenting their subjective feelings as objective fact.
Saying to someone “your work is not good enough for me” is a subjective statement; whether or not it is honest depends on whether or not it is reflective of the speaker’s beliefs about the quality of the work.
A leader not speaking up when they receive subpar work is dishonest, and it is fundamentally unfair to the person doing the work.
1) only if you truly believe the earth to be flat
2) the earth being a sphere is an objective fact that can be proven by multiple means.
You would either be mistaken if you believed the earth to be flat, or a liar if you didn't.
That also has absolutely nothing to do with your original claim -- that Linus has been "dishonest" because his opinions about technical matters discussed on LKML aren't objective. There is a fundamental difference between stating a fact ("the earth is a sphere") and an opinion ("this work is not up to my standards" or "I do not agree with your approach to solving this problem.")
Note: being rude in expressing their opinions might make a person an asshole, but it does not make them "dishonest."
Linus did take a break to work on his anger issues and he has been very noticeably improved these last 6 years. While I don't think it was due to a tribunal, but I think enough other developers told him in private to work on it.
Came a bit too late for me; I spent some time fixing bugs in an ISDN driver in my teens, but Linus’ reputation prevented me from ever trying to upstream it.
I tried reading the history here. I confess the emails signed "on behalf of the committee" hit with a bad taste.
In particular, if the goal is to promote more discussion and openness between contributors, having a "committee" involved feels very counter productive. As does demanding an apology.
By all means, empower folks to call others out as rude. Publicly call out what you see as transgressions. But don't do so with a shield of, "I'm speaking for the committee."
I think this CoC nonsense makes me far less likely to contribute to the kernel. CoC's should be nothing more than "Don't be a jerk, and keep it constructive". Kent's interaction in that one instance was jerk-ish for sure. But the last thing we need is some big brother committee bringing down the hammer of shame on key maintainers. Let them have their heated technical arguments. How about we try and not be so easily offended by everything?
I'm torn. I think having a stated code of conduct is fine. I also think moderation is good. Works well here, as an example. But, it is done very directly here with no hiding behind process.
I get that things can be harder in other context. But will never agree with personal messages on behalf of a committee, I don't think.
And for the apologies, that is silly. Would be akin to someone getting a citation being responsible to say sorry. Ideally, you want people to feel the need to do that on their own. At young ages, it is understandable to try and teach the formalities of apologies. But, as a formal policy, it robs apologies of any real meaning.
I don't think what Kent did was right, but I'm also not sure this kind of heavy-handed approach by the CoC team is good, either. The forced public apology sounds a bit like a kindergarten teacher forcing two kids to shake hands after a fight.
On my part, I just hope that Linux will get a real competitor to ZFS.
I've been an on and off contributor of FLOSS software for a long time. Sometimes I sent some unfinished patches and got responses like ' I don't think you know what you're doing' and 'turn on brain'.
At the time I considered those developers were right and didn't complain. It made more careful before sending patches and commenting. But it also affected my willing to contribute with the project. I also consider that, although those devs were right, they could have expressed themselves more cordially. I don't think being that rude improves anything.
I do support the CoC committee decision and hope more projects had one.
I agree with your general point about the effects of such rudeness, but I also think the solution is to actually "just" write to these people (in broad cc) and say "Please consider that, although [you] devs were right, [you] could have expressed [your]selves more cordially. I don't think being that rude improves anything, [and] this behaviour has affected my willing to contribute with the project.". Even if your own email falls on deaf ears, the second or third will trigger reflection. And the 10th will trigger some sort of review by colleagues. After all, at the end of the day, it's a team of adults who are all in it for the same goal, and they should be trusted to be able to handle it like adults when concerns have been expressed in the appropriate manner.
Whereas CoC-driven development risks leading to a chilling effect where you no longer constructively argue about stuff, let alone in a passionate manner (that, admittedly, risks going the wrong side of the fence on occasion), and just let shit pile up because it's not your business to be getting the snake out of the hole and messing with a CoC Panel for it.
And this is even in the 'ideal' case where the CoC Panel has no 'political' ulterior motives. God forbid when this is not the case.
> Whereas CoC-driven development risks leading to a chilling effect where you no longer constructively argue about stuff, let alone in a passionate manner (that, admittedly, risks going the wrong side of the fence on occasion), and just let shit pile up
Being technically wrong and unproductive during a technical argument should not warrant being insulted.
But It would surely suffice to prevent a demand for a public apology from the exasperated party who was on the right side of the argument ; or at least not before the insulted party having issued an apology for being wrong and uncooperative in the first place.
When CoC have the effect of punishing volunteer work for not being nice/polite/SFW during an argument, regardless of who was technically right, this is putting form over substance.
This is a stance that seems balanced toward corporate friendliness.
But I believe that the kernel benefits more from being a community/volunteer oriented project than pandering to corporate culture of niceness over anything else.
My reading of it is that they both were being jerks. In particular, the whole "I supported my argument with references, but it's YOUR job to locate those arguments" never sits well with me.
Reminds me a bit of this time I had FINALLY gotten someone to volunteer to help out with maintenance, and his first action was met with someone being a real jerk. I called them out on it and they started attacking me. I never replied, but I did get an "appology" from them: [paraphrased] "I'm sooo sorry... That I sent that from my work address. Please don't get me fired, I need this job."
So "CoC committee" recommends refusing pull requests because their author was rude when arguing technical issue with someone who appears to be incompetent?
Am I getting this right?
I really want to migrate my zfs pool to bcachefs so I can finally follow the latest version of fedora from day one, but this crap is making me doubt it’s a good move…
Regardless of everything else, most people should not be using bcachefs yet. Kent has even stated that unless you're okay not being able to access your data for chunks of time while bugs are being fixed, you shouldn't be using it. The conventional wisdom would be to wait 10 years after a new filesystem is introduced for it to stabilize before switching, so we're looking at summer next year at the earliest.
Apart from that, there are (or were, last I tried it six months ago) some performance bugs in the code.
Nothing that completely breaks it, but I found at the time that the high variance on read requests for Samsung 970 series NVMe causes the filesystem to also dispatch reads of cached data to the HDDs, even when it’s fully cached.
Which predictably increases latency a lot.
Really I should make another stab at fixing that, but the whole driver is C, and I’m not good at writing flawless C. Combine that with the problem actually being hard…
(“Always read from SSD” isn’t a valid solution here.)
Sorry to say, I have some old SSDs that are only 3-4 times faster than the HDDs. Especially when there’s a lot of HDDs in the pool, ignoring them could be leaving a lot of performance on the floor.
Though it would be an improvement over what I saw last time I tried, sure.
If we're talking about my desktop, its current configuration is 3x 2TB NVMe (configured as zfs cache) plus 2x 12TB HDDs (mirrored). I've set sync=disabled, with transaction groups committing every 10 minutes — this is fine for my use case — so the HDDs spend most of their time spun down.
I only actually have 4TB of data on the system. It keeps growing, but the working set is probably much less than that.
Which means, it's 100% cached. A single read sent to the HDDs would have a latency of multiple seconds; absolutely catastrophic for a desktop workload. In this case _always_ using the cache _is_ the right answer, but I've been trying to think of an algorithm that would be able to do so without hardcoding it.
Is there not some sort of standardized, stringent filesystem test yet? Like Jepsen is for databases? If passed, one can be sure it is reasonably free from bugs? Guess not.
No, they had the option of having a real conversation in private about what we could do to improve the overall situation.
Instead what I got was "It'd be a real shame if you're no longer around", and other equally dismissive behavior, and considering this was a situation in which a maintainer was pushing for something that would likely have led to security vulnerabilities and was being dismissive of criticism I didn't feel that was something we could let slide.
> No, they had the option of having a real conversation in private about what we could do to improve the overall situation.
Abusing others individually in public, but expecting a quiet word on the side about “the overall situation” when it comes to your own behavior. I hope you realize something from this.
I want superiority de-coupled from technical expertise in the minds of the people who have the latter.
Taking his personal struggles out of kernel development and onto Hacker News was the escalation – pointing out his hypocrisy is only trying to get people who agree with him to realize that they’re wrong.
I've gotten into arguments that were even more heated with maintainers who introduced data corruption bugs into code I wrote in the core block layer, without CCing me, which then hit users I support, and then had to track down, and then had them put up ridiculous fights over getting the bugs fixed.
Context matters, and also, if we're going to have standards for professional conduct they do need to be about more than just language.
We shouldn't be punching down, but we shouldn't be insulating maintainers from criticism when they're being incompetent, either.
Tbh the longer this goes on the worse it makes the kernel and Kent look.
Coc drama is petty but this is the latest in months worth of problems coming out of bcachefs.
Were currently at the point of "get better" and the next action should be "get out".
There is a place for bcachefs in the kernel, it's just out of tree.
There are no instances anyone can point to where I've caused regressions in other subsystems, in the course of developing bcachefs. I have had people introduce regressions into my code without following proper channels, though.
Changes should be in place in time for regression testing, if you cannot manage that wait for the next cycle.
Those same rules apply to everyone, and you're being called out for not only repeatedly ignoring them, but also for refusing to listen to that criticism.
I am very much on the observer/user side of FLOSS, but the way Codes of Conduct have been applied since their widespread adoption have seen a lot of very productive developers ostracized for their emotionally unregulated methods of communications. This general regard for ceremony and civility above anything else leads to these NKVD-like committees policing code access where the quality of work delivered is considered only collaterally, if at all.
I am worried that the trend these code of conduct implementations set in the past few years optimize for a future where development environments will be optimized for the prosperity of low-productivity, low-intelligence, high-vulnerability and highly-provocative individuals. This idea that the tone of communication may not be coupled in any way to the frustration of the correspondent is in my opinion extremely misanthropic and allows intense psychological abuse through condescension and/or playing dumb.
Just to be clear, Overstreet wrote an email asking someone to “get their head checked” and “get the fuck out of here with this shit”.
I don’t think it’s the CoC committee overreacting. I would reach to HR advising termination if a member of my team did this to someone in writing. This is straight up illegal in my country. If you write this to someone, you will lose if they sue. A lenient sanction and some probation seems fine for someone with a history of good contribution but doing nothing would be wrong.
I don't consider that very extreme considering the persistent harassment by someone who, as far as I could tell by the mailing list archive and Overstreet's Patreon, was wrong about the subject matter and insisted on it multiple times, with ascending levels of agression each iteration.
Personally, I would take such an insult as a signal to step away from the immediate conversation and maybe rethink it after some time, but this (admittedly very flamewar provoking and somewhat rude) way of pressing the RESET button on a conversation is understandably not tolerated in the same capacity as it might have been in the 1990s. The problem is, we haven't really replaced it with anything that's as efficient.
Believing that a corporate friendly HR-like body with termination power, is what a community project like linux needs is a part of the current problem.
This mentality will encourage the take-over of FLOSS communities by power-grabbing psychopath types that already thrive in corporate environments.
The CoC committee was long overdue. The decision here is both lenient - it’s only one release - pragmatic and necessary. We should aspire to more friendless not some weird tolerance for behaviour which would he unacceptable everywhere else.
Good code is not written in a democratic way. Seems like Hocko was wearing Kent down with his arguments on what was a very bad idea in the first place.
I agree the last sentence by Kent was not needed, but I can totally understand his frustration.
I think it’s a loss for the users at the end on the day.
Kent is only prevented to merge for a version and mostly because he refused to actually apologise and kind of dig his heels.
Reading his comment on LWN, he seems really really tired. A mandatory break doesn’t look like the worst thing which would happen to him. I don’t think he is a bad person.
Sorry for the poor grammar, I meant could and not would and I hope you took my comment as good intended (it was). I value your contribution a lot. Reading you just reminds me of myself when I had postponed time off far too long at a previous job. I hope you don’t take it too badly and see the occasion as a good time to take a step back and rest even if it’s not your choice.
Arguably a win for the community of users in the long term as those developers who would like a safe environment, more akin to a professional one, will be encouraged to contribute.
In the short term Ken will have to wait for the time out to end, so a loss for sure.
On balance the future is bigger than the present so suffering today for a better future is utilitarian.
And there are a lot of sensitive folk who have been scared off of communities by what they saw. In this thread a couple have commented about the pre CoC community, that they would have contributed but for the fear of getting barked at.
As a younger dev I bailed on some IRC communities after getting weirdly threatened.
Frustration after being very patient with one’s donated time and feeling unreciprocated can lead to frayed nerves and in the short term being rude is brief and often effective - so it is very understandable that this sort of thing will arise.
Good to discuss how we handle these difficult situations of onboarding newbies without scaring some of the lurking next generation of devs.
As a headline this penalty seems harsh, but efforts were made to mediate before the committee made the ruling and proved unsuccessful.
This process is defining the future culture of the kernel code community and it is widely accepted that it should be less toxic and more welcoming and akin to what is expected in a professional context where most devs also function and also have to patiently onboard new developers.
There may be room for improvement of the process, for instance, like in many settings the burden of patient onboarding may need to fall on a community process with an onboarding ramp that doesn’t fall only on the shoulders of those accepting patches.
As a community it behooves us to step in earlier and help new devs polish their contributions before submission.
Especially if we see a fraustration brewing, step in and offer code review to the new developers, who want to contribute, but need some guidance.
Often just guidance about the right questions to ask and where and how to find the answers oneself before asking.
The eternal September doesn’t have to be so, offering to help with onboarding a new dev helps everyone.
Professional environments are terrible. Why do you think there's an abundance of films like "mayhem" and others, showing how dehumanising the "professional environment" is?
“professional environments” have flaws - and can be as you assert dehumanisating - more so when orgs are large, and rules enforced blindly or with ‘zero tolerance’.
I meant it as a proxy for a forum where mutual respect and civility are theoretically expected.
Although in the real world not always present.
I agree that rules can potentially be overbearing and curtail free expression but also protect and nurture expression where it is suppressed by an unruly culture.
As in most things, it is difficult to find a good balance and a healthy community is self-regulating.
Has that fork of Godot Engine that was established to "focus on the code instead of politics" achieved anything besides merging upstream Godot patches and replacing the branding with their own yet? They don't seem to be doing much coding compared to the "political" project they forked.
You don’t get code without people, and the industry is finally realizing that it’s a net negative to have an asshole who produces great code but scares away more productivity than they bring.
This is not a new thing. Patrick Lencioni made a very good job in his "Five Dysfunctions of a Team" (2002), where he explained clearly why the "star developer" sometimes needs to be fired to boost net team productivity as a whole.
What's new here is the benchmark for "what counts as an asshole". If you need to watch every single word in fear of giving anyone the opportunity to cry 'offense' and invoke a CoC panel on you, that's when all trust in the room goes out the window, and when you really start flushing productivity down the drain.
Sure, one of the effect of CoCs is that it can be easier to get rid of an assohole who, even if he is productive, can have a negative impact (not a judgment about the case at hand wrt. Kent Overstreet).
But there are so many other effects that it is still unclear to me wether, at the end of the day, CoCs attract or detter coders from joining / staying with a project.
I've often found myself fighting the macho/childish/exclusive culture around tech, yet the reliance of formal CoCs to police our attitude have made me feel uncomfortable. I guess I'm not the only one.
It's also a net negative to be burdened by incompetent coders with unjustified confidence and a mistaken sense of their own abilities, however polite they might be.
There are better ways of dealing with that than letting assholes roam free. It’s like tear-gassing your bar to keep out ruffians. It technically works, but it’s rather indiscriminate.
One can be considered an asshole while not being an asshole by many people's standard though. Anyone could find an issue with your behavior. Ethics and morality are not so clear cut. Plus, if behavior is an issue, one needs to specify that behavior, labels (such as "asshole") are extremely inadequate.
This right here is the reason code of conduct exists: so that everyone agrees on what kind of behavior is out of line before starting to work on the project.
What he said wasn't even nearly as bad as what I've seen Linus say in other threads over the years. Is / was Linus Torvalds ever subject to a "tribunal" like Kent just was?
In the end, it's the users that end up suffering. The guy (Hocko) kept making mistake after mistake and Kent struggled to get him to do anything remotely net positive with regard to the issues in that original thread.
I'm not arguing that what Kent did was right or wrong, but I would be curious to hear what other ways people work with remote developers who are awful, especially when they work for other companies. You can't just fire them, so I understand the frustration here.
Yes, Linus took some time off to “learn empathy” https://arstechnica.com/gadgets/2018/09/linus-torvalds-apolo...
And I would say on a whole his behavior after 2018 has been less rude although he is still quite frank when necessary. I think it’s a positive change.
I think Linus’s message from 2018 is good perspective here: when someone behaves in a way that harms the mission of the kernel it’s better to try to change that behavior at the expensive of that person’s contributions for a limited time, rather than having the bad behavior negatively impact all other contributors forever.
https://lkml.org/lkml/2018/9/16/167
The current CoC came out from a particularly bad incident with Linus, which he signed off on at the same time as he went into therapy and started working on himself. There is a remarkable difference in the before and after.
> I'm not arguing that what Kent did was right or wrong, but I would be curious to hear what other ways people work with remote developers who are awful, especially when they work for other companies. You can't just fire them, so I understand the frustration here.
They absolutely can "fire" them, by making a decision not to accept any contribution from them.
Around the time the CoC was being established, Linus went to therapy. If I recall correctly, some people had spoke to him about his behaviors and he decided to do something about it. I think it was done in private so it's unclear how much of it was pressure vs his own decision. His tone has become much less aggressive since.
He's been unpleasant also after he came back. Not as extreme maybe, but certainly not nice.
Honesty is often unpleasant, especially when someone tells us that our work isn't good enough. But it is a required thing from a leader. The important thing is that he's cut down on needless personal insults.
But Linus isn't honest. I'm sure he thinks he is, but he's not always "objective". So while he thinks he's being honest, what he's saying can be untrue anyway.
And of course he's Linus and you're a nobody so nobody will ever listen to the other side of the completely subjective "facts"
Being honest doesn’t have anything to do with being objectively correct, unless a person is presenting their subjective feelings as objective fact.
Saying to someone “your work is not good enough for me” is a subjective statement; whether or not it is honest depends on whether or not it is reflective of the speaker’s beliefs about the quality of the work.
A leader not speaking up when they receive subpar work is dishonest, and it is fundamentally unfair to the person doing the work.
Well I can be completely honest and tell you that the earth is flat. Do you see now that being objective is also needed?
1) only if you truly believe the earth to be flat 2) the earth being a sphere is an objective fact that can be proven by multiple means.
You would either be mistaken if you believed the earth to be flat, or a liar if you didn't.
That also has absolutely nothing to do with your original claim -- that Linus has been "dishonest" because his opinions about technical matters discussed on LKML aren't objective. There is a fundamental difference between stating a fact ("the earth is a sphere") and an opinion ("this work is not up to my standards" or "I do not agree with your approach to solving this problem.")
Note: being rude in expressing their opinions might make a person an asshole, but it does not make them "dishonest."
He should get some tips from Theo. :D
Linus did take a break to work on his anger issues and he has been very noticeably improved these last 6 years. While I don't think it was due to a tribunal, but I think enough other developers told him in private to work on it.
https://www.theregister.com/2018/09/17/linus_torvalds_linux_...
Came a bit too late for me; I spent some time fixing bugs in an ISDN driver in my teens, but Linus’ reputation prevented me from ever trying to upstream it.
From having dealt with him personally, you probably saved yourself a lot of trouble.
The CoC is new, so no Linus wasn't subject to it in the past.
I tried reading the history here. I confess the emails signed "on behalf of the committee" hit with a bad taste.
In particular, if the goal is to promote more discussion and openness between contributors, having a "committee" involved feels very counter productive. As does demanding an apology.
By all means, empower folks to call others out as rude. Publicly call out what you see as transgressions. But don't do so with a shield of, "I'm speaking for the committee."
I think this CoC nonsense makes me far less likely to contribute to the kernel. CoC's should be nothing more than "Don't be a jerk, and keep it constructive". Kent's interaction in that one instance was jerk-ish for sure. But the last thing we need is some big brother committee bringing down the hammer of shame on key maintainers. Let them have their heated technical arguments. How about we try and not be so easily offended by everything?
I'm torn. I think having a stated code of conduct is fine. I also think moderation is good. Works well here, as an example. But, it is done very directly here with no hiding behind process.
I get that things can be harder in other context. But will never agree with personal messages on behalf of a committee, I don't think.
And for the apologies, that is silly. Would be akin to someone getting a citation being responsible to say sorry. Ideally, you want people to feel the need to do that on their own. At young ages, it is understandable to try and teach the formalities of apologies. But, as a formal policy, it robs apologies of any real meaning.
Which actually works quite well for places like OpenBSD. The lack of a star chamber CoC puts the focus on writing good code.
Not meaning to support him, but for Kent’s perspective:
https://www.patreon.com/posts/trouble-in-116412665
I don't think what Kent did was right, but I'm also not sure this kind of heavy-handed approach by the CoC team is good, either. The forced public apology sounds a bit like a kindergarten teacher forcing two kids to shake hands after a fight.
On my part, I just hope that Linux will get a real competitor to ZFS.
I've been an on and off contributor of FLOSS software for a long time. Sometimes I sent some unfinished patches and got responses like ' I don't think you know what you're doing' and 'turn on brain'.
At the time I considered those developers were right and didn't complain. It made more careful before sending patches and commenting. But it also affected my willing to contribute with the project. I also consider that, although those devs were right, they could have expressed themselves more cordially. I don't think being that rude improves anything.
I do support the CoC committee decision and hope more projects had one.
I agree with your general point about the effects of such rudeness, but I also think the solution is to actually "just" write to these people (in broad cc) and say "Please consider that, although [you] devs were right, [you] could have expressed [your]selves more cordially. I don't think being that rude improves anything, [and] this behaviour has affected my willing to contribute with the project.". Even if your own email falls on deaf ears, the second or third will trigger reflection. And the 10th will trigger some sort of review by colleagues. After all, at the end of the day, it's a team of adults who are all in it for the same goal, and they should be trusted to be able to handle it like adults when concerns have been expressed in the appropriate manner.
Whereas CoC-driven development risks leading to a chilling effect where you no longer constructively argue about stuff, let alone in a passionate manner (that, admittedly, risks going the wrong side of the fence on occasion), and just let shit pile up because it's not your business to be getting the snake out of the hole and messing with a CoC Panel for it.
And this is even in the 'ideal' case where the CoC Panel has no 'political' ulterior motives. God forbid when this is not the case.
Basically, careful what you wish for.
> Whereas CoC-driven development risks leading to a chilling effect where you no longer constructively argue about stuff, let alone in a passionate manner (that, admittedly, risks going the wrong side of the fence on occasion), and just let shit pile up
Based on what data?
Being technically wrong and unproductive during a technical argument should not warrant being insulted.
But It would surely suffice to prevent a demand for a public apology from the exasperated party who was on the right side of the argument ; or at least not before the insulted party having issued an apology for being wrong and uncooperative in the first place.
When CoC have the effect of punishing volunteer work for not being nice/polite/SFW during an argument, regardless of who was technically right, this is putting form over substance.
This is a stance that seems balanced toward corporate friendliness. But I believe that the kernel benefits more from being a community/volunteer oriented project than pandering to corporate culture of niceness over anything else.
Losing BcacheFS over this would be a shame.
It's american culture.
And it's corporate because linux is now corporate run. And all these things make sure that no volunteer will ever take part.
My reading of it is that they both were being jerks. In particular, the whole "I supported my argument with references, but it's YOUR job to locate those arguments" never sits well with me.
Reminds me a bit of this time I had FINALLY gotten someone to volunteer to help out with maintenance, and his first action was met with someone being a real jerk. I called them out on it and they started attacking me. I never replied, but I did get an "appology" from them: [paraphrased] "I'm sooo sorry... That I sent that from my work address. Please don't get me fired, I need this job."
So "CoC committee" recommends refusing pull requests because their author was rude when arguing technical issue with someone who appears to be incompetent? Am I getting this right?
I really want to migrate my zfs pool to bcachefs so I can finally follow the latest version of fedora from day one, but this crap is making me doubt it’s a good move…
Regardless of everything else, most people should not be using bcachefs yet. Kent has even stated that unless you're okay not being able to access your data for chunks of time while bugs are being fixed, you shouldn't be using it. The conventional wisdom would be to wait 10 years after a new filesystem is introduced for it to stabilize before switching, so we're looking at summer next year at the earliest.
Apart from that, there are (or were, last I tried it six months ago) some performance bugs in the code.
Nothing that completely breaks it, but I found at the time that the high variance on read requests for Samsung 970 series NVMe causes the filesystem to also dispatch reads of cached data to the HDDs, even when it’s fully cached.
Which predictably increases latency a lot.
Really I should make another stab at fixing that, but the whole driver is C, and I’m not good at writing flawless C. Combine that with the problem actually being hard…
(“Always read from SSD” isn’t a valid solution here.)
"Always read from SSD" seems like what you'd want, no?
I have something on the back burner to start benchmarking devices at format time, that would let us start making better decisions in these situations.
Sorry to say, I have some old SSDs that are only 3-4 times faster than the HDDs. Especially when there’s a lot of HDDs in the pool, ignoring them could be leaving a lot of performance on the floor.
Though it would be an improvement over what I saw last time I tried, sure.
Oh, that is tricky. If you want to play around with the algorithm that picks which device to read from, it's in fs/bcachefs/extents.c
Perhaps just squaring the device latencies would balance things out more the way we want.I remember this code!
If we're talking about my desktop, its current configuration is 3x 2TB NVMe (configured as zfs cache) plus 2x 12TB HDDs (mirrored). I've set sync=disabled, with transaction groups committing every 10 minutes — this is fine for my use case — so the HDDs spend most of their time spun down.
I only actually have 4TB of data on the system. It keeps growing, but the working set is probably much less than that.
Which means, it's 100% cached. A single read sent to the HDDs would have a latency of multiple seconds; absolutely catastrophic for a desktop workload. In this case _always_ using the cache _is_ the right answer, but I've been trying to think of an algorithm that would be able to do so without hardcoding it.
Is there not some sort of standardized, stringent filesystem test yet? Like Jepsen is for databases? If passed, one can be sure it is reasonably free from bugs? Guess not.
The thing is that filesystems are inherently statful, so the same test might trigger different edge cases depending on the state of the fs.
I suggest reading the whole mail thread before judging. The CoC decision was the last resort.
No, they had the option of having a real conversation in private about what we could do to improve the overall situation.
Instead what I got was "It'd be a real shame if you're no longer around", and other equally dismissive behavior, and considering this was a situation in which a maintainer was pushing for something that would likely have led to security vulnerabilities and was being dismissive of criticism I didn't feel that was something we could let slide.
Priorities, people.
> No, they had the option of having a real conversation in private about what we could do to improve the overall situation.
Abusing others individually in public, but expecting a quiet word on the side about “the overall situation” when it comes to your own behavior. I hope you realize something from this.
Do you want to de-escalate or make flame wars?
I want superiority de-coupled from technical expertise in the minds of the people who have the latter.
Taking his personal struggles out of kernel development and onto Hacker News was the escalation – pointing out his hypocrisy is only trying to get people who agree with him to realize that they’re wrong.
No Kent, really.
I've gotten into arguments that were even more heated with maintainers who introduced data corruption bugs into code I wrote in the core block layer, without CCing me, which then hit users I support, and then had to track down, and then had them put up ridiculous fights over getting the bugs fixed.
Context matters, and also, if we're going to have standards for professional conduct they do need to be about more than just language.
We shouldn't be punching down, but we shouldn't be insulating maintainers from criticism when they're being incompetent, either.
Tbh the longer this goes on the worse it makes the kernel and Kent look. Coc drama is petty but this is the latest in months worth of problems coming out of bcachefs. Were currently at the point of "get better" and the next action should be "get out". There is a place for bcachefs in the kernel, it's just out of tree.
Why didn't they block his access to the mailing list instead?
It's not his code that people felt hurt by, was it?
Yeah, it kinda was - https://lore.kernel.org/all/172816780614.3194359.10913571563...
He was refusing to contribute his code according to the rules (by which everyone is meant to abide), avoiding regression testing and creating bugs.
And he certainly didn't help his case with tone deaf comments like this:
> If you're so convinced you know best, I invite you to start writing your own filesystem. Go for it.
Linus was completely going off there.
There are no instances anyone can point to where I've caused regressions in other subsystems, in the course of developing bcachefs. I have had people introduce regressions into my code without following proper channels, though.
It's a moot point.
Changes should be in place in time for regression testing, if you cannot manage that wait for the next cycle.
Those same rules apply to everyone, and you're being called out for not only repeatedly ignoring them, but also for refusing to listen to that criticism.
> Linus was completely going off there.
It's his kernel.
Pull requests happen through the mailing list, fwiw.
I am very much on the observer/user side of FLOSS, but the way Codes of Conduct have been applied since their widespread adoption have seen a lot of very productive developers ostracized for their emotionally unregulated methods of communications. This general regard for ceremony and civility above anything else leads to these NKVD-like committees policing code access where the quality of work delivered is considered only collaterally, if at all.
I am worried that the trend these code of conduct implementations set in the past few years optimize for a future where development environments will be optimized for the prosperity of low-productivity, low-intelligence, high-vulnerability and highly-provocative individuals. This idea that the tone of communication may not be coupled in any way to the frustration of the correspondent is in my opinion extremely misanthropic and allows intense psychological abuse through condescension and/or playing dumb.
Just to be clear, Overstreet wrote an email asking someone to “get their head checked” and “get the fuck out of here with this shit”.
I don’t think it’s the CoC committee overreacting. I would reach to HR advising termination if a member of my team did this to someone in writing. This is straight up illegal in my country. If you write this to someone, you will lose if they sue. A lenient sanction and some probation seems fine for someone with a history of good contribution but doing nothing would be wrong.
I’m not sure comparing that to the NKVD is wise.
I don't consider that very extreme considering the persistent harassment by someone who, as far as I could tell by the mailing list archive and Overstreet's Patreon, was wrong about the subject matter and insisted on it multiple times, with ascending levels of agression each iteration.
Personally, I would take such an insult as a signal to step away from the immediate conversation and maybe rethink it after some time, but this (admittedly very flamewar provoking and somewhat rude) way of pressing the RESET button on a conversation is understandably not tolerated in the same capacity as it might have been in the 1990s. The problem is, we haven't really replaced it with anything that's as efficient.
Believing that a corporate friendly HR-like body with termination power, is what a community project like linux needs is a part of the current problem.
This mentality will encourage the take-over of FLOSS communities by power-grabbing psychopath types that already thrive in corporate environments.
Not sure why would anyone want that.
The CoC committee was long overdue. The decision here is both lenient - it’s only one release - pragmatic and necessary. We should aspire to more friendless not some weird tolerance for behaviour which would he unacceptable everywhere else.
In this conflict, there can only be losers. :-(
Good code is not written in a democratic way. Seems like Hocko was wearing Kent down with his arguments on what was a very bad idea in the first place.
I agree the last sentence by Kent was not needed, but I can totally understand his frustration.
I think it’s a loss for the users at the end on the day.
Kent is only prevented to merge for a version and mostly because he refused to actually apologise and kind of dig his heels.
Reading his comment on LWN, he seems really really tired. A mandatory break doesn’t look like the worst thing which would happen to him. I don’t think he is a bad person.
tired would not be inaccurate
Sorry for the poor grammar, I meant could and not would and I hope you took my comment as good intended (it was). I value your contribution a lot. Reading you just reminds me of myself when I had postponed time off far too long at a previous job. I hope you don’t take it too badly and see the occasion as a good time to take a step back and rest even if it’s not your choice.
> Good code is not written in a democratic way
[citation needed]
In case anyone's looking for that last sentence (quoting Kent here, not my words):
> Get your head examined. And get the fuck out of here with this shit.
https://lore.kernel.org/lkml/citv2v6f33hoidq75xd2spaqxf7nl5w...
> [citation needed]
IMHO
Code communities are very democratic, they produce good code and good coders.
Democracy is good governance not a dictatorship of a majority.
A benevolent dictatorship is said to be a most efficient form of government, until it ushers in a non-benevolent dictatorship.
Democracy is not perfect but relatively sustainable in that there is a peaceful mechanism for change and a means of consensus.
Small communities don’t need too many rules but in time as they grow it becomes necessary.
Arguably a win for the community of users in the long term as those developers who would like a safe environment, more akin to a professional one, will be encouraged to contribute.
In the short term Ken will have to wait for the time out to end, so a loss for sure.
On balance the future is bigger than the present so suffering today for a better future is utilitarian.
And there are a lot of sensitive folk who have been scared off of communities by what they saw. In this thread a couple have commented about the pre CoC community, that they would have contributed but for the fear of getting barked at.
As a younger dev I bailed on some IRC communities after getting weirdly threatened.
Frustration after being very patient with one’s donated time and feeling unreciprocated can lead to frayed nerves and in the short term being rude is brief and often effective - so it is very understandable that this sort of thing will arise.
Good to discuss how we handle these difficult situations of onboarding newbies without scaring some of the lurking next generation of devs.
As a headline this penalty seems harsh, but efforts were made to mediate before the committee made the ruling and proved unsuccessful.
This process is defining the future culture of the kernel code community and it is widely accepted that it should be less toxic and more welcoming and akin to what is expected in a professional context where most devs also function and also have to patiently onboard new developers.
There may be room for improvement of the process, for instance, like in many settings the burden of patient onboarding may need to fall on a community process with an onboarding ramp that doesn’t fall only on the shoulders of those accepting patches.
As a community it behooves us to step in earlier and help new devs polish their contributions before submission.
Especially if we see a fraustration brewing, step in and offer code review to the new developers, who want to contribute, but need some guidance.
Often just guidance about the right questions to ask and where and how to find the answers oneself before asking.
The eternal September doesn’t have to be so, offering to help with onboarding a new dev helps everyone.
Professional environments are terrible. Why do you think there's an abundance of films like "mayhem" and others, showing how dehumanising the "professional environment" is?
Good point !
“professional environments” have flaws - and can be as you assert dehumanisating - more so when orgs are large, and rules enforced blindly or with ‘zero tolerance’.
I meant it as a proxy for a forum where mutual respect and civility are theoretically expected.
Although in the real world not always present.
I agree that rules can potentially be overbearing and curtail free expression but also protect and nurture expression where it is suppressed by an unruly culture.
As in most things, it is difficult to find a good balance and a healthy community is self-regulating.
They really need to just kick him out of tree. Quit playing games with him and put bcachefs out of tree where it belongs.
[flagged]
[flagged]
Has that fork of Godot Engine that was established to "focus on the code instead of politics" achieved anything besides merging upstream Godot patches and replacing the branding with their own yet? They don't seem to be doing much coding compared to the "political" project they forked.
You don’t get code without people, and the industry is finally realizing that it’s a net negative to have an asshole who produces great code but scares away more productivity than they bring.
This is not a new thing. Patrick Lencioni made a very good job in his "Five Dysfunctions of a Team" (2002), where he explained clearly why the "star developer" sometimes needs to be fired to boost net team productivity as a whole.
What's new here is the benchmark for "what counts as an asshole". If you need to watch every single word in fear of giving anyone the opportunity to cry 'offense' and invoke a CoC panel on you, that's when all trust in the room goes out the window, and when you really start flushing productivity down the drain.
So, not a net positive in my view.
Sure, one of the effect of CoCs is that it can be easier to get rid of an assohole who, even if he is productive, can have a negative impact (not a judgment about the case at hand wrt. Kent Overstreet).
But there are so many other effects that it is still unclear to me wether, at the end of the day, CoCs attract or detter coders from joining / staying with a project.
I've often found myself fighting the macho/childish/exclusive culture around tech, yet the reliance of formal CoCs to police our attitude have made me feel uncomfortable. I guess I'm not the only one.
It's also a net negative to be burdened by incompetent coders with unjustified confidence and a mistaken sense of their own abilities, however polite they might be.
There are better ways of dealing with that than letting assholes roam free. It’s like tear-gassing your bar to keep out ruffians. It technically works, but it’s rather indiscriminate.
We've seen this with Python's CoC and Tim Peters as well. This timeline sucks.
[flagged]
One can be considered an asshole while not being an asshole by many people's standard though. Anyone could find an issue with your behavior. Ethics and morality are not so clear cut. Plus, if behavior is an issue, one needs to specify that behavior, labels (such as "asshole") are extremely inadequate.
There's also the blatant irony that calling someone an "asshole" would be against a sane interpretation of the CoC.
Yup!
This right here is the reason code of conduct exists: so that everyone agrees on what kind of behavior is out of line before starting to work on the project.
As long as the behavior is adequately specified or described just like one would do in terms of behavior modification, then yeah, that works!
Seems like Kent was a jerk, was given a chance to apologize, didn't, then got kicked out.
Seems like a functioning community to me.
Being a good programmer doesn't absolve you of the need to be a good person to others.
He did apologize, but the apology was deemed insufficient by the CoC. AIUI they wanted a public apology?
> AIUI they wanted a public apology?
Seems fair if the thing that needs an apology happened in public.
Linux is officially dead. This nonsense should not happen. Now users will suffer from bugs, because of some CoC nonsense.
The writing was already on the wall as soon as the CoC was added. It's nothing but a vehicle for control and abuse.