7 ms·

To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "comin

To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects".

sprash 2y ago
[flagged]
lelanthran 2y ago
> To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects". Not in this case. It's the Rust evangelist who is the newcomer. FTA: > Almeida said that he is not trying to keep the C API static; his goal is to get the filesystem developers to explain the semantics of the API so that they can be encoded into Rust. The responses from the kernel team members to the proposal seem reasoned and mature to me: > In addition, when the C code changes, the Rust code needs to follow along, but who is going to do that work? > As the C code evolves, which will happen more quickly than with the Rust code, at least initially, there will be a need to keep the two APIs in sync. > The object lifecycles are being encoded into the Rust API, but there is no equivalent of that in C; if someone changes the lifecycle of the object on one side, the other will have bugs. > Encoding a single lifecycle understanding into the API means that its functions will not work for some filesystems. > Part of the problem, Ted Ts'o said, is that there is an effort to get "everyone to switch over to the religion" of Rust; that will not happen, he said, because there are 50+ different filesystems in Linux that will not be instantaneously converted. > Bottomley said that as more of those semantics get encoded into the bindings, they will become more fragile from a synchronization standpoint > But Ts'o pointedly said that not everyone will learn Rust; if he makes a change, he will fix all of the affected C code, but, "because I don't know Rust, I am not going to fix the Rust bindings, sorry".
- rcxdude 2y ago
  The other person behind the proposal, is however a seasoned kernel developer, with >14 years of experience working in the FS subsystem of linux.
  - tucnak 2y ago
    This is case-in-point; bcachefs maintainer is merely _entertaining_ the ideas proposed by the Rust evangelist, with the express intent of exploring alternatives... and suddenly it's enough for "the movement" to co-opt him into the "proposal" [to include Rust in the FS subsystem], it seeems. Are Rust supporters really as desperate so-as to co-opt ANY interest in the subject?? This toxicity is not helping anybody.
    - _flux 2y ago
      I'm not sure what you are saying. Maybe the first proposal isn't the best one, so some exploration is warranted. Is Kent an unwilling pawn in the game of getting Rust implemented in the Linux kernel? Or is he not serious enough about getting it in that his support should not be considered? From what I've seen it reads to me Kent would be very happy to implement bcachefs in Rust in the Linux kernel. Bcachefs-tools does make use of it.
      - tucnak 2y ago
        [flagged]
        pjc50 2y ago
        > But they don't want to be writing file systems; instead, the only goal that matters to them is getting to the heart of the most popular OS, so as to secure some longterm success. Wrong final word: security. In the war against remote exploits, harden the most widely used target first. Rust only exists because getting people to reliably and consistently write secure C++ proved impossible. (yes I know C++ is a much larger and more complicated language than C)
- rascul 2y ago
  > Not in this case. It's the Rust evangelist who is the newcomer. FTA: From a quick search, I've found that the person is somewhat active in kernel commits over the last four years (mostly but not all rust related from what I see) and is involved in some lkml stuff and some commits over a decade ago. Not sure if this makes him a newcomer or not, just wanted to provide a bit more context.
