Redox - Your Next(Gen) OS - Redox - Your Next(Gen) OS
www.redox-os.org
The Redox official website

This isn’t Linux, but Linux-like. Its a microkernel built from the rust programming language. Its still experimental, but I think it has great potential. It has a GUI desktop, but the compiler isn’t quite fully working yet.

Has anyone used this before? What was your experience with it?

Note: If this is inappropriate since this isn’t technically Linux, mods please take down.

    • weclaw@lemm.ee
      913·
      11 months ago

      From my personal experience I can tell you 2 reasons. The first is that this is the first general purpose language that can be used for all projects. You can use it on the web browser with web assembly, it is good for backend and it also is low level enough to use it for OS development and embedded. Other languages are good only for some thing and really bad for others. The second reason is that it is designed around catching errors at compile time. The error handling and strict typing forces the developer to handle errors. I have to spend more time creating the program but considerably less time finding and fixing bugs.

      • agent_flounder@lemmy.worldEnglish
        251·
        11 months ago

        That sounds pretty great. I get sick of having to switch gears for every layer. As a hobbyist it is tough to remember five or six languages well enough when only coding something a few times a year.

        Since I do embedded, scripting, web front and back end this is sure tempting.

        I have been hesitant to try to learn yet another language (this would make…ummm… idk I lost count ages ago). But with all the hype I may break down and give it a whirl.

        • YIj54yALOJxEsY20eU@lemm.ee
          96·
          11 months ago

          Sounds like python may be a better fit if its supported on the embedded devices you use as it will cover scripting and backend too. Rust has quite a learning curve and can be rather verbose.

          • agent_flounder@lemmy.worldEnglish
            3·
            11 months ago

            I do use python quite a bit for scripting and backend, app, and I’ve used MicroPython a little bit, preferring C, C++ for embedded. It’s pretty great for what I need.

            I might mess around with Rust out of curiosity anyway, though the downsides you mention make it less compelling for me, personally. I’m not a big fan of verbose languages (e.g., Java, though I have used it for some apps).

            • YIj54yALOJxEsY20eU@lemm.ee
              2·
              11 months ago

              If you are curious definitely do check it out! It’s a really cool language to learn and you’ll start to enjoy the fight the compiler puts up.

      • LoETR9@feddit.it
        19·
        11 months ago

        I feel like C++ is as competent as Rust for any project and it’s definitely older.

        • weclaw@lemm.ee
          2·
          11 months ago

          Before using Rust I was using C++ for most projects and while it is a really powerful language there were some big problems:

          • no standard build system, most projects use cmake or meson and vendor dependencies with the projects. These build systems were really hard to learn (especially cmake, meson is easier). There are package managers these days such as conan and vcpkg but there is not really one standard way to build programs like in rust.
          • error messages were really hard to understand, especially when the project uses templates
          • it felt like 3 languages in one, projects written before c++11 differ greatly from c++11 and up
          • some of the new language features have really weird syntax, for example lambdas
          • some people say that rust is hard, but modern c++ is considerably harder to learn, just look at the list of modern c++ features: https://github.com/AnthonyCalandra/modern-cpp-features, you have to know the different pointer types (unique_pointer, shared_pointer etc.), templates, rvalue references and move semantic, exceptions, constexpressions and the list goes on
        • Wooki@lemmy.world
          1·
          11 months ago

          Rust was created because c++ was so bad. Just take a look at crates they need a whole lot less maintenance because less bugs.

    • MonkCanatella@sh.itjust.works
      351·
      11 months ago

      I know the evangelists can be somewhat overwhelming, but its popularity is not unwarranted. It’s fairly easy to pick up, has an incredibly enthusiastic and welcoming community. People like it because it’s incredibly performant, and its memory safe. In terms of DX it’s really a joy to work with. It just has a LOT going for it, and the main drawback you’ll hear about (difficulty) is really overblown and most devs can pick it up in a matter of months.

      • Ramin Honary@lemmy.ml
        281·
        11 months ago

        The main difficulty I have with Rust (what prevents me from using it), is that the maintainers insist on statically compiling everything. This is fine for small programs, and even large monolithic applications that are not expected to change very often.

        But for the machine learning projects I work on, I might want to include a single algorithm from a fairly large library of algorithms. The amount of memory used is not trivial, I am talking about the difference between loading a single algorithm in 50 MB of compiled code for a dynamically loadable library, versus loading the entire 1.5 GB library of algorithms of statically linked code just to use that one algorithm. Then when distributing this code to a few dozen compute nodes, that 50 MB versus 1.5 GB is suddenly a very noticeable difference.

        There are other problems with statically linking everything as well, for example, if you want your application to be written in a high-level language like Python, TypeScript, or Lisp, you might want to have a library of Rust code that you can dynamically load into the Python interpreter and establish foreign function bindings to the Rust APIs. But this is not possible with statically linked code.

        And as I understand, it is a difficult technical problem to solve. Apparently, in order for Rust to optimize a program and guarantee type safety and performance, it needs the type information in the source code. This type information is not normally stored into the dynamically loadable libraries (the .so or .dll files), so if you dynamically load a library into a Rust program its type safety and performance guarantees go out the window. So the Rust compiler developers have chosen to make everything as statically compiled as possible.

        This is why I don’t see Rust replacing C any time soon. A language like Zig might have a better chance than Rust because it can produce dynamically loadable libraries that are fully ABI compatible with the libraries compiled by C compilers.

        • Skull giver@popplesburger.hilciferous.nl
          41·
          11 months ago

          You can load Rust into Python just fine. In fact, several packages have started requiring a Rust compiler on platforms thst don’t get prebuilt binaries. It’s why I installed Rust on my phone.

          The build files for Rust are bigger than you may expect, but they’re not unreasonably big. Languages like Python and Java like to put their dependencies in system folders and cache folders outside of their project so you don’t notice them as often, but I find the difference not that problematic. The binaries Rust generates are often huge but if you build in release mode rather than debug mode and strip the debug symbols, you can quickly remove hundreds of megabytes of “executable” data.

          Rust can be told to export things in the C FFI, which is how Python bindings are generally accomplished (although you rarely deal with those because of all the helper crates).

          Statically compiled code will also load into processes fine, they just take up more RAM than you may like. The OS normally deduplicates dynamically loaded libraries across running processes, but with statically compiled programs you only get the one blob (which itself then gets deduplicated, usually).

          Rust can also load and access standard DLLs. The safety assertions do break, because these files are accessed through the C FFI which is marked unsafe automatically, but that doesn’t need to be a problem.

          There are downsides and upsides to static compilation, but it doesn’t really affect glue languages like Python or Typescript. Early versions of Rust lacked the C FFI and there are still issues with Rust programs dynamically loading other Rust programs without going through the C FFI, but I don’t think that’s a common issue at all.

          I don’t see Rust replace all of C either, because I think Rust is a better replacement for C++ than for C. The C parts it does replace (parsers, drivers, GUIs, complex command line tools) weren’t really things I would write in C in the first place. There are still cars where Rust just fails (it can’t deal with running out of memory, for one) so languages like Zig will always have their place.

          • Ramin Honary@lemmy.ml
            7·
            11 months ago

            So you’re working on your machine learning projects in Zig?

            No, Python and C++, which were the languages chosen by both Google and Facebook for their AI frameworks.

            I just think if a systems programming language like Rust does not provide a good way to facilitate dynamic linking the way C, C++ does, these languages will start running into issues as the size of the compiled binaries become ever larger and larger. I think we might all be a little too comfortable with the huge amount of memory, CPU cycles, and network bandwidth that we have nowadays, and it leads to problems when you want to scale-up a deployment. So I think Zig might make a more viable successor to C or C++ as a systems programming language than Rust does.

            That said, I definitely think Rust and Haskell’s type systems are much better than that of Zig.

        • agent_flounder@lemmy.worldEnglish
          21·
          11 months ago

          Is it not possible for Rust to optimize out unused functions as with C? That seems …like a strange choice if so.

          • Ramin Honary@lemmy.ml
            7·
            11 months ago

            Is it not possible for Rust to optimize out unused functions as with C?

            No Rust can do dead code elimination. And I just checked, Rust can do indeed do FFI bindings from other languages when you ask the compiler to produce dynamically linking libraries, but I am guessing it has the same problems as Haskell when it produces .so or .dll files. In Haskell, things like “monad transformers” depend pretty heavily on function inlining in order to achieve good performance.

            So I am talking more about how Rust makes use of the type system to make decisions about when to inline functions which is pretty important when it comes to performance. You usually can’t inline across module boundaries unless modules are all statically linked. So as I understand it, if you enable dynamic linking in your Rust program, you might see performance suffer a lot as compared to static linking, and this is why most Rust people (as I understand it) just make everything statically linked by default.

            • nous@programming.devEnglish
              2·
              11 months ago

              I am not sure that is quite right. I dont think rust support just enabling dynamic linking of its dependencies. It can talk to dynamically linked libraries - which is how FFI works. And you can compile rust crates to be dynamically linked. But when you are going down this route you are talking over the C ABI. This requires some effort on the code author to make their APIs exportable to C types and means you lose all safety when talking over the C ABI.

              I also dont think that rust inlines across a crate boundary unless the function is marked as inline or LTO is enabled - inlining across crate boundaries is expensive and so only done when explicitly needed or asked for it. It is more that you lose features like generics and traits and other things that are not supported over the C API.

      • fossphi@lemm.eeEnglish
        261·
        11 months ago

        Yes, as much as I appreciate memory safety and rust in particular. I’m very worried by this pivot away from copyleft and GPL. Specially the rewriting in rust phenomenon of fundamental stuff. It’s safer, yes, but they’re all pretty much non GPL and it seems very risky to me. Make no mistake, the industry is riding this wave to move away from copyleft to permissive licenses.

        I wish that people understood the importance of FSF and GNU

        • agent_flounder@lemmy.worldEnglish
          72·
          11 months ago

          Well that is rather insidious. Crap. They probably understand the reasons for the GPL very well. Doesn’t mean they support them.

          • fossphi@lemm.eeEnglish
            4·
            11 months ago

            I’m sure there’s some community pull as well, because most of the rust ecosystem seems to be converged on MIT. But what despairs me is the wilful sidelining of GPL and everything GNU by some open source community members/corporate people. So yeah, you’re probably right

        • jack@monero.town
          311·
          11 months ago

          You make it sound like a conspiracy. Just accept that some things are organically more popular, like MIT which is very easy to understand and use for normies. It’s not perfect, but that’s how it is

          • Danny M@lemmy.escapebigtech.info
            164·
            11 months ago

            MIT is a terrible license that only got popular because of the popularity of the anti-open source movement in the last decade.

            one could write books about what’s wrong with the MIT license.

            It could even theoretically be argued that MIT has in some ways allowed big tech companies to proliferate, by effectively allowing them to take open-source code, modify it, and then close it off in their proprietary software. What does this mean? It means that the work of countless dedicated open-source developers can be co-opted by companies that have done almost none of the work, reaping several billions of dollars, while the developers who actually did the work make no money. It’s like opening your doors wide only to have someone come in, take your stuff, and sell it back to you.

            In contrast, in licenses like the GPL, there’s a requirement that if you use GPL-licensed code and modify it, your new code also has to be open-source under the GPL.

            • Fedora@lemmy.haigner.me
              1·
              11 months ago

              I love the free software ideals, but I think we’ve got a different understanding about what constitutes a good and a bad license. What many people seem to forget about software licenses is that there are these other countries besides America. They couldn’t care less about whatever judges rule over there. A good license is a dumb simple license that anyone can enforce in court with ease. A bad license is a convoluted license that crumbles like a house of cards in court. I read the GPL. It’s convoluted. It’s an opaque terms of service agreement riddled with legal boilerplate disguised as software license. A poor execution of the ideals I hold. I only use the GPL as a formality to say that I support the free software ideals, but I have zero confidence in enforcing the GPL.

      • Fedora@lemmy.haigner.me
        1·
        11 months ago

        Shame that we don’t have a proper copyleft license tho? GPL, as nice as the intentions are, is a license so convoluted that I’m not sure whether it’d hold up in court in my country.

      • velox_vulnus@lemmy.ml
        910·
        11 months ago

        But what is wrong with C and C++ apart from the ISO fuck-up (ahem, slow updates)? There’s a lot of technical debt, so wouldn’t it be better to create an alt-language compiler that adds improvement over C, so that migration is possible in multiple stages?

        Something like:

        1. Fix shitty imports
        2. Improve syntax rule
        3. Improve memory management
        4. Other new misc features
        • Spore@lemmy.ml
          42·
          11 months ago
          1. breaks compatibility
          2. breaks compatibility
          3. breaks compatibility
          4. hard to add without breaking compatibility

          Then we arrive at Rust as a natural outcome.

          And it’s of course possible to migrate to Rust from C or C++ progressively, fish has almost got it done.

          • jack@monero.town
            1·
            11 months ago

            Did fish migrate progressively tho? I thought they swap out everything at once as soon as the rewrite is ready

            • Spore@lemmy.ml
              1·
              11 months ago

              Well, yes. I was trying to say that their rewrite still “works” at each commit being a hybrid of Rust and C++.

        • Mubelotix@jlai.lu
          121·
          11 months ago

          Rust isn’t just a new improved version of C or C++. It’s completely new and it feels completely different to use Rust. In a positive way

        • callyral [he/they]@pawb.socialEnglish
          8·
          11 months ago

          (notice: I am not a Rust or C/C++ expert)

          Doing all that is creating a completely separate programming language from C. Rust is that programming language.

          Fix shitty imports

          Rust does that with modules and crates.

          Improve syntax rule

          You mean having consistent/universal style guidelines? Rust pretty much has that with rustfmt.

          Improve memory management

          Safe Rust is memory safe (using things like the borrow checker), and Unsafe Rust is (usually?) separated using the unsafe keyword.

          Although Unsafe Rust seems to be quite a mess, idk haven’t tried it

          Other new misc features

          Rust has macros, iterators, lambdas, etc. C doesn’t have those. C++ probably has those but in a really weird C++ way.

          • velox_vulnus@lemmy.mlEnglish
            2·
            11 months ago

            I should have framed my words better, I guess. Rust is a radically different language, and honestly, none of the feature it offers fixes the main issue, that is technical debt - I mean yes, there’s incline C or FFI, but that’s still going to be a radical migration.

            What I’m trying to propose is an alternative project, independent from the ISO. Maybe it could be a C-to-Rust, or a C-to-Vale migration project. It could be any of the modern language, I don’t really care. But that particular compiler/transpiler/migrationpiler/-piler should have the ability to do step-by-step migration.

            • Spore@lemmy.ml
              2·
              11 months ago

              I’d say no. Programming safely requires non-trivial transformation in code and a radical change in style, which afaik cannot be easily done automated.

              Do you think that there’s any chance to convert from this to this? It requires understanding of the algorithm and a thorough rewrite. Automated tools can only generate the former one because it must not change C’s crooked semantics.

              • velox_vulnus@lemmy.ml
                1·
                11 months ago

                I was planning to learn C23 for quite some time. It’s a pity that I’ve been planning to learn RISC-V with it, sigh. I guess I’m gonna move over to Rust or Zig, whichever makes sense. But I’d probably switch, when Vale becomes a legit language.

                • Spore@lemmy.ml
                  1·
                  11 months ago

                  I think there’s no need to stick on one particular language. It benefits to learn more languages and bring the “good parts” of their design into your code whatever you are writing it in.

                  Btw It happens that I’ve learned a bit of RISC-V, with Rust.

        • agent_flounder@lemmy.worldEnglish
          2·
          11 months ago

          Idk what the iso fuck up and I don’t code enough to appreciate whatever technical debt exists in either so I am probably sound like an idiot but…

          Since I do infosec, the glaring issue for me is not being memory safe.

        • Skull giver@popplesburger.hilciferous.nl
          2·
          11 months ago

          C and C++ can’t be fixed retroactively because old code must remain compatible.

          If you’re going to implement your own C dialect, you may as well just write a new language.

          For C++ that’s Rust, for C that’s probably Zig (Zig will just let you import existing C files, which helps with porting). Carbon and experimental languages like Jakt may also work, it all depends on what your priorities are.

    • beeng@discuss.tchncs.de
      7·
      11 months ago

      The idea is less bugs due to stricter rules when developing and compiling. You can understand that.

      Then, also more access to build tools and high level programming without changing languages.

      If you have no need for that, then just know others do and it’s a great thing.

  • guitars are real@sh.itjust.worksEnglish
    295·
    11 months ago

    I’m not against Rust, per se, the idea of a systems programming language with some more advanced memory safety features sounds nice, but what is with the emphasis on creating a Rust version of everything? Like why should we want an OS written only in Rust?

    • ExLisper@linux.communityEnglish
      331·
      11 months ago

      People keep saying this but Rust is not only about memory safety. It’s not C with memory safety sprinkled on top. Compare with C and C++ it has better tooling and dependency management, it’s easier to create modules and organize your code, it’s easier to write tests and it has loads of nice, modern language features like algebraic types and typeclasses. Because of all this Rust is growing fast and a lot of people like it. Writing things in Rust is a bet that more people will get behind them and you will be able to add more features faster to them than to existing projects in C. The idea is not to simply do the same but in Rust. It is to have a cleaner, easier to approach codebase that will allow to grow faster in the future.

      • agent_flounder@lemmy.worldEnglish
        9·
        11 months ago

        It would certainly be interesting to see if an OS written in Rust can end up being notably more reliable and secure. My curiosity is piqued by the features you mention.

      • guitars are real@sh.itjust.worksEnglish
        41·
        11 months ago

        Yeah, but I don’t know any other language where the fact a program is written in that language is used as a selling point. I never cared that Linux was written in C, I cared that it does its job. I’ve heard about Redox many times, yet never once has there ever been anything said about it other than “it’s written in Rust! :D” Literally, the fact that it’s a UNIXY operating system written in Rust is the first thing about the OS on their home page.

        Hey, Linux started as a learning project, you learn more about programming by writing code, so I’m not saying it’s bad, I just can’t understand why I’d care about something that at this stage seemingly is just a learning project.

        • ExLisper@linux.communityEnglish
          5·
          11 months ago

          That’s fair, I’m just saying it’s not “OS with memory safety” but “OS written in modern language”. I guess it’s interesting in itself but yeah, definitely not groundbreaking.

        • ProtonBadger@kbin.social
          4·
          11 months ago

          I’m looking at how many of the bugs and security issues are due to memory unsafe code - it’s A LOT and new ones come up almost daily. Humans are just bad at writing safe code because we are so fallible. So if we can eliminate a significant percentage of these bugs from the ground up that suddenly becomes very interesting. Besides personally after two decades of C and C++ (and debugging them) I find Rust much more pleasant and “ergonomic” to use.

          If we want an OS to be more secure by design we really have to begin at the most basic level. It might never be perfect but we can greatly reduce the attack surface. This is also why Microsoft is rewriting a number of vulnerable system components of Windows in Rust.

          So why is it important to the end-user? Well, if that’s Average Joe, maybe not but Redox OS right now is not mainstream, it is for us nerds who are interested in a safer OS and to see what can be done in that space. Maybe you don’t care and that’s fine, but some of us do and just like any post here, people can chose to skip over it or dive into the discussion, we can’t guarantee that all posts or projects are interesting to everyone :)

        • nous@programming.devEnglish
          3·
          11 months ago

          But it happens all the time with other languages. Especially when that language is newer or in the headlines. NodeJS/Electron was a big one a few years ago. Ruby/On Rails a while before that, have seen it for python programs and way back in the day when java was all the rage.

          Personally I think it does matter and as a end user I do care to come degree. It tells you some things about the program, like how it can be install/run what deps you might need, is it going to be a memory hog or possibly full of vulnerabilities. The language affects all of these things, more so when the projects are new or niche and have not been hardened over time or been properly packaged yet.

          Personally I love it when a program is written in languages like rust or go as it means I know it is going to be easy to build/install and distribute given they build into single binaries and very easy to make static. But if I see one written in nodejs with electron I am disappointed as I know it is going to be a huge package that consumes large amounts of memory. Or if there is some python package that is not already packaged by my distro I would avoid it as I hate dealing with python dependencies and its virtualenvs.

          And for this case, with redox. Well redox is not an application to be used by people. It is a showcase about what can be done in the language. It is not intended for most people that hear of it to ever run it or even want to run it. Yet is very impressive what they have managed to do in it. Including having parts written for it be able to work standalone in Linux and other OSs.

    • mogoh@lemmy.ml
      16·
      11 months ago

      Some thoughts:

      • Testing the capabilities of rust and proving what rust is capable of.
      • Seeing what rust is not capable of and proposing improvements for the rust language and ecosystem.
      • Trying new OS concepts. Linux for example is strongly backwards compatible. Starting a new OS is the opportunity to do things different and maybe better.
      • Maybe it will turn out, that the memory safety will improve OS’. We will only know for sure, if we try it.
    • Static_Rocket@lemmy.worldEnglish
      15·
      11 months ago

      Eh, I welcome the iteration. It gives people a reason to practice and hey, who knows, maybe they’ll come up with something neat while rewriting curl or something

    • DumbAceDragon@sh.itjust.worksEnglish
      126·
      11 months ago

      This is one of my main gripes with the rust community. What programming language you used shouldn’t be of any concern to the end-user, let alone be put in the tagline.

      Rust is a very good and capable language and I enjoy using it. I can’t wait for the day it overtakes C or C++. But I want to know more about the program I’m using other than that it was written in a popular language.

      “Written in rust” is basically a meme at this point.

      • Mactan [he/him]@lemmy.ml
        10·
        11 months ago

        not necessarily about the language, but things periodically getting rewritten or re-implemented is a useful exercise. it’s a moment for reflection and analysis of the structures and systems as a whole

      • davel [he/him]@lemmy.mlEnglish
        10·
        11 months ago

        This is typical of when a language is the new hotness. It eventually dies down, either because the language becomes endemic or it fades away.

      • jack@monero.town
        34·
        11 months ago

        Rust is used by modern people to create modern programs. If the program would be in C++ for example, a very complicated, error-prone language, that gives me insight into how well (or not) that program might be supported in the future

    • jack@monero.town
      22·
      11 months ago

      The language is newer so it does a lot of things better than C, C++ and even higher level langs like java. It is more probable that people in the future build upon Rust than legacy languages.

      Comparable to how it would be misguided now to start a project that only runs on Xorg

  • jack@monero.town
    17·
    11 months ago

    Now imagine the new COSMIC desktop environment in Rust on Redox, that would be great

    • atzanteol@sh.itjust.works
      616·
      11 months ago

      Why would that be great? It’s so weird that people care this much about what language their OS is written in…

      • Child Eater@iusearchlinux.fyi
        8·
        11 months ago

        I personally like rust, so I get excited when cool things are done with it because each one makes rust just that much bigger, which leads to it being made that much better.

        I see projects like that as more of a statement that “rust can do it” than anything.

      • jack@monero.town
        5·
        11 months ago

        I want the newest, best software. Is that uncommon? Modern rewrites are often much better than their age-old counterparts since the tech got better over time, compare for example grep vs ripgrep, or find vs fd. The rewrites are much faster and user-friendlier

  • Justin@lemmy.world
    14·
    11 months ago

    I’ve used it in a VM just to mess around. I’d like to install it on an old ThinkPad and try to compile some applications.

    • baconicsynergy@beehaw.org
      9·
      11 months ago

      Kinda. Redox uses a microkernel architecture and tries to keep only the most important functionality in ring 0 while they push everything else in userspace. It’s great.

  • wiki_me@lemmy.mlEnglish
    11·
    11 months ago

    Having some hardware mentioned on the site that is supported and ready for use could be helpful if someone wants to try it (say raspberry pi), There are probably people who are worried to will make their computer explode.

  • aodhsishaj@lemmy.world
    11·
    11 months ago

    I wouldn’t say it’s inappropriate as there is more and more rust making it into the native kernel. I’ll definitely throw this on my Ventoy usb and see if I can get it to boot

  • I Cast Fist@programming.devEnglish
    7·
    11 months ago

    How long would it take to compile their Rust microkernel alone compared to a similar one done in C? There are many posts around the web complaining about Rust’s long compile times, though thankfully rarely as slow as C++