3 ms·

I agree with you completely. If rust is so great why not make a new kernel with it and compete? or fork and start rewriting subsystems? I do also understand th

I agree with you completely. If rust is so great why not make a new kernel with it and compete? or fork and start rewriting subsystems? I do also understand the frustration when an open source project strings you along (me: can I join your club?), ask for this and that (them: sure if you pay your dues), ensuring your cover every "important" person's pet use case (them: and also buy us lunch), then publicly snark about the whole thing (them: this new guy know about no mustard on the lunch!) and kill your failing motivation (me: oh, sorry). That's why the fork is so appealing. If it's good enough for long enough you get to join the club.

llm_trw 2y ago
What I don't get is the complaints from the Rust people. If Rust truly is zero overhead on the C side of things then they should be just able to fork Linux indefinitely without any worry about what upstream does. Just fast forward every change and you're golden. Then they can write every driver they can imagine to their hearts' content. The fact they aren't doing this tells me that the promise that this won't impact C people at all isn't much of one.
- MyOutfitIsVague 2y ago
  The problem is that they might want their drivers to actually work on people's existing Linux systems without having to force them to use a forked kernel. It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.
  - llm_trw 2y ago
    What extra effort? If you match upstream it's a drop in replacement and anyone who cares will use it. If they don't it's because they don't care.
    - dralley 2y ago
      "if you match upstream" Talk about aggressively missing the point.
      - llm_trw 2y ago
        Explain what the point is. Rust developers are promising that rust in the kernel should have no impact on c in the kernel. If rust in the kernel has no impact in c then you should be able to remove the rust from the kernel and move it to it's own project, since it will have no impact on the c either way.
    - MyOutfitIsVague 2y ago
      And what if they do care, but they simultaneously need features available in multiple different forks? You can't run two kernels at the same time.
      - llm_trw 2y ago
        Then it means the rust code does impact the C code and the rust people were lying.
        MyOutfitIsVague 2y ago
        That doesn't make sense, and you can look at the patches and see that the Rust code didn't impact the C code. It's not like we have to take anybody's word for it. This is primarily around Rust filesystem drivers. If you want to run a filesystem but it's implemented in Rust, you'd have to use that fork. If another person had the same issue (say a GPU driver that some maintainer decided they didn't like because of the country of origin or some other petty reason), then that would have to be a fork as well. Suddenly, you can't use that GPU with a Rust-implemented filesystem, because you have to pick one of the forks, or you have to make your own merged kernel from the two. "Just fork it" doesn't work here. It's a logistical nightmare.
        2y ago
  - liveoneggs 2y ago
    Linux is the most important open source project ever. The barrier to entry is, actually, shockingly low.

llm_trw 2y ago

What I don't get is the complaints from the Rust people. If Rust truly is zero overhead on the C side of things then they should be just able to fork Linux indefinitely without any worry about what upstream does. Just fast forward every change and you're golden. Then they can write every driver they can imagine to their hearts' content. The fact they aren't doing this tells me that the promise that this won't impact C people at all isn't much of one.

MyOutfitIsVague 2y ago
The problem is that they might want their drivers to actually work on people's existing Linux systems without having to force them to use a forked kernel. It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.
- llm_trw 2y ago
  What extra effort? If you match upstream it's a drop in replacement and anyone who cares will use it. If they don't it's because they don't care.
  - dralley 2y ago
    "if you match upstream" Talk about aggressively missing the point.
    - llm_trw 2y ago
      Explain what the point is. Rust developers are promising that rust in the kernel should have no impact on c in the kernel. If rust in the kernel has no impact in c then you should be able to remove the rust from the kernel and move it to it's own project, since it will have no impact on the c either way.
  - MyOutfitIsVague 2y ago
    And what if they do care, but they simultaneously need features available in multiple different forks? You can't run two kernels at the same time.
    - llm_trw 2y ago
      Then it means the rust code does impact the C code and the rust people were lying.
      - MyOutfitIsVague 2y ago
        That doesn't make sense, and you can look at the patches and see that the Rust code didn't impact the C code. It's not like we have to take anybody's word for it. This is primarily around Rust filesystem drivers. If you want to run a filesystem but it's implemented in Rust, you'd have to use that fork. If another person had the same issue (say a GPU driver that some maintainer decided they didn't like because of the country of origin or some other petty reason), then that would have to be a fork as well. Suddenly, you can't use that GPU with a Rust-implemented filesystem, because you have to pick one of the forks, or you have to make your own merged kernel from the two. "Just fork it" doesn't work here. It's a logistical nightmare.
        2y ago
- liveoneggs 2y ago
  Linux is the most important open source project ever. The barrier to entry is, actually, shockingly low.