The general attitude around R4L is that it’s largely unneeded and for every 1 person actively working against the project, there are 10 saying either “waiting and seeing if it works is the right decision” or “if rust is so good they should prove it.”
So as a R4L developer you’re expected by the community to fight an uphill battle with basically no support on your side.
We will likely keep having developers on that project continue to burn out and leave until the entire thing collapses unless the decision is made ahead of time to cancel the project.
Every time I read any news about Rust for Linux I leave disappointed by the entire kernel community.
I am with you on that last line. However, I remain more hopeful.
As long as Linus keeps merging code, Rust will eventually win. And by win I just mean that it will overcome the haters sufficiently to render their resistance futile.
There is only so much support infrastructure needed before large chunks of Rust can be committed ( at least on the driver side ). We are not so far away from that. Once real code starts to appear the “show me” will drive adoption elsewhere.
Take this case, it all started over a bit of code. The subsystem maintainer refuses to take it. But it does not require any changes to existing code. It just has to be merged.
Linus can take it directly. If he does that, the Rust folks can start to use it. The sub-system maintainer will lose in the end.
At some point, the battle will be lost by those trying to block Rust.
Take this case, it all started over a bit of code. The subsystem maintainer refuses to take it. But it does not require any changes to existing code. It just has to be merged.
Linus can take it directly. If he does that, the Rust folks can start to use it. The sub-system maintainer will lose in the end.
At some point, the battle will be lost by those trying to block Rust.
It all depends on Linus. We will see.
Linus hasn’t been merging the necessary code, by virtue of supporting a maintainer who was very obviously trying to sabotage R4L; if Linus was going to stand up for R4L, this would have been the time.
What code has he not merged? Was his argument technical or political?
I see lots of R4L code being merged in each of the last few releases.
I also do not see the email where Linus supported Christoph. I see the one where he chewed out Hector for “social media brigading”. That is not the same thing as supporting the maintainer. Hector is not even the one submitting the Rust code in question. He just piled on in the LKML later.
By saying that Hector is the problem, he’s implicitly saying that Christoph is not the problem. By saying that the current process works–the very same process that just prevented R4L from submitting patches to the kernel, he’s implicitly endorsing Christoph’s actions.
Perhaps. That is not my read. I hear Linus saying that he trusts the process and that sticking with it is the solution to working through the problem. He does not say that a maintainer blocking a technically sound patch is a problem. He does not say that he would reject the patch. He does say that the approach taken by Hector ( who is not the one that submitted the patch ) is the wrong one. If Linus had said that the technical approach or the code quality was a problem, I would agree with you. He did not object to either of those things. What he said is that social media is not the solution.
The problem with your timeline is that it completely leaves out the event(s) that Linus is objecting to. I am hoping that is unintentional on your part.
I will know what Linus thinks when he either accepts or rejects the submission from the R4L team.
If that does happen, I just hope there will be enough developers by then that can/will want to use it (as in, write rust code). Especially developers that can put up with the kernel process and its people.
Fair point. I do think burn out is a problem for the process in general. I guess Linux has always benefited from the long line of people looking to contribute. As long as progress is being made, I expect that to continue here.
I’m not surprised by this.
The general attitude around R4L is that it’s largely unneeded and for every 1 person actively working against the project, there are 10 saying either “waiting and seeing if it works is the right decision” or “if rust is so good they should prove it.”
So as a R4L developer you’re expected by the community to fight an uphill battle with basically no support on your side.
We will likely keep having developers on that project continue to burn out and leave until the entire thing collapses unless the decision is made ahead of time to cancel the project.
Every time I read any news about Rust for Linux I leave disappointed by the entire kernel community.
I am with you on that last line. However, I remain more hopeful.
As long as Linus keeps merging code, Rust will eventually win. And by win I just mean that it will overcome the haters sufficiently to render their resistance futile.
There is only so much support infrastructure needed before large chunks of Rust can be committed ( at least on the driver side ). We are not so far away from that. Once real code starts to appear the “show me” will drive adoption elsewhere.
Take this case, it all started over a bit of code. The subsystem maintainer refuses to take it. But it does not require any changes to existing code. It just has to be merged.
Linus can take it directly. If he does that, the Rust folks can start to use it. The sub-system maintainer will lose in the end.
At some point, the battle will be lost by those trying to block Rust.
It all depends on Linus. We will see.
Linus hasn’t been merging the necessary code, by virtue of supporting a maintainer who was very obviously trying to sabotage R4L; if Linus was going to stand up for R4L, this would have been the time.
What code has he not merged? Was his argument technical or political?
I see lots of R4L code being merged in each of the last few releases.
I also do not see the email where Linus supported Christoph. I see the one where he chewed out Hector for “social media brigading”. That is not the same thing as supporting the maintainer. Hector is not even the one submitting the Rust code in question. He just piled on in the LKML later.
The boiled down summary is:
Abdiel Janulgue submits the patch to Christoph Hellwig
Christoph rejects the patch because he doesn’t want to maintain it
Danilo Krummrich offers to maintain it
Christoph says no and that he “will do everything [he] can do to stop [Rust support from being added to the DMA subsystem]”
Hector Martin adds Linus and says “If Linus doesn’t pipe up with an authoritative answer to this thread, Miguel and the other Rust folks should just merge this series once it is reviewed and ready, ignoring Christoph’s overt attempt at sabotaging the project.”
Linus says “How about you accept the fact that maybe the problem is you. You think you know better. But the current process works.”
By saying that Hector is the problem, he’s implicitly saying that Christoph is not the problem. By saying that the current process works–the very same process that just prevented R4L from submitting patches to the kernel, he’s implicitly endorsing Christoph’s actions.
Perhaps. That is not my read. I hear Linus saying that he trusts the process and that sticking with it is the solution to working through the problem. He does not say that a maintainer blocking a technically sound patch is a problem. He does not say that he would reject the patch. He does say that the approach taken by Hector ( who is not the one that submitted the patch ) is the wrong one. If Linus had said that the technical approach or the code quality was a problem, I would agree with you. He did not object to either of those things. What he said is that social media is not the solution.
The problem with your timeline is that it completely leaves out the event(s) that Linus is objecting to. I am hoping that is unintentional on your part.
I will know what Linus thinks when he either accepts or rejects the submission from the R4L team.
I didn’t include the social media “brigading” portion because Linus already addressed that in a different sub-thread.
If that does happen, I just hope there will be enough developers by then that can/will want to use it (as in, write rust code). Especially developers that can put up with the kernel process and its people.
Fair point. I do think burn out is a problem for the process in general. I guess Linux has always benefited from the long line of people looking to contribute. As long as progress is being made, I expect that to continue here.