4 ms·

If you watch that YouTube link, you'll see the same guy Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust". I thi

If you watch that YouTube link, you'll see the same guy Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust". I think he apologised for this flagrant comment, but this email shows he hasn't changed his behaviour in the slightest.

uecker 2y ago
His email seems very reasonable to me (the thin-blue-line comment is a bit weird though). To me the problem are that some Rust people seem to expect that the Linux maintainers (that put in a tremendous amount of work) just have to go out of their way to help them achieve their goals - even if the maintainers are not themselves convinced about it and later have to carry the burden.
- Ar-Curunir 2y ago
  How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.
  - uecker 2y ago
    I don't think it is this simple.
  - afr0ck 2y ago
    This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.
    - dralley 2y ago
      At some level this is just concern trolling. There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just expressed. You are asking for something that is impossible. What could they possibly "deliver" beyond a strong commitment to fix the code in a timely manner themselves?
      - tmoertel 2y ago
        > There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just exprssed. They could do exactly what Ted Ts'o suggested in his email [1] that Marcan cited: They could integrate more into the existing kernel-development community, contribute to Linux in general, not just in relation to their pet projects, and over time earn trust that, when they make promises with long time horizons, they can actually keep them. Because, if they can't keep those promises, whoever lets their code into the kernel ends up having to keep their promises for them. [1] https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...
        dralley 2y ago
        Many of them have, in fact, done all of those things, and have done them over a time horizon measured in years. Many of the R4L developers are paid by their employers specifically to work on R4L and can therefore be considered reasonably reliable and not drive-by contributors. Many existing maintainers are not "general contributors" It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do. Christoph refused to take onboard a new maintainer. The fight from last August was about subsystem devs refusing to document the precise semantics of their C APIs. These are signs of fief-building that would be equally dangerous to the long-term health of the project if Rust was not involved whatsoever.
        zifpanachr23 2y ago
        I disagree. If you want to provide technical leadership by massively changing the organization and tooling of a huge project that has been around a long time, it should be absolutely mandatory to spend years building trust and doing work that you don't want to do. That's just how programming on teams and trust and teamwork actually works in the real world. Especially on a deadly serious not-hobby project like the kernel. Sometimes you are gonna have to do work that doesn't excite you. That's life doing professional programming. Everything Ted Tso recommended is just common sense teamwork 101 stuff and it's just generally good advice for programmers in their careers. The inability of rust people to follow it will only hurt them and doom their desire to be accepted by larger more important projects in the long run. Programming on a team is a social affair and pretending you don't have to play by the rules because you have such great technical leadership is arrogant.
  - rc00 2y ago
    As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250131135421.GO5556... > Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not. > Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders". > It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build. For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?
    - chrsig 2y ago
      > For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads? Yes actually, I really wish someone would bring that sort of thing to the forefront, because that's a great spot to welcome new contributors.
  - toast0 2y ago
    As a non-interested observer; I think it will need to be said until the commitment becomes credible. I don't know how it would become credible, but it's clearly not considered credible by at least those of the kernel maintainers who are worried about the maintenance burden of accepting rust patches.
  - gkbrk 2y ago
    This is not what the "Rust kernel policy" [1] of Rust for Linux says. [1]: https://rust-for-linux.com/rust-kernel-policy https://rust-for-linux.com/rust-kernel-policy > Who is responsible if a C change breaks a build with Rust enabled? > The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust. > Didn't you promise Rust wouldn't be extra work for maintainers? > No, we did not. Since the very beginning, we acknowledged the costs and risks a second language introduces.
    - steveklabnik 2y ago
      You conveniently left out > However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.
      - gkbrk 2y ago
        Yes, "breakage should be fixed as soon as possible". Not "Rust for Linux team will fix the breakage as soon as possible". The exception is allowing the subsystem to break Rust code temporarily. If you accept a patch in C that breaks Rust code, and the Rust for Linux team doesn't fix it quickly enough, you either need to fix the Rust code yourself, remove it, or re-write it in C. All of this would take time and energy from all the non-R4L kernel devs. This is why people are reluctant to accept too much mixing of the C and Rust codebases, because even the Rust for Linux team isn't promising to fix breakages in Rust for Linux code.
        nindalf 2y ago
        Just to be clear, this is the situation. A rando submits a C patch that breaks Rust code, a maintainer accepts this patch and then demands that the R4L devs fix the breakage introduced by someone else and reviewed by themselves. The rando who broke the thing isn't around, and the person who reviewed the change takes no responsibility. Have I gotten that right? And then you're presenting this situation as "the Rust for Linux team isn't promising to fix breakages in Rust for Linux code". Somewhat disingenuous.
  - zifpanachr23 2y ago
    They've said that, but nobody believes them, and can you blame them given we JUST saw another big rust maintainer resign? I'd be suspicious these guys aren't in it for the long haul if they don't get their way and will leave the Rust they shoved in the kernel to bit rot if things don't go their way w.r.t enough rust adoption fast enough. "If you don't let us add even more rust, we will resign from the project and leave you to maintain the rust that's already there and that we added, and that you said you didn't want to add because you didn't trust us to not resign". Rust 4 Linux people just proving the points of the maintainers scared of abandonment. The rust 4 Linux people unfortunarely give the impression of caring more about rust than about the kernel, and it's clear that many are willing to make that perfectly clear by abandoning the larger project. The whole thing needs to be scrapped and rethought with better and more committed leadership. This past 6 months to a year has been embarrassing and done nothing but confirm the fears of anti rust people.
    - timeon 2y ago
      These people were quitting after being harassed. So I do not think you are arguing in good faith.
  - aragilar 2y ago
    That doesn't line with https://rust-for-linux.com/rust-kernel-policy#who-is-responsible-if-a-c-change-breaks-a-build-with-rust-enabled https://rust-for-linux.com/rust-kernel-policy#who-is-respons... (which may be a recent change?)
  - CRConrad 2y ago
    > the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. How have they "committed"? By saying they commit[1], I presume -- but what more? Anyone can say anything. I think what makes the "old guard" kernel maintainers nervous is the lack of a track record. And yes, I know that's a kind of a lifting-yourself-by-your-bootstraps problem. And no, I don't know of any solution to that. But I do know that, like baron Münchhausen, you can't ride your high horse around the swamp before you've pulled your self out of it. ___ [1]: And, as others in this thread have shown, that's apparently just out of one side of their collective mouth: The official "Rust kernel policy" says otherwise.
