No announcement yet.

Rust-Written Redox OS 0.8 Released With i686 Support, Audio & Multi-Display Working

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    I remember how long it took NetBSD to get USB 3 support, it didn't come out till version 7 or 8 I can't remember and it has a small team working on it. 10.0 will be the first version with Linux 5.4 DRM, which is almost 2 LTS old now. Redox will take some time to implement just USB 2.0 or even 1.1 rather yet USB 3 or 4. I wish them all the best. It is nice to see OpenBSD get some competition in the secure OS arena. Genode with its micro kernel and Redox with its RUST kernel will keep things interesting. But until you can throw it on a commodity laptop it will remain a niche OS. Not to offend anyone, but even the biggest two *BSDs FreeBSD and OpenBSD have trouble running on some Business laptops: case in point I bought a ThinkPad for OpenBSD use and immediately had to swap the wi-fi card to an Intel model so it would be supported.


    • #32
      Originally posted by zexelon View Post

      That is such a non-informed response.

      Suggested reading:
      In the end it doesn't really matter. Both OSs have admirable goals. I have followed ReactOS for many years now and it still has many years to go before even reaching their stated WIndows XP level of compatibility. RedoxOS is not going to be encumbered by any of that. They will however 100% have the hardware compatibility issues that took Linux decades to overcome, unless they can come up with some sort of "shim" design to maybe load Linux driver modules... it would be ugly as sin and I am sure an angel would loose its wings over it, but it would at least help with the driver side of things.
      Redox is an attempt to make a complete, fully-functioning, general-purpose operating system with a focus on safety, freedom, reliability, correctness, and pragmatism.
      To me it is suspicious that they didn't include "performance" as part of their main goals, they might not be able to closely match Linux performance-wise later on.


      • #33
        Originally posted by mirmirmir View Post

        "your dumb" is not an argument, quoting the guy who made the claim is not convincing.

        ok, let's see what we got,
        • general computing is not a problem to solve, it's already done by everyone and a handful of them are already succeed.
        • they are not trying to reinvent everything? sounds like someone was high on copium writing that
        • and the rest? technicality shouldn't be treated as goals, telling people what MIT license is not an explanation to their project's philosophy either
        and i feel stupid to respond to you. i shouldn't have wasted time in here
        My apologies, in no way did I mean to imply "your dumb" and did not use that wording. There is a very large gulf between dumb and un-informed.

        I would suggest that "general computing" is a never ending "problem" if you will. Technically ENIAC solved the "general computing" problem in the mid 1940s. Everything since then has been innovation. Redox OS does not state anywhere that I can find that they are going to "solve general computing". They are going to innovate... and hopefully significantly!

        Most of the rest of the OS is designed around various paradigms that have been in computing for many years now. One of the more interesting possible innovations (or total failures... still waiting to see) is the idea that everything is a URI instead of the *nix everything is a file.


        • #34
          Originally posted by cl333r View Post

          To me it is suspicious that they didn't include "performance" as part of their main goals, they might not be able to closely match Linux performance-wise later on.
          Yah, thats a touchy subject. I mean its sort of a given that on some level performance is always the goal in software... but Redox OS has some hills to climb on this front. The architecture that they have chosen to base the OS on has historically struggled with performance issues. Quite a few of the major ones have been addressed in recent years, and the "memory safe" nature of Rust may allow them to bypass some of the checks and balances that slowed down this architecture before.

          But all of that is in the future and can only be guessed at.
          Last edited by zexelon; 24 November 2022, 01:28 PM. Reason: Fixed typo


          • #35
            Originally posted by archkde View Post

            Not quite, both are copyright licenses. Copyleft is just a term the FSF invented for twisting copyright to their needs. MIT on the other hand is called a permissive license.
            Yes, of course, I was talking in the context of his post


            • #36
              Originally posted by Classical View Post
              1. Memory safety. This is supposedly the big reason why we should use Rust. The CHERI memory-protection features historically allow memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities.
              Rust catches much more than that and it encourages memory safe thinking/programming instead of making errors and trying to fix them afterwards.

              2. Performance, Rust is slow as a snail in real programs compared to C:​
              Generally speaking, C still dominates Rust by a relatively wide margin in terms of execution time. Consequently, there is definitely a performance cost associated with using Rust instead of C.
              Last, but not least, notice how Common Lisp is the fastest language of all, beating even Rust, on the smaller runs (and notice that this is no hello-world, it loads over 70,000 words into a hash-table, then encodes 1,000 phone numbers using those words - all of that in a mere 59ms, well ahead of Rust, somehow, which needs 89ms!).
              Reads like some rust hater wrote that 7 years ago.

              Edit: also from your link:
              > The Rust implementation is generally the fastest, but Java’s Main catches up on the longer runs, once again showing that its JIT compiler is very powerful.​
              And by the way rust used 20 MB while the others were over 100 MB.

              3. Ease of use:
              However, there are still some annoyances about Rust that can, at times, make implementing a simple algorithm difficult.
              Most of the times rust makes your life hard is because you try to implement an unsafe algorithm. If you don't want to evolve as a programmer there is nothing wrong with C. But imagine how much time you could save if you didn't need 100 tools, a debugger, luck and special hardware instructions to make your code memory safe (and you still can't be sure like you would with a rust programm).
              Last edited by Anux; 24 November 2022, 12:44 PM.


              • #37
                What i want to ask is does it run crysis?

                No realy whats the goal? Porting Gimp, Blender, Wine? One allready made a sarcastic Steam remark, in the end thats what it boils down to, where is my Chrome browser to Google the Amazon Black Friday Sale highlights ?

                It´s all nice and fun that it´s proof of concept for Rust, but when does it benefit the masses? Like Facebock or PayGal ~~ where they used some crap code to make billions of $$$$$
                Last edited by erniv2; 24 November 2022, 12:07 PM.


                • #38
                  Originally posted by erniv2 View Post
                  It´s all nice and fun that it´s proof of concept for Rust, but when does it benefit the masses?
                  Why does it have to benefit the masses? Is there some rule that says "what ever you develop in your free time as a hobby must allways benefit the masses!"?


                  • #39
                    Originally posted by Waethorn View Post
                    Hardware support is always, ALWAYS going to be the big speedbump to any OS development especially given the license, intellectual property, and complexity issues with existing hardware. It'd probably be easier to just design a new form of computer from scratch that's tailored to the function that you want. FPGA's have helped make this a viable option.
                    They could go the hybrid route, like Haiku with its FreeBSD driver support.


                    • #40
                      Originally posted by Anux View Post
                      Why does it have to benefit the masses? Is there some rule that says "what ever you develop in your free time as a hobby must allways benefit the masses!"?
                      It doesn´t have to, but if you come out of the hobby box and want a growing user base you will need software that runs on it in a atlast home user enviroment.

                      Funny that you call it hobby project some pepole here allready treat it as the next holy OS grail, it´s Rust and it´s new praise it. You have to be realistic in some points.

                      Like what hardware will we support do we go pure 64bit only aarch64 x64 like asked before, if you want something new revolutionari you need to think about this things, wich driverstacks can we implement what userspace software can we get etc. a kind of roadmap, not i code this for fun and when i get a new girlfriend it gets buried ~~.

                      Waste of time could aswell have programmed a Rust driver for linux in the same time .... well in the end it´s freedom of choise, but it´s funny how alot of zealots jump onto stuff like that.