1. 5

    Redox is not a particularly good example of operating system design

    A bold claim that I’d be curious to hear sustantiated.

    1. 4

      Someone on the reddit post asked much the same thing. Here’s my reply:

      Sure thing. I’m not saying that Redox isn’t a great thing. It was the first project to seriously open up the possibility of writing operating systems in Rust and I will forever be thankful to it for that.

      To elaborate on bad design: there are a number of questionable (at least to me) design decisions. For example, why are schemes designed the way they are? It seems to me like if they want to change the api between usermode and the kernel, they should either go all the way or none of it. Schemes change it a bit, but they don’t reconsider and fix bad design choices in posix and linux.

      Furthermore, Redox is simply not designed for performance. Even the scheduler, one of the most important contributors to the overall performance of a system does far more work than necessary. It exchanges performance for slightly more simplicity, which, when designing an operating system, is rarely the correct choice.

      1. 1

        I don’t understand how it’s possible pick three here: “full-native speed”, single address space OS (everything in ring 0) and security. I believe you can only pick two.

        1. 1

          Well, that’s what nebulet is trying to challenge.

            1. 1

              I haven’t yet read the whole paper but in the conclusion they say that performance was a non-goal. They “also improved message-passing performance by enabling zero-copy communication through pointer passing”. Although I don’t see why zero-copy IPC can’t be implemented in a more traditional OS design.

              The only (performance-related) advantage such design has in my opinion is cheaper context-switching, but I’m not convinced it’s worth it. Time (and benchmarks) will show, I guess.

              1. 1

                When communication across processes becomes cheaper than posting a message to a queue belonging to another thread in the same process in a more traditional design, I’d say that that’s quite a monstrous “only” benefit.

                I should have drawn your attention to section 2.1 in the original comment, that’s where you original query is addressed. Basically the protection comes from static analysis, a bit like the original Native Client or Java’s bytecode verifier