8 ms·

If an individual maintainer can veto critical parts of the Rust for Linux project and announce they'll do everything they can to stop it, then Linus is wasting

If an individual maintainer can veto critical parts of the Rust for Linux project and announce they'll do everything they can to stop it, then Linus is wasting everyone else's time pretending it's a real project. It's not a proper environment to put contributors in.

sgt 2y ago
Give him time, Linus will reach out soon regarding Rust.
- Tomte 2y ago
  He has at least said this to Martin: "How about you accept the fact that maybe the problem is you." (https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...) I wouldn‘t expect a grand Rust announcement anytime soon, above what has already been said. Rust in the kernel seems to be fine, but it will have to adapt to longstanding kernel processes. And if it means there won‘t be Rust in some maintainers‘ subsystems, so be it. The kernel won‘t be 100% Rust next year anyway.
  - Dalewyn 2y ago
    I've conversed with marcan a few times (on completely unrelated and inconsequential things). As far as I know he's a decent man. That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.
    - rcxdude 2y ago
      Indeed, but where is the 'real' solution? If no-one higher up is going to step in and merge the patches despite the blocking maintainer, how is "the process" going to move R4L forward? (Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)
      - chippiewill 2y ago
        They can merge regardless. The maintainer nacked something they don't even own, they were asked for a review as a courtesy as it wraps their subsystem. That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.
      - pas 2y ago
        Sometimes there's no win-win-win solution. I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.
        sgt 2y ago
        > "I think people who write C should stop unless it's to fix security bugs and should do something else" That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though. And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?
        pas 2y ago
        Of course, internal combustion engine motorcycles too, but I hate the aggressively noisy noxious little shits whizzing around my code, I mean, me. :) ... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security. And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status. But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one. https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st/ https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98... https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-... If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)
    - deleted 2y ago
      [deleted]
jeroenhd 2y ago
I think it's rather silly to have some subsystem maintainers do everything in their power to sabotage the improvement projects by subsystem and even high level maintainers in the kernel. It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers. This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything. That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.
- Longhanks 2y ago
  > This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything. Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit. Luckily, the kernel seems to be doing fine.
  - tedivm 2y ago
    The kernel is doing fine today, but I don't think that's sustainable. The average age of the maintainers seems to be rising, and plenty of skilled people completely avoid kernel development explicitly because of the hostility and, frankly, assholish behavior that comes from the folks on these mailing lists. Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.
    - 2y ago
nicce 2y ago
That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area. About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.
- Dr_Emann 2y ago
  "The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/ https://lwn.net/ml/all/20250204052916.GA28741@lst.de/ That doesn't sound like he's only talking about in his area to me
  - bjord 2y ago
    is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?
    - naasking 2y ago
      Maintainers come and go, languages come and go. C will never go away and everyone working on kernels knows C, so there's a certain labour pool and skillset that will always be available that doesn't necessarily apply to Rust. That's even setting aside any technical issues, like bugs creeping up in the language interoperability layer, which obviously doesn't really happen if you're only using one compiler.
      - ChocolateGod 2y ago
        I think both arguments have credibility. The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team. Meanwhile, everyone involved in development for Linux already knows C.
noirscape 2y ago
He couldn't veto it anyway; by reading the entire thread, you'll see that the maintainer NACKed the request. After that, Greg KH stepped in (since he was soft asked to help earlier in the thread with an @) to reconfirm that what seems to be the general policy for r4l is followed (aka it'll be a separate file with its own maintainer), with the subtle implication that it would probably just get merged as a separate patch to Linus directly, the complaints of the maintainer be damned. Marcan's sudden outburst and forcibly adding Linus and Greg to the thread he was responding to came afterwards. You can even see some other rust4linux devs asking him to please not do this, since the situation is under control.
- gpm 2y ago
  Put yourself in the shoes of the person submitting this patch. Is a "subtle implication" (and to be clear, it was a very subtle one if it was one at all) that a senior maintainers NAK on a patch is going to be ignored enough to make the whole situation not incredibly demoralizing? Does it do much of anything to solve the fact they've publicly declared that they are going to do everything they can to stop the project, and that there's a history of them doing just that going on for years now? Marcan's response clearly wasn't the most productive way to raise these issues, but the issues are there and are not being addressed.
  - noirscape 2y ago
    To me the implication isn't subtle; the maintainer NACKs, the response from someone on the contributing team is "maybe we should involve @Linus or @Greg" and from that point on, you see Greg KH get involved to note what the proper procedure is and to ensure that it'll be followed. Hellwig is completely sidelined from that point onwards, minus some grumbling noise on his side. Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder). Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).
7e 2y ago
[flagged]
znpy 2y ago
I think the core of the issue is expecting people to agree with stuff. Linux is free software and there's really nobody stopping people from forking it and doing things the way they want. It used to happen all the time once upon a time, nowadays people seems to be afraid of doing it.
- bitbasher 2y ago
  The kernel is nearly 30 million lines of code. I would love to see a fork where Rust starts taking over sections of it, but that's a huge undertaking that would clearly take many years.
  - znpy 2y ago
    Yep, either people are willing to do the fork and take the challenge or they accept that nobody has to be forced to accept their opinions and contributions, good or not.
- n144q 2y ago
  I can easily fork your project with 1k lines of code, but not Linux kernel and stay up-to-date with all the latest commits. Nobody can.
  - gkbrk 2y ago
    Why would a Rust for Linux fork want to stay up-to-date with all the latest commits that are in C? If all the latest commits in C are so useful, even to a Rust fork, perhaps the Linux C devs are not off-base that Rust isn't worth it for now.