tucnak 2y ago
This is a common misconception; like every movement of "revolutionary" modus, it likes to over-represent its supporter base & amplify the chosen ambassadors. So whenever some kind of concession, or endorsement is made—it's immediately read, and amplified as indicative of a greater support, and/or change.
Firmwarrior 2y ago
[flagged]
- guitarbill 2y ago
  > Rust kids need to quit tricking other entry level aspiring OS devs into wasting their time learning this language. In that case, C/C++ developers need to quit tricking the rest of the world that C/C++ is a suitable language for anything security related and - for commercial products - take responsibility for the economic and social impact for the data breaches due to memory safety issues. (I really don't care if it's Rust, Java, C#, whatever.)
- abenga 2y ago
  Hmmm. Is this serious or facetious? Or could be either, depending on the response? There already is rust code in the Linux kernel (some drivers), afaik.
  - tucnak 2y ago
    Linus strategy on Rust is genius, albeit immoral. — Don't engage the movement head-on, make concessions where it doesn't matter. — Nobody wants to write drivers? No problem, have THEM write the drivers where the impact is minimal. I believe, if Rust people really understood how they're being used exactly, they wouldn't bother with it, and would go on to write more impactful code. And yet, Linus had managed to execute this strategy perfectly; the insult is subtle enough not to cause major injury.
    - tracker1 2y ago
      I seriously doubt it's meant as an insult so much as to minimize near term impact in case there are (and likely will be) mistakes to the larger ecosystem. Creating clearer separations for where Rust can make more sense initially is important. Not just for Rust, but C/C++ and other future languages all around. The file system is an area where Rust can make a lot of sense, similar for network drivers. Points of interaction with underlying hardware and external systems where well defined controls are all the more important and widely interacted with. I would be surprised, if within a decade a lot of the use of OpenSSL isn't displaced with rustls across a lot of applications even if not written in Rust directly.

To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects".

sprash 2y ago

[flagged]

lelanthran 2y ago

> To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects". Not in this case. It's the Rust evangelist who is the newcomer. FTA: > Almeida said that he is not trying to keep the C API static; his goal is to get the filesystem developers to explain the semantics of the API so that they can be encoded into Rust. The responses from the kernel team members to the proposal seem reasoned and mature to me: > In addition, when the C code changes, the Rust code needs to follow along, but who is going to do that work? > As the C code evolves, which will happen more quickly than with the Rust code, at least initially, there will be a need to keep the two APIs in sync. > The object lifecycles are being encoded into the Rust API, but there is no equivalent of that in C; if someone changes the lifecycle of the object on one side, the other will have bugs. > Encoding a single lifecycle understanding into the API means that its functions will not work for some filesystems. > Part of the problem, Ted Ts'o said, is that there is an effort to get "everyone to switch over to the religion" of Rust; that will not happen, he said, because there are 50+ different filesystems in Linux that will not be instantaneously converted. > Bottomley said that as more of those semantics get encoded into the bindings, they will become more fragile from a synchronization standpoint > But Ts'o pointedly said that not everyone will learn Rust; if he makes a change, he will fix all of the affected C code, but, "because I don't know Rust, I am not going to fix the Rust bindings, sorry".

rcxdude 2y ago
The other person behind the proposal, is however a seasoned kernel developer, with >14 years of experience working in the FS subsystem of linux.
- tucnak 2y ago
  This is case-in-point; bcachefs maintainer is merely _entertaining_ the ideas proposed by the Rust evangelist, with the express intent of exploring alternatives... and suddenly it's enough for "the movement" to co-opt him into the "proposal" [to include Rust in the FS subsystem], it seeems. Are Rust supporters really as desperate so-as to co-opt ANY interest in the subject?? This toxicity is not helping anybody.
  - _flux 2y ago
    I'm not sure what you are saying. Maybe the first proposal isn't the best one, so some exploration is warranted. Is Kent an unwilling pawn in the game of getting Rust implemented in the Linux kernel? Or is he not serious enough about getting it in that his support should not be considered? From what I've seen it reads to me Kent would be very happy to implement bcachefs in Rust in the Linux kernel. Bcachefs-tools does make use of it.
    - tucnak 2y ago
      [flagged]
      - pjc50 2y ago
        > But they don't want to be writing file systems; instead, the only goal that matters to them is getting to the heart of the most popular OS, so as to secure some longterm success. Wrong final word: security. In the war against remote exploits, harden the most widely used target first. Rust only exists because getting people to reliably and consistently write secure C++ proved impossible. (yes I know C++ is a much larger and more complicated language than C)
rascul 2y ago
> Not in this case. It's the Rust evangelist who is the newcomer. FTA: From a quick search, I've found that the person is somewhat active in kernel commits over the last four years (mostly but not all rust related from what I see) and is involved in some lkml stuff and some commits over a decade ago. Not sure if this makes him a newcomer or not, just wanted to provide a bit more context.

tucnak 2y ago

This is a common misconception; like every movement of "revolutionary" modus, it likes to over-represent its supporter base & amplify the chosen ambassadors. So whenever some kind of concession, or endorsement is made—it's immediately read, and amplified as indicative of a greater support, and/or change.

Firmwarrior 2y ago

[flagged]

guitarbill 2y ago
> Rust kids need to quit tricking other entry level aspiring OS devs into wasting their time learning this language. In that case, C/C++ developers need to quit tricking the rest of the world that C/C++ is a suitable language for anything security related and - for commercial products - take responsibility for the economic and social impact for the data breaches due to memory safety issues. (I really don't care if it's Rust, Java, C#, whatever.)
abenga 2y ago
Hmmm. Is this serious or facetious? Or could be either, depending on the response? There already is rust code in the Linux kernel (some drivers), afaik.
- tucnak 2y ago
  Linus strategy on Rust is genius, albeit immoral. — Don't engage the movement head-on, make concessions where it doesn't matter. — Nobody wants to write drivers? No problem, have THEM write the drivers where the impact is minimal. I believe, if Rust people really understood how they're being used exactly, they wouldn't bother with it, and would go on to write more impactful code. And yet, Linus had managed to execute this strategy perfectly; the insult is subtle enough not to cause major injury.
  - tracker1 2y ago
    I seriously doubt it's meant as an insult so much as to minimize near term impact in case there are (and likely will be) mistakes to the larger ecosystem. Creating clearer separations for where Rust can make more sense initially is important. Not just for Rust, but C/C++ and other future languages all around. The file system is an area where Rust can make a lot of sense, similar for network drivers. Points of interaction with underlying hardware and external systems where well defined controls are all the more important and widely interacted with. I would be surprised, if within a decade a lot of the use of OpenSSL isn't displaced with rustls across a lot of applications even if not written in Rust directly.