Announcement

Collapse
No announcement yet.

FSF-Approved Hyperbola GNU/Linux Switching Out The Linux Kernel For Hard Fork Of OpenBSD

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • FSF-Approved Hyperbola GNU/Linux Switching Out The Linux Kernel For Hard Fork Of OpenBSD

    Phoronix: FSF-Approved Hyperbola GNU/Linux Switching Out The Linux Kernel For Hard Fork Of OpenBSD

    In a rather unusual twist, the Hyperbola GNU/Linux distribution that is approved by the Free Software Foundation for being free software and making use of the Linux-libre kernel has now decided they are going to fork OpenBSD and become a BSD...

    http://www.phoronix.com/scan.php?pag...a-Linux-To-BSD

  • #2
    Coming soon to a testing VM near you:

    Hyperbole BSD

    Not a typo.

    Comment


    • #3
      That is a bit strange. While some aspects of Linux development might need improvement I’d have to say that they are at least exploring the required improvements. Rust is a perfect example of research into better ways to do things. I’m not saying a Rust is the best choice but it’s use could do much for driver quality.

      Comment


      • #4
        Originally posted by wizard69 View Post
        Rust is a perfect example of research into better ways to do things. I’m not saying a Rust is the best choice but it’s use could do much for driver quality.
        The safety of Rust would be very nice to have in a kernel. But...

        Rust is basically useless without Cargo and the cluster fsck web development approach dragging in dependencies left, right and center is not good for operating system development anyway.

        "Rust drivers" would need a fairly large binding layer to interface with the C within the kernel. This would be a massive time sink. Much of it would have to be marked "unsafe" anyway, reducing the whole point of Rust.

        C++ can be safer than C in similar ways to Rust but not even that (even being based on C) has managed to get a foot hold after all these years. Rust has very little chance until at least C++ has had a go in kernel-land :/
        Last edited by kpedersen; 12-23-2019, 07:52 PM.

        Comment


        • #5
          I don't get why would they do that...

          Originally posted by phoronix View Post
          They attribute this supposed downfall of the Linux kernel to be due to adopting Digital Rights Manager / HDCP content protection,
          Couldn't you fork the Linux kernel and remove such bits if you hate them so much instead of moving to a different kernel?

          Originally posted by phoronix View Post
          proposed usage of Rust,
          It is a proposal, come on. It has not happened and I do not think it will happen.

          Originally posted by phoronix View Post
          and applications/user-space forcing the usage of PulseAudio / systemd / Rust / Java.
          What is wrong with that?

          ...plus... "Java"? What Java? Are you crazy?

          Comment


          • #6
            So they're upset that something called technological progress happens?

            Comment


            • #7
              Their complaints here just seem bizarre. I guess I see their point about DRM in the kernel; that's clearly objectionable under their project's goals. But is there any reasonable interpretation to the complaint about "applications/user-space forcing the usage of PulseAudio / systemd / Rust / Java."? I don't think the Linux kernel, coreutils, etc. require any of these things. As far as applications, you'd probably be using the same applications with a BSD kernel. Either the same requirements would exist, or the application probably wouldn't work on BSD at all.

              Originally posted by kpedersen View Post
              Rust is basically useless without Cargo and the cluster fsck web development approach dragging in dependencies left, right and center is not good for operating system development anyway.

              "Rust drivers" would need a fairly large binding layer to interface with the C within the kernel. This would be a massive time sink. Much of it would have to be marked "unsafe" anyway, reducing the whole point of Rust.
              /
              I don't really see the problem with cargo. It's perfectly possible to not have any dependencies other than the code you have in tree, just using cargo as a build system. Of course, you might have to implement a lot of things if you're not pulling in third party dependencies, but that's already how the Linux kernel works so it doesn't seem like a fundamental problem at all.

              That it would be a "massive time sync" to provide full idiomatic Rust bindings for kernel APIs seems pretty undeniable, anyway. It would be a massive project, even if useful.

              Comment


              • #8
                Wait, is it April 1st yet? ;-)

                Comment


                • #9
                  Originally posted by kpedersen View Post
                  Rust is basically useless without Cargo and the cluster fsck web development approach dragging in dependencies left, right and center is not good for operating system development anyway.
                  Unless I'm mistaken, a kernel cannot have any dependency because of obvious reasons, and therefore Rust would also not use Cargo at all for the kernel development.

                  "Rust drivers" would need a fairly large binding layer to interface with the C within the kernel. This would be a massive time sink. Much of it would have to be marked "unsafe" anyway, reducing the whole point of Rust.
                  Unless you rewrite all in Rust. Rewriting all in rust is always the solution.

                  Comment


                  • #10
                    Fishing for the intersection of anti-systemd, anti-linux and anti-rust trolls?
                    Gonna be a lonesome Christmas for hyperboles (that the plural for hyperbola users? )
                    Last edited by discordian; 12-23-2019, 08:38 PM.

                    Comment

                    Working...
                    X