sgt 2y ago

Give him time, Linus will reach out soon regarding Rust.

Tomte 2y ago
He has at least said this to Martin: "How about you accept the fact that maybe the problem is you." (https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...) I wouldn‘t expect a grand Rust announcement anytime soon, above what has already been said. Rust in the kernel seems to be fine, but it will have to adapt to longstanding kernel processes. And if it means there won‘t be Rust in some maintainers‘ subsystems, so be it. The kernel won‘t be 100% Rust next year anyway.
- Dalewyn 2y ago
  I've conversed with marcan a few times (on completely unrelated and inconsequential things). As far as I know he's a decent man. That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.
  - rcxdude 2y ago
    Indeed, but where is the 'real' solution? If no-one higher up is going to step in and merge the patches despite the blocking maintainer, how is "the process" going to move R4L forward? (Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)
    - chippiewill 2y ago
      They can merge regardless. The maintainer nacked something they don't even own, they were asked for a review as a courtesy as it wraps their subsystem. That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.
    - pas 2y ago
      Sometimes there's no win-win-win solution. I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.
      - sgt 2y ago
        > "I think people who write C should stop unless it's to fix security bugs and should do something else" That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though. And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?
        pas 2y ago
        Of course, internal combustion engine motorcycles too, but I hate the aggressively noisy noxious little shits whizzing around my code, I mean, me. :) ... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security. And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status. But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one. https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st/ https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98... https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-... If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)
  - deleted 2y ago
    [deleted]

jeroenhd 2y ago

I think it's rather silly to have some subsystem maintainers do everything in their power to sabotage the improvement projects by subsystem and even high level maintainers in the kernel. It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers. This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything. That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.

Longhanks 2y ago
> This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything. Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit. Luckily, the kernel seems to be doing fine.
- tedivm 2y ago
  The kernel is doing fine today, but I don't think that's sustainable. The average age of the maintainers seems to be rising, and plenty of skilled people completely avoid kernel development explicitly because of the hostility and, frankly, assholish behavior that comes from the folks on these mailing lists. Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.
  - 2y ago

nicce 2y ago

That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area. About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.

Dr_Emann 2y ago
"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/ https://lwn.net/ml/all/20250204052916.GA28741@lst.de/ That doesn't sound like he's only talking about in his area to me
- bjord 2y ago
  is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?
  - naasking 2y ago
    Maintainers come and go, languages come and go. C will never go away and everyone working on kernels knows C, so there's a certain labour pool and skillset that will always be available that doesn't necessarily apply to Rust. That's even setting aside any technical issues, like bugs creeping up in the language interoperability layer, which obviously doesn't really happen if you're only using one compiler.
    - ChocolateGod 2y ago
      I think both arguments have credibility. The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team. Meanwhile, everyone involved in development for Linux already knows C.

noirscape 2y ago

He couldn't veto it anyway; by reading the entire thread, you'll see that the maintainer NACKed the request. After that, Greg KH stepped in (since he was soft asked to help earlier in the thread with an @) to reconfirm that what seems to be the general policy for r4l is followed (aka it'll be a separate file with its own maintainer), with the subtle implication that it would probably just get merged as a separate patch to Linus directly, the complaints of the maintainer be damned. Marcan's sudden outburst and forcibly adding Linus and Greg to the thread he was responding to came afterwards. You can even see some other rust4linux devs asking him to please not do this, since the situation is under control.

gpm 2y ago
Put yourself in the shoes of the person submitting this patch. Is a "subtle implication" (and to be clear, it was a very subtle one if it was one at all) that a senior maintainers NAK on a patch is going to be ignored enough to make the whole situation not incredibly demoralizing? Does it do much of anything to solve the fact they've publicly declared that they are going to do everything they can to stop the project, and that there's a history of them doing just that going on for years now? Marcan's response clearly wasn't the most productive way to raise these issues, but the issues are there and are not being addressed.
- noirscape 2y ago
  To me the implication isn't subtle; the maintainer NACKs, the response from someone on the contributing team is "maybe we should involve @Linus or @Greg" and from that point on, you see Greg KH get involved to note what the proper procedure is and to ensure that it'll be followed. Hellwig is completely sidelined from that point onwards, minus some grumbling noise on his side. Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder). Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).

7e 2y ago

[flagged]

znpy 2y ago

I think the core of the issue is expecting people to agree with stuff. Linux is free software and there's really nobody stopping people from forking it and doing things the way they want. It used to happen all the time once upon a time, nowadays people seems to be afraid of doing it.

bitbasher 2y ago
The kernel is nearly 30 million lines of code. I would love to see a fork where Rust starts taking over sections of it, but that's a huge undertaking that would clearly take many years.
- znpy 2y ago
  Yep, either people are willing to do the fork and take the challenge or they accept that nobody has to be forced to accept their opinions and contributions, good or not.
n144q 2y ago
I can easily fork your project with 1k lines of code, but not Linux kernel and stay up-to-date with all the latest commits. Nobody can.
- gkbrk 2y ago
  Why would a Rust for Linux fork want to stay up-to-date with all the latest commits that are in C? If all the latest commits in C are so useful, even to a Rust fork, perhaps the Linux C devs are not off-base that Rust isn't worth it for now.