- vaxman 2y ago
  > "the thin-blue-line comment is a bit weird though" In US, "thin blue line" is a colloquialism for police officers who typically wear blue and "toe the line." You should not be downvoted/shadowbanned/abused for your post, IMHO.
ajross 2y ago
[flagged]
- mulmen 2y ago
  > The same people community clutching pearls This is an unfortunate typo because your meaning is completely lost. If your claim is that individuals are being hypocritical then you may have a point. Especially if you can produce examples. But if you mean community vs community then you have simply bought in to the religious debate which isn’t interesting.
  - ajross 2y ago
    [flagged]
    - geodel 2y ago
      [flagged]
      - dralley 2y ago
        [flagged]
        ajross 2y ago
        The distinction in this particular case is that Rust tried to "downvote" a lkml discussion to get code merged. No one much cares about rendering color in HN comments, except to the extent that we're having this discussion (which you found valuable enough to contribute to!) in an invisible flagged subthread because Rust people don't want to have it, apparently. It's just tiresome. And it boiled over here, because no matter how enthusiastic the Rust people can be their youthful exuberance pales in influence in comparison with the the talent and impact of the Linux Kernel maintainers. And the resulting tantrum shows it.
        dralley 2y ago
tharne 2y ago
> Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust" Given the online temper tantrum thrown by marcan, Ted Tso'o's comment seems totally reasonable, regardless of one's opinion of Rust in the Linux kernel.
- dralley 2y ago
  Ted gave that rant 6 months ago, and it was in fact unreasonable if you look at the details of what they were discussing. You're trying to use Marcan's ragequit to ex-post-facto justify Ted T'so when it's literally the other way around.
- deleted 2y ago
  [deleted]
- LexiMax 2y ago
  Quite frankly, if I had the realization that despite assurances to the contrary, that my contributions to a project had been sabotaged for months or even years up to that point, I would have also had a hard time keeping a smile on my face. This is ultimately what this drama comes down to. Not if Rust should or shouldn't be in the kernel, but with kernel maintainers' broken promises and being coy with intentions until there is no other option than to be honest, with the reveal that whatever time and effort a contributor had put in was a waste from the start. It seems like the folks who didn't want Rust in the kernel will be getting their way in the end, but I had better never hear another complaint about the kernel not being able to attract new talent.
  - detuur 2y ago
    I can't believe you're the first person I find in this conversation who raises this issue. This is the exact reason why Marcan flipped his lid. Linus publicly championed a very technically complex initiative and then left all those contributors to the wolves when things didn't progress without a hiccup. Especially damning when you consider that at every step, the fief lords in Linux have seemingly done everything in their power to set up the r4l people for failure and Linus hasn't so much as squeaked at them. He personally cut the knot and asserted that Rust is Linux's future, but he constantly allows those below him to relitigate the issue with new contributors (who can't fight back because even though they're contributing by the supposed rules, they don't have enough social buy-in).

