I’m not sure why they feel it’s Linus’ responsibility to make Rust happen in the kernel. I’m certainly not happy someone is being harassed, but none of this is the fault of the Linux Foundation or the people that have been working on the kernel for decades.
If Rust is going to happen, then it’ll happen. Or fork it and make a Rust Linux with blackjack and hookers, and boy, will everyone left behind feel silly that they didn’t jump on the bandwagon. But nobody has to make your dreams their focus or even interact with it if they don’t want to. And these social media outbursts aren’t accomplishing what they think they’re accomplishing.
I’m not sure why they feel it’s Linus’ responsibility to make Rust happen in the kernel.
That’s not what’s being said here, as far as I can tell. Linus is not expected to somehow “make Rust happen”. But as a leader, he is expected to call out maintainers who block the R4L project and harass its members just because they feel like it. Christoph Hellwig’s behavior should not be allowed.
I’m not saying Marcan is necessarily correct, to be clear. It might well be that Linus chose to handle the issue in a quieter way. We can’t know whether Linus was planning on some kind of action that didn’t involve him jumping into the middle of the mailing list fight, eg contacting Christoph Hellwig privately. I’m merely pointing out that maybe you misunderstood what Marcan is saying.
Or fork it and make a Rust Linux with blackjack and hookers, and boy, will everyone left behind feel silly that they didn’t jump on the bandwagon.
That’s what they’re doing. But if you read the entire post carefully, he explains why maintaining a fork without eventually upstreaming it is problematic. And it’s not like they’re forcing their dream on the linux project, because the discussions have already been had and rust has officially been accepted into the kernel. So in the wider context, this is about individual maintainers causing friction against an agreed-upon project they don’t like.
Thing is, there is already Rust in Linux, and Torvalds wants more, faster. He’s being sabotaged by C purists, who at this point should stop acting unprofessionally, or at the very least make their own “only C” fork if they disagree with his leadership so much.
And these social media outbursts aren’t accomplishing what they think they’re accomplishing.
I’m extremely technical, but not actively into Linux, though I’ve set up various distros dozens up times. These posts have driven me away from Linux in an extremely hard way - anyone with opinions like the Kernel team simply don’t deserve support, and Linus is clearly past his prime and making bad decisions. This has shown me that Linux is going to (likely already has) slowly stop improving due to its explicitly anti-progress leadership. Until a fork with good leaders manages to take a real market share, the OS will stagnate.
I’m sure this is a minority opinion, but to claim that the social media blitz hasn’t had its intended effect is objectively false. Fuck the kernel team.
Linus is pro-Rust. It is not clear from what you wrote that you realize that. He has merged plenty of Rust code. I personally expect him to merge the change that caused all this current drama (though I could clearly be wrong about that).
Right or wrong, this is how Linux kernel dev has always worked. How long did it take for real time to get in? How smoothly is the bcachefs merge going? Have you read any of the GPU driver chatter?
Honestly though, it is not just the kernel. How much different is the Wayland scene?
I am hardly defending Linux here by the way. I think the maintainers are blocking progress. I am merely pointing out that it is hardly new or unique.
Anyway, RedoxOS is quite progressive. They would probably love help from anybody that finds Linux kernel dev too stodgy.
How can it happen if individual maintainers say they’ll do everything in their power to keep Rust out of the kernel? There’s fundamentally no way forward. The R4L devs already gave every commitment they could, but some maintainers fundamentally don’t want it.
And before anyone brings it up: no, the maintainers weren’t asked to touch Rust code or not break Rust code or anything else.
Fact is Rust isn’t ready for every part of the kernel. C/Rust interop is still a growing pain for Linux and troubleshooting issues at the boundary require a developer to be good at both. It’s an uphill battle, and instead of inciting flame wars they could have fostered cooperation around the parts of the kernel that were more prepared. While their work is appreciated and they are incredibly talented, the reality is that social pressures are going to dictate development. At the end of the day software is used by people. Their expectations are not law, but they do need addressed to preserve public opinion.
Again: what cooperation is possible when the maintainer says “I’ll do everything in my power to keep Rust out of the kernel”? When they NACK a patch outside of their Subsystem?
I accept that you don’t want to be involved with Rust in the kernel, which is
why we offered to maintain the Rust abstraction layer for the DMA coherent
allocator as a separate component (which it would be anyways) ourselves.
Which doesn’t help me a bit. Every additional bit that the another
language creeps in drastically reduces the maintainability of the kernel
as an integrated project. The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this. You might not like my answer, but I will do
everything I can do to stop this.
Can a maintainer really NACK any patch they dislike? I mean I get that Hellwig said he won’t merge it. Fine. What if for example Kroah-Hartman says “whatever, I like it” and merges it nonetheless in his tree?
It was an example. I don’t have a fucking clue how all the maintainers are named.
The main question was: why can a maintainer NACK something not in their responsibility? Isn’t it simply necessary to find one maintainer who is fine with it and pulls it in?
Or even asked differently: shouldn’t you need to find someone who ACKs it rather than caring about who NACKs it?
Let me just say that hierarchies are for breaking ties.
The normal process is that Linus prefers we all work through maintainers to cut down on the noise that comes to him. In this case, the maintainer is the reason the noise is coming to Linus. So, it will be up to him to settle it.
Yes, but asking him in this case was basically a courtesy, the code isn’t going into anything he manages. He can reject it, but that’s an opinion, not a decision. It can still be merged if the regular maintainer (or someone senior like Linus himself) approves.
why they feel it’s Linus’ responsibility to make Rust happen in the kernel
who does? are you talking about marcan? because as far as i can see, what they’re asking for is for linus to make a stance and actually say whether R4L is a thing they want or not. because linus’ attitude so far has been “let’s wait and see” which hasn’t been all that helpful, as said in the blog post.
Ultimately Linus’ opinion here does not matter in the positive. He can say Rust in kernel is good, but that does not summon the skill and work to make it happen. He can say it’s bad and quash it, at the potential expense of Linux’s future. His position of avoiding an extreme is a pragmatic one. “Let them come if they may, and if they do not it was less a loss for us.”
see, i could maybe agree with this if it weren’t for the amazing work from R4L that already has been and continues to be done, despite subsystems maintainers putting their foot down and going “Not In My Back Yard, bucko!”. how many more maintainers does R4L have to lose before Linus realizes he might need to take a stance as a project lead?
Linus can merge whatever patches he wants to, and the stonewalling subsystem maintainers would have to deal with it–like he did with the eBPF scheduler. R4L maintainers already wrote the patches, they literally just needed to be merged.
I’m not placing blame on the Linux Foundation, Linus, or anyone else for that matter. However, I believe that if Linus has publicly endorsed the use of Rust in the kernel, that decision is already largely set in motion. On the other hand, if the community collectively opposes the integration of Rust with C and no action is taken to address these problems, and everyone say no, then there is little to no reason to make the initial statement.
Much of the work being produced by Rust developers seems to struggle, often because it’s not made in C and because of maintainers saying “No I don’t want any rust code near my C code”.
I recognize that there are various technical factors influencing this decision, but ultimately it was the creator’s choice to support it.
Isn’t it reasonable for a maintainer to say “no rust here” when they don’t know rust, don’t want to learn it, and have decades of experience in C, and are maintaining that part of the system
The project has said it is a goal to move to a dual language model. So, no, it is not reasonable.
What would be reasonable would be technical arguments or pragmatic logistical concerns with the goal of finding solutions. What would be reasonable would be asking for and accepting help.
None of the reasonable stuff is happening. So, it not reasonable.
It’s also his legitimate choice to wait. He can’t see the best way forward and is deciding to wait on his decission or let the community decide instead of him. As much as we like to think of him as autocrat in some way, he respects people that work on kernel and he respects their time. The smartest move is often to wait on a decision. And even if it’s not a smartest move in this case, it can still be better than making a wrong decission that will demoralize the community even more.
I’m not sure why they feel it’s Linus’ responsibility to make Rust happen in the kernel. I’m certainly not happy someone is being harassed, but none of this is the fault of the Linux Foundation or the people that have been working on the kernel for decades.
If Rust is going to happen, then it’ll happen. Or fork it and make a Rust Linux with blackjack and hookers, and boy, will everyone left behind feel silly that they didn’t jump on the bandwagon. But nobody has to make your dreams their focus or even interact with it if they don’t want to. And these social media outbursts aren’t accomplishing what they think they’re accomplishing.
That’s not what’s being said here, as far as I can tell. Linus is not expected to somehow “make Rust happen”. But as a leader, he is expected to call out maintainers who block the R4L project and harass its members just because they feel like it. Christoph Hellwig’s behavior should not be allowed.
I’m not saying Marcan is necessarily correct, to be clear. It might well be that Linus chose to handle the issue in a quieter way. We can’t know whether Linus was planning on some kind of action that didn’t involve him jumping into the middle of the mailing list fight, eg contacting Christoph Hellwig privately. I’m merely pointing out that maybe you misunderstood what Marcan is saying.
That’s what they’re doing. But if you read the entire post carefully, he explains why maintaining a fork without eventually upstreaming it is problematic. And it’s not like they’re forcing their dream on the linux project, because the discussions have already been had and rust has officially been accepted into the kernel. So in the wider context, this is about individual maintainers causing friction against an agreed-upon project they don’t like.
Thing is, there is already Rust in Linux, and Torvalds wants more, faster. He’s being sabotaged by C purists, who at this point should stop acting unprofessionally, or at the very least make their own “only C” fork if they disagree with his leadership so much.
I’m extremely technical, but not actively into Linux, though I’ve set up various distros dozens up times. These posts have driven me away from Linux in an extremely hard way - anyone with opinions like the Kernel team simply don’t deserve support, and Linus is clearly past his prime and making bad decisions. This has shown me that Linux is going to (likely already has) slowly stop improving due to its explicitly anti-progress leadership. Until a fork with good leaders manages to take a real market share, the OS will stagnate.
I’m sure this is a minority opinion, but to claim that the social media blitz hasn’t had its intended effect is objectively false. Fuck the kernel team.
Linus is pro-Rust. It is not clear from what you wrote that you realize that. He has merged plenty of Rust code. I personally expect him to merge the change that caused all this current drama (though I could clearly be wrong about that).
Right or wrong, this is how Linux kernel dev has always worked. How long did it take for real time to get in? How smoothly is the bcachefs merge going? Have you read any of the GPU driver chatter?
Honestly though, it is not just the kernel. How much different is the Wayland scene?
I am hardly defending Linux here by the way. I think the maintainers are blocking progress. I am merely pointing out that it is hardly new or unique.
Anyway, RedoxOS is quite progressive. They would probably love help from anybody that finds Linux kernel dev too stodgy.
deleted by creator
How can it happen if individual maintainers say they’ll do everything in their power to keep Rust out of the kernel? There’s fundamentally no way forward. The R4L devs already gave every commitment they could, but some maintainers fundamentally don’t want it.
And before anyone brings it up: no, the maintainers weren’t asked to touch Rust code or not break Rust code or anything else.
Fact is Rust isn’t ready for every part of the kernel. C/Rust interop is still a growing pain for Linux and troubleshooting issues at the boundary require a developer to be good at both. It’s an uphill battle, and instead of inciting flame wars they could have fostered cooperation around the parts of the kernel that were more prepared. While their work is appreciated and they are incredibly talented, the reality is that social pressures are going to dictate development. At the end of the day software is used by people. Their expectations are not law, but they do need addressed to preserve public opinion.
Again: what cooperation is possible when the maintainer says “I’ll do everything in my power to keep Rust out of the kernel”? When they NACK a patch outside of their Subsystem?
Removed by mod
Sure: https://lore.kernel.org/rust-for-linux/20250131075751.GA16720@lst.de/
Can’t get more explicit than this.
Can a maintainer really NACK any patch they dislike? I mean I get that Hellwig said he won’t merge it. Fine. What if for example Kroah-Hartman says “whatever, I like it” and merges it nonetheless in his tree?
I doubt Greg is pulling in Rust until it has been through the mainline. That said, Linus can merge anything he wants.
It was an example. I don’t have a fucking clue how all the maintainers are named.
The main question was: why can a maintainer NACK something not in their responsibility? Isn’t it simply necessary to find one maintainer who is fine with it and pulls it in?
Or even asked differently: shouldn’t you need to find someone who ACKs it rather than caring about who NACKs it?
Let me just say that hierarchies are for breaking ties.
The normal process is that Linus prefers we all work through maintainers to cut down on the noise that comes to him. In this case, the maintainer is the reason the noise is coming to Linus. So, it will be up to him to settle it.
Yes, but asking him in this case was basically a courtesy, the code isn’t going into anything he manages. He can reject it, but that’s an opinion, not a decision. It can still be merged if the regular maintainer (or someone senior like Linus himself) approves.
who does? are you talking about marcan? because as far as i can see, what they’re asking for is for linus to make a stance and actually say whether R4L is a thing they want or not. because linus’ attitude so far has been “let’s wait and see” which hasn’t been all that helpful, as said in the blog post.
“Let’s wait and C”.
aughhhhhh here’s your upvote. git out.
Ultimately Linus’ opinion here does not matter in the positive. He can say Rust in kernel is good, but that does not summon the skill and work to make it happen. He can say it’s bad and quash it, at the potential expense of Linux’s future. His position of avoiding an extreme is a pragmatic one. “Let them come if they may, and if they do not it was less a loss for us.”
see, i could maybe agree with this if it weren’t for the amazing work from R4L that already has been and continues to be done, despite subsystems maintainers putting their foot down and going “Not In My Back Yard, bucko!”. how many more maintainers does R4L have to lose before Linus realizes he might need to take a stance as a project lead?
Linus can merge whatever patches he wants to, and the stonewalling subsystem maintainers would have to deal with it–like he did with the eBPF scheduler. R4L maintainers already wrote the patches, they literally just needed to be merged.
I’m not placing blame on the Linux Foundation, Linus, or anyone else for that matter. However, I believe that if Linus has publicly endorsed the use of Rust in the kernel, that decision is already largely set in motion. On the other hand, if the community collectively opposes the integration of Rust with C and no action is taken to address these problems, and everyone say no, then there is little to no reason to make the initial statement.
Much of the work being produced by Rust developers seems to struggle, often because it’s not made in C and because of maintainers saying “No I don’t want any rust code near my C code”.
I recognize that there are various technical factors influencing this decision, but ultimately it was the creator’s choice to support it.
Isn’t it reasonable for a maintainer to say “no rust here” when they don’t know rust, don’t want to learn it, and have decades of experience in C, and are maintaining that part of the system
Yes.
But that’s not what’s happening here. The guy who said no is not the maintainer of the rust code, and is not expected to touch the rust code at all.
The project has said it is a goal to move to a dual language model. So, no, it is not reasonable.
What would be reasonable would be technical arguments or pragmatic logistical concerns with the goal of finding solutions. What would be reasonable would be asking for and accepting help.
None of the reasonable stuff is happening. So, it not reasonable.
It’s also his legitimate choice to wait. He can’t see the best way forward and is deciding to wait on his decission or let the community decide instead of him. As much as we like to think of him as autocrat in some way, he respects people that work on kernel and he respects their time. The smartest move is often to wait on a decision. And even if it’s not a smartest move in this case, it can still be better than making a wrong decission that will demoralize the community even more.