6 ms·

I've been saying this for years now: the rust4linux folks are putting so much effort into trying to upstream their work, seems like they should instead put that

I've been saying this for years now: the rust4linux folks are putting so much effort into trying to upstream their work, seems like they should instead put that effort into maintaining a fork. Arguably it would be less hours spent porting than arguing with humans. Certainly more pleasant! Then one of two things will happen: * Rust will prove its worth and their fork will be the better operating system. Distros will start switching to it one by one due to its increased performance and stability, and they will have dethroned Linus and become gods of the new world. * The project will die because the C programmers will outcompete it with good ol' C, and all their talk about safety doesn't pan out in the real world. If I were the rust4linux leadership, I'd roll those dice. Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning).

deleted 2y ago
[deleted]
gpm 2y ago
I think you're discounting the very real damage that would be done by Linux a project controlled by Linus and a community being replaced by Linux a project controlled by Google/Samsung/Redhat/Microsoft. I'm afraid that this is what is going to happen with the Linus tree effectively rejecting rust drivers by subjecting anyone attempting to upstream rust code to persistent bullying, but I don't want it to happen.
- jeanlucas 2y ago
  [flagged]
- actinium226 2y ago
  > I think you're discounting the very real damage that would be done by [Linux a project controlled by Linus and a community] being replaced by [Linux a project controlled by Google/Samsung/Redhat/Microsoft.] (Brackets added for clarity) Isn't the current Linux already Linus + communities + companies? More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
  - gpm 2y ago
    > Isn't the current Linux already Linus + communities + companies? Absolutely. To that point the companies I listed are the ones that I'm aware of employing kernel developers who work specifically on rust in linux. The control of the project is in Linus's/community hands though, not corporate ones, and I think that's a good thing. > More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync. I don't think so. Linux is a huge modular system, and no one is really interested in rewriting the core components of it at this point. Nor maintaining their own copies of components that some other company is responsible for (like graphics drivers). Until and unless it became the dominant fork I'd expect that they'd keep merging in the mainline branch and updating their things as necessary. This is already how projects like Android work.
- apatheticonion 2y ago
  Does Linux have the ability to load drivers dynamically (like Windows)? Is there a reason why developers don't develop drivers outside of the kernel and have users simply install them post-install?
  - sgerenser 2y ago
    It can, but Linux does not have a stable driver ABI. Whoever wrote the out-of-tree drivers would have to constantly update them whenever there was a breaking change to the kernel, which I understand is relatively common.
    - apatheticonion 2y ago
      That's interesting. Dumb question but why doesn't Linux aim for a stable driver ABI? Does it impede delivery speed? I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
      - DrillShopper 2y ago
        The rationale for not having a stable driver ABI is here: https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-... RE: nvidia - yes
      - gcr 2y ago
        nvidia uses "DKMS" to rebuild itself for each running kernel. Closed source modules like nvidia frequently have a kernel-independent proprietary piece and a kernel-specific (open source) ABI piece. Whenever you upgrade your kernel, DKMS will re-build the kernel-specific shim and re-link the proprietary blob. The result is a .ko tailor made for your running kernel, even though most of the code is in a kernel-independent blob.
        DrillShopper 2y ago
        It looks like nVidia is open to moving their open driver (which requires a card that as a GSP) upstream [1] but with Rust being killed from the Linux kernel that's probably dead. [1] https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD
- 77pt77 2y ago
  > controlled by Google/Samsung/Redhat/Microsoft. Can they do that to openssl instead? Thank you.
  - gpm 2y ago
    They did: https://github.com/aws/aws-lc https://github.com/aws/aws-lc / https://github.com/google/boringssl https://github.com/google/boringssl (Not in rust, but it's mostly assembly anyways so I'm not sure rust provides much. There is https://github.com/briansmith/ring https://github.com/briansmith/ring in rust, not sure if it's sponsored by anyone)