uecker 2y ago

His email seems very reasonable to me (the thin-blue-line comment is a bit weird though). To me the problem are that some Rust people seem to expect that the Linux maintainers (that put in a tremendous amount of work) just have to go out of their way to help them achieve their goals - even if the maintainers are not themselves convinced about it and later have to carry the burden.

Ar-Curunir 2y ago
How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.
- uecker 2y ago
  I don't think it is this simple.
- afr0ck 2y ago
  This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.
  - dralley 2y ago
    At some level this is just concern trolling. There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just expressed. You are asking for something that is impossible. What could they possibly "deliver" beyond a strong commitment to fix the code in a timely manner themselves?
    - tmoertel 2y ago
      > There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just exprssed. They could do exactly what Ted Ts'o suggested in his email [1] that Marcan cited: They could integrate more into the existing kernel-development community, contribute to Linux in general, not just in relation to their pet projects, and over time earn trust that, when they make promises with long time horizons, they can actually keep them. Because, if they can't keep those promises, whoever lets their code into the kernel ends up having to keep their promises for them. [1] https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...
      - dralley 2y ago
        Many of them have, in fact, done all of those things, and have done them over a time horizon measured in years. Many of the R4L developers are paid by their employers specifically to work on R4L and can therefore be considered reasonably reliable and not drive-by contributors. Many existing maintainers are not "general contributors" It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do. Christoph refused to take onboard a new maintainer. The fight from last August was about subsystem devs refusing to document the precise semantics of their C APIs. These are signs of fief-building that would be equally dangerous to the long-term health of the project if Rust was not involved whatsoever.
        zifpanachr23 2y ago
        I disagree. If you want to provide technical leadership by massively changing the organization and tooling of a huge project that has been around a long time, it should be absolutely mandatory to spend years building trust and doing work that you don't want to do. That's just how programming on teams and trust and teamwork actually works in the real world. Especially on a deadly serious not-hobby project like the kernel. Sometimes you are gonna have to do work that doesn't excite you. That's life doing professional programming. Everything Ted Tso recommended is just common sense teamwork 101 stuff and it's just generally good advice for programmers in their careers. The inability of rust people to follow it will only hurt them and doom their desire to be accepted by larger more important projects in the long run. Programming on a team is a social affair and pretending you don't have to play by the rules because you have such great technical leadership is arrogant.
- rc00 2y ago
  As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250131135421.GO5556... > Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not. > Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders". > It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build. For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?
  - chrsig 2y ago
    > For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads? Yes actually, I really wish someone would bring that sort of thing to the forefront, because that's a great spot to welcome new contributors.
- toast0 2y ago
  As a non-interested observer; I think it will need to be said until the commitment becomes credible. I don't know how it would become credible, but it's clearly not considered credible by at least those of the kernel maintainers who are worried about the maintenance burden of accepting rust patches.
- gkbrk 2y ago
  This is not what the "Rust kernel policy" [1] of Rust for Linux says. [1]: https://rust-for-linux.com/rust-kernel-policy https://rust-for-linux.com/rust-kernel-policy > Who is responsible if a C change breaks a build with Rust enabled? > The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust. > Didn't you promise Rust wouldn't be extra work for maintainers? > No, we did not. Since the very beginning, we acknowledged the costs and risks a second language introduces.
  - steveklabnik 2y ago
    You conveniently left out > However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.
    - gkbrk 2y ago
      Yes, "breakage should be fixed as soon as possible". Not "Rust for Linux team will fix the breakage as soon as possible". The exception is allowing the subsystem to break Rust code temporarily. If you accept a patch in C that breaks Rust code, and the Rust for Linux team doesn't fix it quickly enough, you either need to fix the Rust code yourself, remove it, or re-write it in C. All of this would take time and energy from all the non-R4L kernel devs. This is why people are reluctant to accept too much mixing of the C and Rust codebases, because even the Rust for Linux team isn't promising to fix breakages in Rust for Linux code.
      - nindalf 2y ago
        Just to be clear, this is the situation. A rando submits a C patch that breaks Rust code, a maintainer accepts this patch and then demands that the R4L devs fix the breakage introduced by someone else and reviewed by themselves. The rando who broke the thing isn't around, and the person who reviewed the change takes no responsibility. Have I gotten that right? And then you're presenting this situation as "the Rust for Linux team isn't promising to fix breakages in Rust for Linux code". Somewhat disingenuous.
