• ferric_carcinization@lemmy.ml
    link
    fedilink
    English
    arrow-up
    18
    ·
    3 days ago

    Does it have to be Linux? Some greybeards are pretty opposed to it. I wonder if it would be easier to make our own theme park kernel with blackjack and hookers memory and thread safety, like Redox.

    • patatahooligan@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 day ago

      Does it have to be Linux?

      In order to be a viable general use OS, probably yes. It would be an enormous amount of effort to reach a decent range of hardware compatibility without reusing the work that has already been done. Maybe someone will try something more ambitious, like writing a rust kernel with C interoperability and a linux-like API so we can at least port linux drivers to it as a “temporary” solution.

      • ferric_carcinization@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        9 hours ago

        I remember there being a bit of talk around a Linux driver compatibility layer for Redox in the future, but I can’t find anything about it, so I could be misremembering.

        What do you mean by “C interoperability and a linux-like API”, exactly?

        1. C is pretty much the standard for FFI, you can use C libraries with Rust and Redox even has their own C standard library implementation.
        2. Linux does not have a stable kernel API as far as I know, only userspace API & ABI compatibility is guaranteed.
        • patatahooligan@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          8 hours ago

          C is pretty much the standard for FFI, you can use C libraries with Rust and Redox even has their own C standard library implementation.

          Right, but I’m talking specifically about a kernel which supports building parts of it in C. Rust as a language supports this but you also have to set up all your processes (building, testing, doc generation) to work with a mixed code base. To be clear, I don’t image that this part is that hard. When I called this a “more ambitious” approach, I was mostly referring to the effort of maintaining forks of linux drivers and API compatibility.

          Linux does not have a stable kernel API as far as I know, only userspace API & ABI compatibility is guaranteed.

          Ugh, I forgot about that. I wonder how much effort it would be to keep up with the linux API changes. I guess it depends on how many linux drivers you would use, since you don’t need 100% API compatibility. You only need whatever is used by the drivers you care about.