Linux maintainers are unwilling to get rust into the kernel, so some rust folks decided to start writing a new kernel with same ABI. This allows them to make new architectural decisions. An example being their “frame kernel” (something between a monolithic kernel and a microkernel).

If I may say, it’s more legible and the tooling is way better, right off the bat.

  • Scoopta@programming.dev
    link
    fedilink
    arrow-up
    7
    ·
    3 months ago

    Eh? I daily drive only FOSS software with basically no problems, the only exception I make is for firmware and JS, firmware because it’s realistically not a choice and JS because it’s extremely sandboxed and I use librewolf with container tabs to isolate cookies etc cross sites, even drivers are not exempt from this rule. FOSS specifically being programs under a GNU approved free software license or software found in the Debian main repos and therefore complying with the DFSG. It’s, surprisingly easy. In fact when I made the decision to do this it was primarily because I needed so little proprietary software that it just wasn’t even much of a challenge?? I guess my main point in saying this is I don’t get where you’re coming from, I’d love a Linux phone but it’s not realistic there, but on the desktop? It’s extremely realistic??

    • adr1an@programming.devM
      link
      fedilink
      arrow-up
      5
      ·
      3 months ago

      Linux made huge strides in the last years. But if we go back 10 years, or 15 things were quite bleak. And there are many reasons to that. It’s license is one. That’s my point. Correct or not, okay.

      And Linux never embraced GPLv3 for reasons that are in common probably as to why this project chose a permissive license. So, I think we should all support them in that regard.

      • Scoopta@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        3 months ago

        The decision not to support GPLv3 makes sense and I understand Linus’ perspective on that. GPLv3 branched out into something beyond traditional copy left by ensuring that users can run the modified code by restricting hardware design. That’s a separate thing. I disagree with the decision to go with a permissive license in most cases including this one. Permissive licensing leads to the problems the BSDs have with companies like Sony taking the code and running with it without giving back and it’s why I prefer strong copy left licenses like GPLv2 or v3.

        One other thing, yes it was rough in the past but now due to the massive market penetration Linux has we have a large swath of GPLv2 drivers making it far less of a relevant issue.

        • adr1an@programming.devM
          link
          fedilink
          arrow-up
          2
          ·
          3 months ago

          We can’t really know if BSD “lost” a sell to Sony. Right? I ask sincerely, maybe there’s more to the case you cited.

          From my naïve view, this new project can win new associated companies and get some income to pay new devs when some maturity is achieved on this framework since it’s quite innovative and those companies can really participate whereas with a GPL they would just be left out.

          I only mean to say that we might be discussing if the glass is half empty or half full. That’s why I’m trying to put into this new perspective (like considering GrapheneOS as an example. In the long run, the license might not be that much of a hurdle. At least let’s hope that’s the case since they probably won’t change to GPL.