4 ms·

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 cont

by 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.

by gpm 2y ago

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.