[tssva]

"To interpret it differently requires bending the mind."

Stange, I think interpreting it your way requires bending the mind. Hellwig clearly used it to describe what he sees at the ill effects of multiple languages in the kernel. It was not used to describe either Rust the language or this specifically this particular submission.

[Vegenoid]

> And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).

It was used to describe the Rust for Linux project, as well as any other potential efforts to bring other languages into the kernel, of which there are none. It is clear why someone working on the Rust for Linux project would feel that "this cancer" refers to the project that they are working on.

I'm not trying to pull out pitchforks, I don't want anyone to burn. I just want people to collaborate effectively and be happy, and I think it is empirically clear that calling something that grows/spreads and that you think is bad "cancer" is not useful, and only inflames things. It is not an illuminating metaphor.

[markchuk]

I agree with Vegenoid that using diseases for labeling poorly written code is at the very least highly unprofessional. This practice not only diminishes the seriousness of illnesses like cancer when used so casually, but it also cannot provide helpful constructive feedback.

Instead of providing helpful advice like outlining the current situation and suggesting specific improvements (action A, task B, and goal C) to reach the goal, it feels rude and offensive.

[Brian_K_White]

There is no specific improvement if the problem is fundamental. There is no "better/right" way to spread a cancer. (I'm not saying it is, just that that is the argument, and in that context, there is no such thing as a common goal to reach some better way. Everyone does not actually have to agree that all goals are valid and should be reached.)

The only helpful advice, which they did give, is don't even start doing this because it's fundamentally wrong.

The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?

I don't see how he has any right to what he wants, and I don't see an existing kernel devs refusal to cooperate, or even entertain cooperating, as automatically wrong or unreasonable.

[MrJohz]

> The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?

While I think this a dumb metaphor, it's also incorrect in this context. The Linux kernel explicitly supports C and Rust code, and there are very clear parameters to allow for Rust code to be integrated into parts of the kernel.

Or in other words, the decision has already been made to allow meat into the vegan household, and now one maintainer is explicitly blocking a package of meat from entering the building, even though it has already been decided from on high that meat should be allowed in.

This isn't quite accurate, though, because of the unnecessary metaphor thing. Reading the original mailing list chain all the way through and talking about these events directly is completely sufficient here. The patch was reasonable within the parameters set out for the R4L project. The maintainer of this subsystem blocked it explicitly because they disagree with the idea of R4L in general (calling it a cancer).

The question is not whether or not R4L is a good thing or a bad thing - anyone can have their own opinion on that. R4L is part of Linux, and will be for the foreseeable future, until it either clearly demonstrates its use, or clearly demonstrates its failure. The question (at least as regards the "cancer" comment) is whether it is okay for a maintainer to describe another team's work as cancer, and to publicly block it as much as they can.

[Brian_K_White]

Of course it's ok to block something they judge to be harmful as much as they can. That is their explicit job as maintainer is to make exactly that type of judgement.

If they are overstepping, then Linus will make that known. Until then, apparently they are not overstepping.

And he can use that image if it communicates the concept he wants to communicate.

It sounds like a valid image to me to apply to the concept of polyglot.

He is saying that "If there is really no way for a rust driver to exist all by itself without any of the c code having to do anything special to accomodate it, then so be it, I guess rust doesn't fit here after all."

rust devs are saying "you're not even helping a tiny bit!". I am saying, no, they're not, so what? They don't have to. They did not request what rust devs are trying to do.

The concession rust devs got to proceed to attempt to use rust in the kernel at all doesn't promise almost anything beyond "well you can try". It does not promise to facilitate that try at all really.

[steveklabnik]

No, the rust devs are saying “you do not need to accommodate” and he’s saying “I say no anyway.”

[Brian_K_White]

It's like the trope of the hyper emotional significant other that turns practically any statement into "You just called me a dog!!??".