7 ms·

Regretfully a major Rust for Linux maintainer just stepped down yesterday, saying he doesn't have the energy to keep dealing with the constant nontechnical nons

by tux3 2y ago

Regretfully a major Rust for Linux maintainer just stepped down yesterday, saying he doesn't have the energy to keep dealing with the constant nontechnical nonsense: https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/ https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...

tyleo 2y ago
I lack context. What is the “constant nontechnical nonsense”?
- speed_spread 2y ago
  Kneejerk pushback from old timers C-only kernel devs.
  - tyleo 2y ago
    Thanks for sharing. This makes a lot of sense to me. I’m not close to kernel development but any change to an established entity impacts the interest of people in it. So a primary obstacle change encounters is that it may diminish power people obtained in the establishment. These people, while well intentioned in pushback, have difficulty separating benefit to the entity and benefit to themselves. So it takes a lot of work to impact change, and I understand the distance it has from normal technical work.
    - abhinavk 2y ago
      Asahi Linux’s (Distro targeting Macs) developer also recounts a similar experience. https://vt.social/@lina/113045455229442533 https://vt.social/@lina/113045455229442533
  - mytailorisrich 2y ago
    It's inevitable in any organisations when dealing with change. Identifying resistance and coming up with strategies to overcome is a key part of change management. Telling people their reaction is "kneejerk pushback" usually does not help ;) It's probably more difficult to handle in open source than in a company because authority less powerful and it's more difficult to wave both carrots and sticks...
    - deleted 2y ago
      [deleted]
    - bitexploder 2y ago
      Well, as an uninvested observer I think it is okay to call it out.
      - cogman10 2y ago
        At a talk presenting a personal project? Do you also feel it's OK to go to talks on Java projects to make statements like "Well, why didn't you write this in Go? It's a better language that serious developers are using and nobody will want to contribute to your dumb project using java"
  - jtrueb 2y ago
    That was pretty toxic for a kneejerk reaction.
    - bitexploder 2y ago
      Wow, the speakers point was so totally missed it was comical. That was just actually insulting and rude to the speaker in my opinion.
      - cogman10 2y ago
        Yup, anyone defending this behavior needs a screw tightened. The dev "pushing back" was being an asshole probably because of deep insecurity of gasp there being other programming languages than C. Literally rust is currently being proposed for maybe new drivers and basically nothing else ATM. Nobody is suggesting rewriting code in rust or forcing people to learn rust. It is literally just "Hey, might be nice to write this driver for my mouse in a memory safe language".
  - dgb23 2y ago
    I would assume this type of pushback is one of the main reasons a project like Linux is trustworthy in the first place.
    - cogman10 2y ago
      That wasn't the nature of the pushback. He did a presentation on making a fs in rust, the response from this dev was "we won't be converting to your religion. We are going to continue modifying c code and your dumb rust code will always be a second class citizen." Literally just hostility for hostility sake. He wasn't proposing to rewrite everything in rust. He wasn't proposing that everyone learns rust. He was just giving a freaking presentation on making a rust fs that integrates with the kernel and was immediately trashed for spreading religion or whatever. Non-technical nonsense is charitable.
      - computerthings 2y ago
        What was literally said didn't include the words "always" or "your dumb rust code". From the subtitles with slight manual fixes: > I suspect part of the problem here is you're trying to convince everyone to switch over to the religion as promulgated by rust and the reality is that ain't going to happen because we have 50 plus filesystems in Linux, they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make the C code better. If it breaks rust bindings, at least for the foreseeable future the rust bindings are a second class citizen and those file systems that depend on the rust bindings will break and that is the rust bindings problem, not the file system community at large's problem and that's going to be true for a long long time, okay, and I think we just simply need to accept that That seems rather technical to me. To put words into their mouth because they had a snarky tone, or claim the presenter was "immediately stacked for spreading religion or whatever" hardly is.
        cogman10 2y ago
        They literally said "spreading your religion" at the very start of their critique. I think I'm correctly reading the tone of the rest of the comment even if I didn't verbatim quote them. From the closed captions with minor editing. In response to "we are going to provide API bindings" > I suspect the problem here is you are trying to convert everyone to the religion as promulgated by rust and the reality is that ain't gonna happen. Because we have 50 plus filesystems in linux and they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make C code better. If that breaks the rust bindings at least for the foreseeable future the rust bindings are a second class citizen. Those file systems that depend on the rust bindings will break and that is the rust bindings problem not the file system community at large problem. And that's going to be true for a long long time, OK. And I think we just simply accept that right because the answer you are not allowed to refactor C code because it would break 5 critical file systems that distros depend on is like not a star, OK.
  - api 2y ago
    Lots of that, which is why we are going to have memory error CVEs for the next hundred years.