- hitekker 2y ago
  > subject upstream rust code to persistent bullying I don’t remember seeing this bullying accusation in your original comment. Was it edited in? Regardless, the “bullying” happened on both sides. Hector Martin started the social media brigading and quit when he couldn’t get his personal enemy suspended for CoC violations. Jonathan Corbet wrote a letter naming and shaming maintainers, in the guise of a report. All in all, I agree with the GP. Most of the arguments against (even temporary) forking feel like excuses for a lack of will and a maybe even a lack of ability. The space is open for a fork.
  - gpm 2y ago
    I may have edited the phrasing within a minute or two of posting, couldn't say. I haven't edited the comment in the 14 hours since then, and the sentiment was in the original. (I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)
- dbcjv7vhxj 2y ago
  Why do people think rejecting rust drivers is a bad thing? It's a fucking c project.
msgilligan 2y ago
I think a fork with a mission to aggressively rewrite the kernel into Rust would be a great experiment. Lessons learned could be applied to the more mainstream C/Rust kernel(s). Has anyone done that?
- actinium226 2y ago
  https://www.redox-os.org/ https://www.redox-os.org/ It's not a fork of Linux but a ground up effort to write a kernel in Rust. Still they're trying to make it compatible with Linux/BSD
  - snvzz 2y ago
    Rust aside, it uses a microkernel, multiserver architecture. And, of course, drivers run in userspace and interact with the system through a clearly defined API. Other systems like this include Robigalia, Lions OS and Genode. They would likely quickly overtake Linux if they got 1% of the resources Linux receives.
    - snvzz 2y ago
      Correction, where I said Robigalia I meant Managarm. Robigalia is also an effort, but one that hasn't been touched in nearly a decade.
- tatetian16 2y ago
  https://github.com/asterinas/asterinas https://github.com/asterinas/asterinas Asterinas is such an experiment. Purely written in Rust and Linux ABI compatible.
dinkumthinkum 2y ago
[flagged]
- actinium226 2y ago
  Genuinely curious, what book are you talking about?
- eviks 2y ago
  You could read books older than 2000+ years to realize this drama can't be avoided (though neither can this smug feel re other's ignorance)
- Ar-Curunir 2y ago
  Please enlighten us, oh knowledgeable one.
  - dinkumthinkum 2y ago
    Because the Rust used in the kernel is unsafe. All these people downvoting me or talking about 2000 year old books choosing to be maliciously ignorant, which is fine, I guess.
    - xondono 2y ago
      You have to be rage baiting to make an argument this bad. First, no, it’s not all unsafe, it’s not even 50% unsafe. Second, even 50% unsafe is an upgrade from 100% unsafe. The problem is that the R4L project is raising a lot of questions about how interfaces are handled by some Linux maintainers, and there’s definitely a difference in criteria when it comes to soundness bugs. I fall on the side that just because nobody has stepped on it on years isn’t a good excuse to keep landmines in the code, but clearly a lot of people in the kernel think differently.
    - goku12 2y ago
      By your logic, the entire Rust language and ecosystem would be considered unsafe. Even the Rust standard library is full of unsafe blocks and functions. But people don't consider it so, because Rust isn't about avoiding unsafe code. It's about containing unsafe code and presenting a safe wrapper by enforcing the invariants. This philosophy would have been abundantly clear if you cared to look at the patch [1] at the center of this controversy. Perhaps you should verify the validity and harmlessness of your own claims before accusing others. [1] https://lore.kernel.org/rust-for-linux/20250108122825.136021-3-abdiel.janulgue@gmail.com/ https://lore.kernel.org/rust-for-linux/20250108122825.136021...