- zifpanachr23 2y ago
  They've said that, but nobody believes them, and can you blame them given we JUST saw another big rust maintainer resign? I'd be suspicious these guys aren't in it for the long haul if they don't get their way and will leave the Rust they shoved in the kernel to bit rot if things don't go their way w.r.t enough rust adoption fast enough. "If you don't let us add even more rust, we will resign from the project and leave you to maintain the rust that's already there and that we added, and that you said you didn't want to add because you didn't trust us to not resign". Rust 4 Linux people just proving the points of the maintainers scared of abandonment. The rust 4 Linux people unfortunarely give the impression of caring more about rust than about the kernel, and it's clear that many are willing to make that perfectly clear by abandoning the larger project. The whole thing needs to be scrapped and rethought with better and more committed leadership. This past 6 months to a year has been embarrassing and done nothing but confirm the fears of anti rust people.
  - timeon 2y ago
    These people were quitting after being harassed. So I do not think you are arguing in good faith.
- aragilar 2y ago
  That doesn't line with https://rust-for-linux.com/rust-kernel-policy#who-is-responsible-if-a-c-change-breaks-a-build-with-rust-enabled https://rust-for-linux.com/rust-kernel-policy#who-is-respons... (which may be a recent change?)
- CRConrad 2y ago
  > the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. How have they "committed"? By saying they commit[1], I presume -- but what more? Anyone can say anything. I think what makes the "old guard" kernel maintainers nervous is the lack of a track record. And yes, I know that's a kind of a lifting-yourself-by-your-bootstraps problem. And no, I don't know of any solution to that. But I do know that, like baron Münchhausen, you can't ride your high horse around the swamp before you've pulled your self out of it. ___ [1]: And, as others in this thread have shown, that's apparently just out of one side of their collective mouth: The official "Rust kernel policy" says otherwise.
vaxman 2y ago
> "the thin-blue-line comment is a bit weird though" In US, "thin blue line" is a colloquialism for police officers who typically wear blue and "toe the line." You should not be downvoted/shadowbanned/abused for your post, IMHO.

ajross 2y ago

[flagged]

mulmen 2y ago
> The same people community clutching pearls This is an unfortunate typo because your meaning is completely lost. If your claim is that individuals are being hypocritical then you may have a point. Especially if you can produce examples. But if you mean community vs community then you have simply bought in to the religious debate which isn’t interesting.
- ajross 2y ago
  [flagged]
  - geodel 2y ago
    [flagged]
    - dralley 2y ago
      [flagged]
      - ajross 2y ago
        The distinction in this particular case is that Rust tried to "downvote" a lkml discussion to get code merged. No one much cares about rendering color in HN comments, except to the extent that we're having this discussion (which you found valuable enough to contribute to!) in an invisible flagged subthread because Rust people don't want to have it, apparently. It's just tiresome. And it boiled over here, because no matter how enthusiastic the Rust people can be their youthful exuberance pales in influence in comparison with the the talent and impact of the Linux Kernel maintainers. And the resulting tantrum shows it.
        dralley 2y ago

tharne 2y ago

> Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust" Given the online temper tantrum thrown by marcan, Ted Tso'o's comment seems totally reasonable, regardless of one's opinion of Rust in the Linux kernel.

dralley 2y ago
Ted gave that rant 6 months ago, and it was in fact unreasonable if you look at the details of what they were discussing. You're trying to use Marcan's ragequit to ex-post-facto justify Ted T'so when it's literally the other way around.
deleted 2y ago
[deleted]
LexiMax 2y ago
Quite frankly, if I had the realization that despite assurances to the contrary, that my contributions to a project had been sabotaged for months or even years up to that point, I would have also had a hard time keeping a smile on my face. This is ultimately what this drama comes down to. Not if Rust should or shouldn't be in the kernel, but with kernel maintainers' broken promises and being coy with intentions until there is no other option than to be honest, with the reveal that whatever time and effort a contributor had put in was a waste from the start. It seems like the folks who didn't want Rust in the kernel will be getting their way in the end, but I had better never hear another complaint about the kernel not being able to attract new talent.
- detuur 2y ago
  I can't believe you're the first person I find in this conversation who raises this issue. This is the exact reason why Marcan flipped his lid. Linus publicly championed a very technically complex initiative and then left all those contributors to the wolves when things didn't progress without a hiccup. Especially damning when you consider that at every step, the fief lords in Linux have seemingly done everything in their power to set up the r4l people for failure and Linus hasn't so much as squeaked at them. He personally cut the knot and asserted that Rust is Linux's future, but he constantly allows those below him to relitigate the issue with new contributors (who can't fight back because even though they're contributing by the supposed rules, they don't have enough social buy-in).