Announcement

Collapse
No announcement yet.

Redox OS Working On NVMe, USB 3.0, Theme Support

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

  • Redox OS Working On NVMe, USB 3.0, Theme Support

    Phoronix: Redox OS Working On NVMe, USB 3.0, Theme Support

    For those interested in the Rust-written Redox OS open-source operating system project, a brief status update was posted today...

    http://www.phoronix.com/scan.php?pag...VMe-USB3-Theme

  • #2
    I wouldn't be against moving to a microkernel, but I would like (almost) complete compatibility with the Linux userspace.
    However, this does not seem to be one of the stated goals. Or is it? It would be nice to run mesa on it, for example (though there are also the kernel modules to port; a nice feature would be to be able to translate kernel modules to be Redox-compatible with corrode).

    Comment


    • #3
      Jumping from one operating system to another is a big hurdle and going from zero to an established operating system can take a long time and needs momentum.
      If the whole selling point is "its written in Rust" that might not be so convincing to end-users.

      Rewriting parts of Linux in Rust would probably be more fruitful and make more sense.
      Rust is awesome for parsers and decoders.

      Comment


      • #4
        Originally posted by uid313 View Post
        If the whole selling point is "its written in Rust" that might not be so convincing to end-users.
        Redox is not just "Linux" written in Rust, first of all it is different architecture, it's microkernel and because of that it offers stability, no driver can crush the system, since drivers are not part of the kernel any more. Redox provide great isolation of system processes so any security breaches won't spread as easily as on Linux (or Win, or BSD) through whole system.

        "It's written in Rust" thing gives something else: memory safety - in short, in Rust you can't create such bugs as "Dirty Cow" or "Heartbleed". (OK, you can, but you have to use 'unsafe' each time, and you can check ten times those parts, in C each line is 'unsafe'). Linux is 25 millions line of C code - it is impossible to ensure memory safety with human eye only... there are literally thousands of bugs like Dirty Cow in Linux...

        Originally posted by uid313 View Post
        Rewriting parts of Linux in Rust would probably be more fruitful and make more sense.
        This would be complete waste of time and resources, You wouldn't gain any of advantage over present solution, you would end up with just copy of Linux...

        And compatibility with Linux is a thing for Redox, in a way, that you could easily run programs form Linux/Unix... (except of that which are using any Linux kernel features directly, 99% of software don't care on what kernel they are running)

        Comment


        • #5
          Originally posted by uid313 View Post
          Jumping from one operating system to another is a big hurdle and going from zero to an established operating system can take a long time and needs momentum.
          If the whole selling point is "its written in Rust" that might not be so convincing to end-users.

          Rewriting parts of Linux in Rust would probably be more fruitful and make more sense.
          Rust is awesome for parsers and decoders.
          One of your previous comments was on this article: https://www.phoronix.com/forums/foru...eged-processes

          "How can this be prevented in the future?"

          One way of preventing double-free kernel vulnerabilities is to move kernel code into userspace, so that failures will be isolated. Redox does this by moving the majority of OS drivers and services to userspace.

          Another is to use a language that statically disallows double frees, and other memory errors. Redox does this by using Rust.

          The selling point is reliability - Redox avoids common sources of security vulnerabilities and crashes with a different architectural design.

          Comment


          • #6
            Originally posted by uid313 View Post
            Jumping from one operating system to another is a big hurdle and going from zero to an established operating system can take a long time and needs momentum.
            If the whole selling point is "its written in Rust" that might not be so convincing to end-users.

            Rewriting parts of Linux in Rust would probably be more fruitful and make more sense.
            Rust is awesome for parsers and decoders.
            Although I see your point and agree with it, the message you are sending isn't really helping any one, except for the people who doesn't see that as stating the obvious. Those people aren't reading this new site anyway and probably wont even know how to begin using this new operating system.
            Personally I wish these guys god speed with their project and might even want to join them in their efforts.

            It's my personal experience that the features that Rust provides over C is the same features that speed up development in higher level languages. However Microkernel designs have a tendency to complicate things and retard development speed. Considering that they already have Filesystem, GUI and networking running in the short time that they have used, I am positive.

            Comment


            • #7
              Originally posted by pracedru View Post

              Although I see your point and agree with it, the message you are sending isn't really helping any one, except for the people who doesn't see that as stating the obvious. Those people aren't reading this new site anyway and probably wont even know how to begin using this new operating system.
              Personally I wish these guys god speed with their project and might even want to join them in their efforts.

              It's my personal experience that the features that Rust provides over C is the same features that speed up development in higher level languages. However Microkernel designs have a tendency to complicate things and retard development speed. Considering that they already have Filesystem, GUI and networking running in the short time that they have used, I am positive.
              I think it would be more worthwhile to port Wayland or ext4 from C to Rust.
              They can start by rewriting parts of the Linux kernel (such a ext4) in Rust.

              Also the GUI isn't terribly useful thing to write in Rust. What would really benefit to write in Rust are decoders and parsers, example FFmpeg and GStreamer or a SSH daemon or a TLS library.

              Comment


              • #8
                Originally posted by uid313 View Post

                I think it would be more worthwhile to port Wayland or ext4 from C to Rust.
                They can start by rewriting parts of the Linux kernel (such a ext4) in Rust.

                Also the GUI isn't terribly useful thing to write in Rust. What would really benefit to write in Rust are decoders and parsers, example FFmpeg and GStreamer or a SSH daemon or a TLS library.
                There's little reason to rewrite ext4 in Rust. Ticki is already working on a superior filesystem, named TFS. TFS has lead to the creation of a handful of key crates for the Rust ecosystem that benefits all software written in Rust, not just TFS, such as concurrent hash maps, SeaHash, and LZ4 -- one of the key advantages of Rust's Cargo ecosystem. Filesystems written from scratch in Rust, like kernels and other kinds of software, can achieve production-grade status significantly quicker than those written in C/C++, and do so with better designs and significantly less bugs. It would take far longer to rewrite something than to create something new, as a result.

                Additionally, as for SSH we already have Thrussh; for TLS we already have Rustls; and for de/serializers there's Serde, of which a plethora of parsers have been built upon it. The ffmpeg and gstreamer projects are free to take advantage of Rust whenever they see fit -- the tools are there. Mozilla's already doing this for Firefox at a limited scale for parsing MP4 metadata.

                Comment


                • #9
                  How does NetBSD's Rumpkernel compete ?

                  Comment

                  Working...
                  X