nialv7 2y ago
Projects don't just live or die purely on technical merits. There are so many examples across history of this.
saghm 2y ago
Even if they made a fork and made it super great from a technical perspective, it still would face an uphill battle from the perspective of adoption. The amount of work to get people to switch over would be enormous, and the fact that there's at least some willingness on the part of Linux to adopt Rust in places makes me skeptical that there really would be less work to try to compete. I'd be thrilled if you're right though!
andreww591 2y ago
I'm a little bit skeptical as to how successful a hard fork of Linux that only differs from the mainline kernel by having a bit more Rust code actually would be. If you're going to rewrite significant parts of the kernel, you might as well do what I've been doing and try to write what amounts to a better Linux than Linux that tries to maintain compatibility, but moves beyond the rather limiting conventional Unix architecture. The conventional Unix architecture was fine on a something like a 70s/80s-era PDP-11/VAX, but in the modern world its limitations have been apparent for quite some time. What I've been working on is an OS very similar to QNX Neutrino in terms of general architecture, but with a somewhat different IPC protocol layering that reduces the number of user-visible primitives and allows for more consistent management of security. Most of the functionality of the system will be implemented in user-level server processes that export their services through special filesystems, with the only special/irregular parts of the system being the microkernel, the process manager (which also contains the core VFS and memory filesystems since these will be tightly linked to the process model), and the base syscall library (vaguely akin to the vDSO under Linux). Literally everything else will just be a regular process. It's not a "Rust OS" as such, as there will still be some C (for instance, the microkernel, which was forked from an older version of seL4), although it will have a fair bit of Rust code. IMO the issues with Linux are mostly due to a combination of poor/ad-hoc extensibility and the development model that's way too decentralized in some places but excessively centralized in others. The architecture I'm going with will allow for more experimentation, since adding functionality to it will typically just be a matter of adding a regular user program (or a plugin for a regular user program), and much of the system will be based around standardized filesystem-based RPC protocols (generic tooling for implementing RPC interfaces will of course be provided). Therefore it would be easier to maintain experimental functionality in a separate repository and merge it into the base system later on. Currently it's still quite preliminary, and it only runs some hardcoded tests built into the process server, although despite that, some developers from a major company have taken interest in it recently because of the possibility of using it as a replacement for QNX both in embedded systems and development workstations. I'm working on the VFS layer and built-in special filesystems at the moment, and hopefully should be able to get user processes running pretty soon. https://gitlab.com/uxrt/uxrt-toplevel https://gitlab.com/uxrt/uxrt-toplevel
eqvinox 2y ago
> Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning). Unfortunately, what Hector Martin was actually doing is producing rather spectacular flame on LKML and Mastodon. And he isn't representative of other Rust developers either, at least one has voiced their disagreement with him: https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phenom.ffwll.local/ https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen... I agree maintaining a fork would've been a more productive use of Hector's time, but that's not what has been happening and I see no reason to believe it is what will be happening from now on. From my own experience, personalities like Hector quit after not getting their way, rather than looking for other constructive options.
- nicce 2y ago
  > Now I'm left with the unlikely explanation that you just like thundering in as the cavalry, fashionably late, maximally destructive, because it entertains the masses on fedi or reddit or wherever. I have no idea what you're trying to achieve here, I really don't get it, but I am for sure fed up dealing with the fallout. That is a perfect description on what has been happening over the years.
stainablesteel 2y ago
completely agree on the fork side of things, just show its merits already or be done with it i think it's going to fail because of rust as a language, not because the ideas in rust are bad but because there's infinite complications
mmooss 2y ago
Who would use a kernel that is essentially the mainline kernel with more Rust? Would Debian or Red Hat use it? Maybe some very hard-core Rust hobbyists, but otherwise, why use the Rustier kernel? But if they could demonstrate significant improvements in security and stability, then they would have something to say. Maybe the plan should be to rewrite a component that the mainline maintainers wouldn't agree to - something important with a significant affect on security and stability. Yes, it's a risk, but if their claims for Rust are true, then it shouldn't be a problem. If Rust doesn't offer a major improvement then it isn't worth the effort anyway. Put their money (or time) where their mouth is.
- steveklabnik 2y ago
  There are drivers that exist only in Rust, so any distro that wants to support that hardware will. Like the Apple A3 silicon graphics driver. Iirc red hat and nvidia are also working on some Rust based drivers.
  - mmooss 2y ago
    Do the Rust drivers provide significant benefits over C equivalents (or over typical C drivers), enough to make it worth switching? Rust may have to really prove itself with results. And why shouldn't it?
    - steveklabnik 2y ago
      There are no C equivalents for the drivers I’m talking about.
      - mmooss 2y ago
        I got that - that's why I added the parenthetical. My point was the second sentence. Anyway, thanks for the input about the drivers. And for what it's worth, I expect Rust would offer significant improvements.
        2y ago

