> What's next? Saying that particular drivers can't do DMA, because you
don't like that device, and as a DMA maintainer you control who can
use the DMA code? That's _literally_ exactly what you are trying to do with the Rust code.
"... Guess what wasn't caught, and
then wasn't fixed until -rc3? A bog-standard build error on the
esoteric platform called "i386".
...
"Guys and gals - this is normal. You should expect it. Breakage
happens. All the time. And that has nothing to do with Rust. It has to
do with the fact that we are doing software development.
Ask yourself: how many problems has rust caused you in the last year?
I'm claiming that the main problem has been people who have been
forthing at the mouth, not the actual rust support.
So next time you want to write an email to complain about rust
support: take a look in the mirror.
Is the problem actually the rust code causing you issue, or is the
problem between the keyboard and the chair, and you just want to vent?"
> Ask yourself: how many problems has rust caused you in the last year?
Isn't rust flag disabled by default? How would one know if there are any problems if most people don't use it?
Besides Hellwig's concerns were legit. When rust becomes a part of kernel either maintainer would have to learn Rust or depend on rust Developers for any breaking changes in C api, assuming there would be someone interested in maintaining rust part of things.
I like how this change was done with no excess drama and that Christoph is continuing to stay involved with Linux. This could be a break for the controversy to cool down and the developers to get back to developing.
Because no one cared enough to write them. The Rust people started their work years ago and have a lot of people interested in doing it. You know, the same as how it’s always worked.
I've yet to see a CoC used for good (sample bias I know). You don't need a CoC to ban and remove fuck sticks from your spaces. But you do need one if you want to ban someone who crime was doing something you found offensive. Offensive here is doing a lot of heavy lifting. I don't mean something actually objectionable, I mean something manufactured, where it's reasonable and worthy of a friendly conversation when you assume good faith, or something that's barely enough to trigger some part of the CoC to be used as a weapon. CoC give unfair power to people who want to be offended, and want to choose to assume bad faith, and abuse people they disagree with.
Yes, CoC as they commonly exist are bad because they're a net negatively tool that can be abused.
I don't apply that to all of them, I have a back burner idea to write one that can't be abused in the same way the popular and ambiguously written ones are. The primary issue is because they're written to be ambiguous so they can catch edge cases, and curated behavior intended to evade a more specific CoC. But that's not hard to fix. If you want your CoC to be fair, and just. It needs to have rules to prevent a single person from strongarming, and using it against an individual. It needs to have explicit tests and requirements for any fact finder to prove a violation, and demand a clear rational. One of these tests could easily be a pattern of behavior, and a finding this behavior is more likely to be designed specifically to evade this CoC than organic behavior, and that can serve as a single reason to implement a response. None of the ones I've read try to put the accusers on a fair rhetorical field as their targets. they're all written as if they they would never be abused by someone in bad faith, but that's not the reality we live in. Too many people enjoy pretending to be the victim, while actually being the bully.
But in the same way regulatory capture turns our governments against our best interests... CoCs sometimes get weaponized, empowering voices that wouldn't otherwise have a leg to stand on in terms of a meritocracy.
But yes, corporations are interested in it too, and they're willing to invest in a bunch of young(er) talented developers to get the work done. There's nothing untoward in factoring the labor market into your decision making process. Which also explains why Ada is NOT in the kernel (apart from the fact that Linus simply dislikes Ada)
Why does a CoC have anything do do with a maintainer stepping down due to a technical disagreement?
And the way you word it makes it seem like you think CoCs are bad or “forced”; I don’t particularly want to engage there, but I’d encourage you to reflect on why you think that.
> What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code? That's _literally_ exactly what you are trying to do with the Rust code.
Linus did the right thing eventually and spoke up