- steveklabnik 2y ago
  https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41386939 A comment there has a link to a video of what seems to be the final straw.
  - Zambyte 2y ago
    Also linked in the email in the GP. > Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.
    - theta_d 2y ago
      That was painful to watch.
    - techwizrd 2y ago
      A redditor pointed out [0] that this is exactly what they would do to sink Rust adoption. Even if you agree with the substance of the argument, the delivery is rude and unhelpful. I hope this resignation is a wake-up call, and much of the onus is on C devs to be more collaborative. 0: https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_rust_linux_kernel_maintainers_steps/lkgvejt/ https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_r...
      - zozbot234 2y ago
        Why do C devs even have to be 'collaborative' about Rust modules? The latter would typically ingest C APIs, most likely via bindgen, making C code the "source of truth" about what the API is - because Rust modules are self-contained and C is the only stable ABI that Rust supports. All the type-checking smarts that the video talks about are purely on the Rust side. If a new 'raw' low-level C API is needed to build better smarts on the Rust side (which seems to be what's involved in some of the fs proposals) that can just be a self-contained proposal, with very lightweight changes on the C side of the code. This whole thing looks like a tempest in a teapot to me - and to be clear, this absolutely includes the Linux dev's complaints, which are extremely poor form.
- kranuckle 2y ago
  [dead]
pif 2y ago
Unless the Linux developer community at large requested Rust in the kernel, this is good news.
- rowanG077 2y ago
  Good news for whom? The mental safe space of old time kernel developers? Or good new for users who will continue to have to deal with kernel panics and other memory issues.
  - hagbard_c 2y ago
    > users who will continue to have to deal with kernel panics and other memory issues. I have not seen many of those in my close to 32 years of involvement with Linux. In the beginning of the project they did occur 'every now and then' but once Linux got past v1.2 or thereabouts they're about as rare as hen's teeth. If Rust ever becomes widespread enough for kernel developers to pick it up with ease it will be a welcome addition but until such a time I prefer for the project to remain C-focused so as not to close out a large fraction of the potential developer base. If that means that some 'competing' kernel gets written in Rust and takes over from Linux that'd be fine by me as well, may the best [1] kernel win. [1] see https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
    - rowanG077 2y ago
      I admit it's not often I see a direct panic. But I do see bugs caused by memory issues relatively often. In fact two weeks ago I made a patch for a memory issue in a wifi driver that caused it to drop connections. The long list of CVE is more direct proof though. By far most of them are memory safety issues. Suggesting making a new kernel is just total FUD. This is a multi decade project. It's like saying to a person who want some legislation in their country to change "why not make your own country, may the best country win". It's just so far removed from reality I'm very surprised I have seen this argument more then once.
      - 2y ago

by tux3 2y ago

tyleo 2y ago

I lack context. What is the “constant nontechnical nonsense”?

speed_spread 2y ago
Kneejerk pushback from old timers C-only kernel devs.
- tyleo 2y ago
  Thanks for sharing. This makes a lot of sense to me. I’m not close to kernel development but any change to an established entity impacts the interest of people in it. So a primary obstacle change encounters is that it may diminish power people obtained in the establishment. These people, while well intentioned in pushback, have difficulty separating benefit to the entity and benefit to themselves. So it takes a lot of work to impact change, and I understand the distance it has from normal technical work.
  - abhinavk 2y ago
    Asahi Linux’s (Distro targeting Macs) developer also recounts a similar experience. https://vt.social/@lina/113045455229442533 https://vt.social/@lina/113045455229442533
- mytailorisrich 2y ago
  It's inevitable in any organisations when dealing with change. Identifying resistance and coming up with strategies to overcome is a key part of change management. Telling people their reaction is "kneejerk pushback" usually does not help ;) It's probably more difficult to handle in open source than in a company because authority less powerful and it's more difficult to wave both carrots and sticks...
  - deleted 2y ago
    [deleted]
  - bitexploder 2y ago
    Well, as an uninvested observer I think it is okay to call it out.
    - cogman10 2y ago
      At a talk presenting a personal project? Do you also feel it's OK to go to talks on Java projects to make statements like "Well, why didn't you write this in Go? It's a better language that serious developers are using and nobody will want to contribute to your dumb project using java"
- jtrueb 2y ago
  That was pretty toxic for a kneejerk reaction.
  - bitexploder 2y ago
    Wow, the speakers point was so totally missed it was comical. That was just actually insulting and rude to the speaker in my opinion.
    - cogman10 2y ago
      Yup, anyone defending this behavior needs a screw tightened. The dev "pushing back" was being an asshole probably because of deep insecurity of gasp there being other programming languages than C. Literally rust is currently being proposed for maybe new drivers and basically nothing else ATM. Nobody is suggesting rewriting code in rust or forcing people to learn rust. It is literally just "Hey, might be nice to write this driver for my mouse in a memory safe language".
- dgb23 2y ago
  I would assume this type of pushback is one of the main reasons a project like Linux is trustworthy in the first place.
  - cogman10 2y ago
    That wasn't the nature of the pushback. He did a presentation on making a fs in rust, the response from this dev was "we won't be converting to your religion. We are going to continue modifying c code and your dumb rust code will always be a second class citizen." Literally just hostility for hostility sake. He wasn't proposing to rewrite everything in rust. He wasn't proposing that everyone learns rust. He was just giving a freaking presentation on making a rust fs that integrates with the kernel and was immediately trashed for spreading religion or whatever. Non-technical nonsense is charitable.
    - computerthings 2y ago
      What was literally said didn't include the words "always" or "your dumb rust code". From the subtitles with slight manual fixes: > I suspect part of the problem here is you're trying to convince everyone to switch over to the religion as promulgated by rust and the reality is that ain't going to happen because we have 50 plus filesystems in Linux, they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make the C code better. If it breaks rust bindings, at least for the foreseeable future the rust bindings are a second class citizen and those file systems that depend on the rust bindings will break and that is the rust bindings problem, not the file system community at large's problem and that's going to be true for a long long time, okay, and I think we just simply need to accept that That seems rather technical to me. To put words into their mouth because they had a snarky tone, or claim the presenter was "immediately stacked for spreading religion or whatever" hardly is.
      - cogman10 2y ago
        They literally said "spreading your religion" at the very start of their critique. I think I'm correctly reading the tone of the rest of the comment even if I didn't verbatim quote them. From the closed captions with minor editing. In response to "we are going to provide API bindings" > I suspect the problem here is you are trying to convert everyone to the religion as promulgated by rust and the reality is that ain't gonna happen. Because we have 50 plus filesystems in linux and they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make C code better. If that breaks the rust bindings at least for the foreseeable future the rust bindings are a second class citizen. Those file systems that depend on the rust bindings will break and that is the rust bindings problem not the file system community at large problem. And that's going to be true for a long long time, OK. And I think we just simply accept that right because the answer you are not allowed to refactor C code because it would break 5 critical file systems that distros depend on is like not a star, OK.
- api 2y ago
  Lots of that, which is why we are going to have memory error CVEs for the next hundred years.
steveklabnik 2y ago
https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41386939 A comment there has a link to a video of what seems to be the final straw.
- Zambyte 2y ago
  Also linked in the email in the GP. > Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.
  - theta_d 2y ago
    That was painful to watch.
  - techwizrd 2y ago
    A redditor pointed out [0] that this is exactly what they would do to sink Rust adoption. Even if you agree with the substance of the argument, the delivery is rude and unhelpful. I hope this resignation is a wake-up call, and much of the onus is on C devs to be more collaborative. 0: https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_rust_linux_kernel_maintainers_steps/lkgvejt/ https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_r...
    - zozbot234 2y ago
      Why do C devs even have to be 'collaborative' about Rust modules? The latter would typically ingest C APIs, most likely via bindgen, making C code the "source of truth" about what the API is - because Rust modules are self-contained and C is the only stable ABI that Rust supports. All the type-checking smarts that the video talks about are purely on the Rust side. If a new 'raw' low-level C API is needed to build better smarts on the Rust side (which seems to be what's involved in some of the fs proposals) that can just be a self-contained proposal, with very lightweight changes on the C side of the code. This whole thing looks like a tempest in a teapot to me - and to be clear, this absolutely includes the Linux dev's complaints, which are extremely poor form.
kranuckle 2y ago
[dead]

pif 2y ago

Unless the Linux developer community at large requested Rust in the kernel, this is good news.

rowanG077 2y ago
Good news for whom? The mental safe space of old time kernel developers? Or good new for users who will continue to have to deal with kernel panics and other memory issues.
- hagbard_c 2y ago
  > users who will continue to have to deal with kernel panics and other memory issues. I have not seen many of those in my close to 32 years of involvement with Linux. In the beginning of the project they did occur 'every now and then' but once Linux got past v1.2 or thereabouts they're about as rare as hen's teeth. If Rust ever becomes widespread enough for kernel developers to pick it up with ease it will be a welcome addition but until such a time I prefer for the project to remain C-focused so as not to close out a large fraction of the potential developer base. If that means that some 'competing' kernel gets written in Rust and takes over from Linux that'd be fine by me as well, may the best [1] kernel win. [1] see https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
  - rowanG077 2y ago
    I admit it's not often I see a direct panic. But I do see bugs caused by memory issues relatively often. In fact two weeks ago I made a patch for a memory issue in a wifi driver that caused it to drop connections. The long list of CVE is more direct proof though. By far most of them are memory safety issues. Suggesting making a new kernel is just total FUD. This is a multi decade project. It's like saying to a person who want some legislation in their country to change "why not make your own country, may the best country win". It's just so far removed from reality I'm very surprised I have seen this argument more then once.
    - 2y ago