deleted 2y ago

[deleted]

gpm 2y ago

I think you're discounting the very real damage that would be done by Linux a project controlled by Linus and a community being replaced by Linux a project controlled by Google/Samsung/Redhat/Microsoft. I'm afraid that this is what is going to happen with the Linus tree effectively rejecting rust drivers by subjecting anyone attempting to upstream rust code to persistent bullying, but I don't want it to happen.

jeanlucas 2y ago
[flagged]
actinium226 2y ago
> I think you're discounting the very real damage that would be done by [Linux a project controlled by Linus and a community] being replaced by [Linux a project controlled by Google/Samsung/Redhat/Microsoft.] (Brackets added for clarity) Isn't the current Linux already Linus + communities + companies? More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
- gpm 2y ago
  > Isn't the current Linux already Linus + communities + companies? Absolutely. To that point the companies I listed are the ones that I'm aware of employing kernel developers who work specifically on rust in linux. The control of the project is in Linus's/community hands though, not corporate ones, and I think that's a good thing. > More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync. I don't think so. Linux is a huge modular system, and no one is really interested in rewriting the core components of it at this point. Nor maintaining their own copies of components that some other company is responsible for (like graphics drivers). Until and unless it became the dominant fork I'd expect that they'd keep merging in the mainline branch and updating their things as necessary. This is already how projects like Android work.
apatheticonion 2y ago
Does Linux have the ability to load drivers dynamically (like Windows)? Is there a reason why developers don't develop drivers outside of the kernel and have users simply install them post-install?
- sgerenser 2y ago
  It can, but Linux does not have a stable driver ABI. Whoever wrote the out-of-tree drivers would have to constantly update them whenever there was a breaking change to the kernel, which I understand is relatively common.
  - apatheticonion 2y ago
    That's interesting. Dumb question but why doesn't Linux aim for a stable driver ABI? Does it impede delivery speed? I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
    - DrillShopper 2y ago
      The rationale for not having a stable driver ABI is here: https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-... RE: nvidia - yes
    - gcr 2y ago
      nvidia uses "DKMS" to rebuild itself for each running kernel. Closed source modules like nvidia frequently have a kernel-independent proprietary piece and a kernel-specific (open source) ABI piece. Whenever you upgrade your kernel, DKMS will re-build the kernel-specific shim and re-link the proprietary blob. The result is a .ko tailor made for your running kernel, even though most of the code is in a kernel-independent blob.
      - DrillShopper 2y ago
        It looks like nVidia is open to moving their open driver (which requires a card that as a GSP) upstream [1] but with Rust being killed from the Linux kernel that's probably dead. [1] https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD
77pt77 2y ago
> controlled by Google/Samsung/Redhat/Microsoft. Can they do that to openssl instead? Thank you.
- gpm 2y ago
  They did: https://github.com/aws/aws-lc https://github.com/aws/aws-lc / https://github.com/google/boringssl https://github.com/google/boringssl (Not in rust, but it's mostly assembly anyways so I'm not sure rust provides much. There is https://github.com/briansmith/ring https://github.com/briansmith/ring in rust, not sure if it's sponsored by anyone)
hitekker 2y ago
> subject upstream rust code to persistent bullying I don’t remember seeing this bullying accusation in your original comment. Was it edited in? Regardless, the “bullying” happened on both sides. Hector Martin started the social media brigading and quit when he couldn’t get his personal enemy suspended for CoC violations. Jonathan Corbet wrote a letter naming and shaming maintainers, in the guise of a report. All in all, I agree with the GP. Most of the arguments against (even temporary) forking feel like excuses for a lack of will and a maybe even a lack of ability. The space is open for a fork.
- gpm 2y ago
  I may have edited the phrasing within a minute or two of posting, couldn't say. I haven't edited the comment in the 14 hours since then, and the sentiment was in the original. (I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)
