Announcement

Collapse
No announcement yet.

Redox OS Exploring Coreboot Payload, Other Improvements

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

  • Redox OS Exploring Coreboot Payload, Other Improvements

    Phoronix: Redox OS Exploring Coreboot Payload, Other Improvements

    It's been a while since last having anything significant to report on Redox OS, the Unix-like operating system written in the Rust programming language and pursuing a micro-kernel design, but fortunately this open-source OS is still moving along and they have some interesting plans moving forward...

    http://www.phoronix.com/scan.php?pag...-February-2019

  • #2
    A wayland implementation would be cool. This might ease porting applications with an GUI.

    Comment


    • #3
      Or a Raspberri Pi Version.

      Comment


      • #4
        Even if this would be the best OS base in the world, would anyone be able to run it? As in, what's the driver state?

        Comment


        • #5
          Originally posted by Steffo View Post
          A wayland implementation would be cool. This might ease porting applications with an GUI.
          Why go though XWayland when just an implementation of X11 would be faster and have more GUI applications available to it?

          Basically, standards generally take priority. Niche Linux compatibility can wait!

          Originally posted by Compartmentalisation View Post
          Even if this would be the best OS base in the world, would anyone be able to run it? As in, what's the driver state?
          I suppose if it can be supported by the main VM systems like VirtualBox, then that is actually a good start for user uptake.
          Last edited by kpedersen; 02-23-2019, 05:42 PM.

          Comment


          • #6
            Originally posted by kpedersen View Post
            I suppose if it can be supported by the main VM systems like VirtualBox, then that is actually a good start for user uptake.
            Yes great point! Virtualised environments. I was looking more into the Gen2 Hyper-V/Azure environments where Clear is doing really well aside from their updates (while delta updates, they're so frequent compared to Debian). Targeting a virtualised environment means you don't need that driver support. But what big advantage does Redox give at that point? Software still keeps focusing Linux since the '00s, and an updated CentOS/Debian/Ubuntu VM has both security through other people using it, and performance is not as big.

            Also, since about 3 days ago, I've conveniently seen some companies doing taxes going for upwards of €5000+ per hour billing VMs so those proven VMs are getting some attraction on the big money market.

            Comment


            • #7
              Originally posted by Compartmentalisation View Post
              But what big advantage does Redox give at that point?
              At the moment, possibly not much, it is a research project to see if Rust can be a successful systems language. As a C and C++ developer, I see why native languages are the only choice in operating system development but I also see how C and C++ in particular open us up to errors which could be easily avoided by simply using a safer language instead. Rust is potentially a language which is best of both worlds. Safe and native.

              I am not so sure I am convinced yet, but that is why this project is quite important to me. To find out if Rust really is the solution.

              Originally posted by Compartmentalisation View Post
              Software still keeps focusing Linux since the '00s.
              Yep, and before that, everyone was obsessed with Windows. And before that everyone was obsessed with proprietary UNIX. These things do change. When Linux dies, perhaps RedoxOS will be the project that picks up the slack?
              Last edited by kpedersen; 02-23-2019, 06:35 PM.

              Comment


              • #8
                Originally posted by kpedersen View Post
                I am not so sure I am convinced yet, but that is why this project is quite important to me. To find out if Rust really is the solution.
                My issue with Rust is parent-child relationship which can't be implemented "natively", either use Rc<RefCell<>> + Weak<RefCell<>>, or a third party library that does God knows what under the hood. I wonder how Redox implements its parent-child logic if any.

                Comment


                • #9
                  Originally posted by kpedersen View Post

                  Why go though XWayland when just an implementation of X11 would be faster and have more GUI applications available to it?

                  Basically, standards generally take priority. Niche Linux compatibility can wait!
                  The stated goal of Redox is to have an OS written in Rust. X11 isn't written in Rust, it has a massive codebase, and it is legacy now. So porting it would be a mammoth task and be incredibly dumb. Whereas Wayland is a relatively small protocol, they could easily write something in Rust that could use it. I'm not saying they should, but Wayland is at least an option.

                  Comment


                  • #10
                    Originally posted by cl333r View Post

                    My issue with Rust is parent-child relationship which can't be implemented "natively", either use Rc<RefCell<>> + Weak<RefCell<>>, or a third party library that does God knows what under the hood. I wonder how Redox implements its parent-child logic if any.
                    Use unsafe and raw pointers if you want. That's what C and 1990s C++ do and what "Rc<RefCell<>> + Weak<RefCell<>>" does internally. Rust is just following what modern C++ encourages as best practices via types like std::shared_ptr<T> (C++'s Rc and, when used differently, Arc) and std::atomic<std::shared_ptr<T>> (C++'s Arc as of the in-development C++20 standard).

                    Prior to version 1.0, Rust actually had a garbage-collected pointer sigil (@ instead of & or *) but it was converted into the Rc and Arc standard library types as part of the effort to not specially privilege things which, algorithmically, are just standard library types.

                    (Which, for that matter, granted the added benefit of being able to explicitly choose between the minor performance boost of not using atomics (Rc) and the support for multi-threaded access that comes from using atomics (Arc)... or various other kinds of pointers from crates.io)

                    Rust is a victim of its own success if you're complaining that its compile-time prover for the correctness of single-ownership access (something no other language has yet, though Ada is working on it) isn't smart enough to prove correctness of multi-ownership access at compile time... something which may be impossible at a theoretical level.

                    That said, I'm not immune to that either. I come in from Python, which is horrendously slow by comparison, everything is wrapped in an Rc<T> and heap allocated, and the language uses a Global Interpreter Lock because putting everything in Arc<T> would be too slow, and, before you can blink, I'm grumbling about the complexity of making certain things purely stack-allocated and singly-owned with minimal copying. Rust just makes it so nice most of the time, that you don't want to resort to what GCed languages do under the hood all the time.

                    Comment

                    Working...
                    X