dbcjv7vhxj 2y ago
Why do people think rejecting rust drivers is a bad thing? It's a fucking c project.

msgilligan 2y ago

I think a fork with a mission to aggressively rewrite the kernel into Rust would be a great experiment. Lessons learned could be applied to the more mainstream C/Rust kernel(s). Has anyone done that?

actinium226 2y ago
https://www.redox-os.org/ https://www.redox-os.org/ It's not a fork of Linux but a ground up effort to write a kernel in Rust. Still they're trying to make it compatible with Linux/BSD
- snvzz 2y ago
  Rust aside, it uses a microkernel, multiserver architecture. And, of course, drivers run in userspace and interact with the system through a clearly defined API. Other systems like this include Robigalia, Lions OS and Genode. They would likely quickly overtake Linux if they got 1% of the resources Linux receives.
  - snvzz 2y ago
    Correction, where I said Robigalia I meant Managarm. Robigalia is also an effort, but one that hasn't been touched in nearly a decade.
tatetian16 2y ago
https://github.com/asterinas/asterinas https://github.com/asterinas/asterinas Asterinas is such an experiment. Purely written in Rust and Linux ABI compatible.

dinkumthinkum 2y ago

[flagged]

actinium226 2y ago
Genuinely curious, what book are you talking about?
eviks 2y ago
You could read books older than 2000+ years to realize this drama can't be avoided (though neither can this smug feel re other's ignorance)
Ar-Curunir 2y ago
Please enlighten us, oh knowledgeable one.
- dinkumthinkum 2y ago
  Because the Rust used in the kernel is unsafe. All these people downvoting me or talking about 2000 year old books choosing to be maliciously ignorant, which is fine, I guess.
  - xondono 2y ago
    You have to be rage baiting to make an argument this bad. First, no, it’s not all unsafe, it’s not even 50% unsafe. Second, even 50% unsafe is an upgrade from 100% unsafe. The problem is that the R4L project is raising a lot of questions about how interfaces are handled by some Linux maintainers, and there’s definitely a difference in criteria when it comes to soundness bugs. I fall on the side that just because nobody has stepped on it on years isn’t a good excuse to keep landmines in the code, but clearly a lot of people in the kernel think differently.
  - goku12 2y ago
    By your logic, the entire Rust language and ecosystem would be considered unsafe. Even the Rust standard library is full of unsafe blocks and functions. But people don't consider it so, because Rust isn't about avoiding unsafe code. It's about containing unsafe code and presenting a safe wrapper by enforcing the invariants. This philosophy would have been abundantly clear if you cared to look at the patch [1] at the center of this controversy. Perhaps you should verify the validity and harmlessness of your own claims before accusing others. [1] https://lore.kernel.org/rust-for-linux/20250108122825.136021-3-abdiel.janulgue@gmail.com/ https://lore.kernel.org/rust-for-linux/20250108122825.136021...

nialv7 2y ago

Projects don't just live or die purely on technical merits. There are so many examples across history of this.

saghm 2y ago

Even if they made a fork and made it super great from a technical perspective, it still would face an uphill battle from the perspective of adoption. The amount of work to get people to switch over would be enormous, and the fact that there's at least some willingness on the part of Linux to adopt Rust in places makes me skeptical that there really would be less work to try to compete. I'd be thrilled if you're right though!

andreww591 2y ago

I'm a little bit skeptical as to how successful a hard fork of Linux that only differs from the mainline kernel by having a bit more Rust code actually would be. If you're going to rewrite significant parts of the kernel, you might as well do what I've been doing and try to write what amounts to a better Linux than Linux that tries to maintain compatibility, but moves beyond the rather limiting conventional Unix architecture. The conventional Unix architecture was fine on a something like a 70s/80s-era PDP-11/VAX, but in the modern world its limitations have been apparent for quite some time. What I've been working on is an OS very similar to QNX Neutrino in terms of general architecture, but with a somewhat different IPC protocol layering that reduces the number of user-visible primitives and allows for more consistent management of security. Most of the functionality of the system will be implemented in user-level server processes that export their services through special filesystems, with the only special/irregular parts of the system being the microkernel, the process manager (which also contains the core VFS and memory filesystems since these will be tightly linked to the process model), and the base syscall library (vaguely akin to the vDSO under Linux). Literally everything else will just be a regular process. It's not a "Rust OS" as such, as there will still be some C (for instance, the microkernel, which was forked from an older version of seL4), although it will have a fair bit of Rust code. IMO the issues with Linux are mostly due to a combination of poor/ad-hoc extensibility and the development model that's way too decentralized in some places but excessively centralized in others. The architecture I'm going with will allow for more experimentation, since adding functionality to it will typically just be a matter of adding a regular user program (or a plugin for a regular user program), and much of the system will be based around standardized filesystem-based RPC protocols (generic tooling for implementing RPC interfaces will of course be provided). Therefore it would be easier to maintain experimental functionality in a separate repository and merge it into the base system later on. Currently it's still quite preliminary, and it only runs some hardcoded tests built into the process server, although despite that, some developers from a major company have taken interest in it recently because of the possibility of using it as a replacement for QNX both in embedded systems and development workstations. I'm working on the VFS layer and built-in special filesystems at the moment, and hopefully should be able to get user processes running pretty soon. https://gitlab.com/uxrt/uxrt-toplevel https://gitlab.com/uxrt/uxrt-toplevel

eqvinox 2y ago

> Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning). Unfortunately, what Hector Martin was actually doing is producing rather spectacular flame on LKML and Mastodon. And he isn't representative of other Rust developers either, at least one has voiced their disagreement with him: https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phenom.ffwll.local/ https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen... I agree maintaining a fork would've been a more productive use of Hector's time, but that's not what has been happening and I see no reason to believe it is what will be happening from now on. From my own experience, personalities like Hector quit after not getting their way, rather than looking for other constructive options.

nicce 2y ago
> Now I'm left with the unlikely explanation that you just like thundering in as the cavalry, fashionably late, maximally destructive, because it entertains the masses on fedi or reddit or wherever. I have no idea what you're trying to achieve here, I really don't get it, but I am for sure fed up dealing with the fallout. That is a perfect description on what has been happening over the years.

stainablesteel 2y ago

completely agree on the fork side of things, just show its merits already or be done with it i think it's going to fail because of rust as a language, not because the ideas in rust are bad but because there's infinite complications

mmooss 2y ago

Who would use a kernel that is essentially the mainline kernel with more Rust? Would Debian or Red Hat use it? Maybe some very hard-core Rust hobbyists, but otherwise, why use the Rustier kernel? But if they could demonstrate significant improvements in security and stability, then they would have something to say. Maybe the plan should be to rewrite a component that the mainline maintainers wouldn't agree to - something important with a significant affect on security and stability. Yes, it's a risk, but if their claims for Rust are true, then it shouldn't be a problem. If Rust doesn't offer a major improvement then it isn't worth the effort anyway. Put their money (or time) where their mouth is.

steveklabnik 2y ago
There are drivers that exist only in Rust, so any distro that wants to support that hardware will. Like the Apple A3 silicon graphics driver. Iirc red hat and nvidia are also working on some Rust based drivers.
- mmooss 2y ago
  Do the Rust drivers provide significant benefits over C equivalents (or over typical C drivers), enough to make it worth switching? Rust may have to really prove itself with results. And why shouldn't it?
  - steveklabnik 2y ago
    There are no C equivalents for the drivers I’m talking about.
    - mmooss 2y ago
      I got that - that's why I added the parenthetical. My point was the second sentence. Anyway, thanks for the input about the drivers. And for what it's worth, I expect Rust would offer significant improvements.
      - 2y ago