Personally, I am really excited by Relibc. While there is a certain irony in a C standard library that is not written in C, it seems like exactly the kind a place you want to have the advantages of Rust. I would love to see it find success beyond Redox as well.
I have never really paid attention to Redoxfs before. I see that it is also meant to work with Linux as well.
It would be great if it could get some traction on Linux as any level of success on Linux would bring a relatively large audience and substantial testing. A filesystem also seems like the kind of place that Rust features would be very welcome. The fact that Linux is moving towards allowing Rust usage gives me hope that Redoxfs could make it into the kernel at some point.
Hi Jeremy and first of all, thank you very much for your efforts in trying to bring some new fresh air in the OS world.
We see nowadays OSes and applications running short in resources with, let's say, 2GB RAM and 2 2GHz cores, typical resources for old-school 32-bit systems. Do you have in mind to keep the resource hunger of your OS as low as possible so they could fit (and be actually effective and useful) also on such "limited" hardware?
I ask this because I use what I would call "a rather capable" 64-bit laptop that normally does nothing but yet can easily struggle with some web-based multimedia service running in a browser.
How much performance overhead does the microkernel design impose? Or is it actually the opposite these days (there's got to be a reason people keep moving network stacks into userspace for performance...)?
People are moving network stacks into userspace to be closer to the application, which improves the performance. Similarly, you could move application code to the kernel, which is what unikernels achieve. :)
It is fascinating to see the emphasis on working with a broad range of hardware and low level features like the file system. Contrast this with something like SerenityOS where they spend so much time on things like the web browser and where many contributors are working on things like fonts and dialog boxes.
This leads me to ask, “what are your goals and ambitions for Redox?”. How should I be thinking about it? Who should be using it today and tomorrow?
Some people have asked what is unique about Redox as if being an OS in Rust is not enough. That is not really what I am asking.
If I am allowed to ask another question, “what’s next?”.
I would love to next work on the install process. Currently, there is only a very simple installer that I haven't mentioned much because it is really only good for replicating the VM image inside a VM.
Improving this so it can be used to have permanent installs of Redox OS, and then improving rustc so those installs can build software for Redox OS (self-hosted), would accelerate development so we can take on bigger, higher level projects.
Been contributing each month for the last year or so. Every release confirms to me that this is money well spent. currently learning rust so that I can contribute myself. eventually. thankyou for all the hard work!
Primarily the model is capability based. Most things are managed through file descriptors. Services usually end up in a special namespace where they can no longer open new files at runtime, except from a highly restricted set of filesystems. This essentially disallows operating on anything beyond their current set of open file descriptors. This makes runtime inspection of the capabilities of each process fairly easy, and the build time declaration of those namespaces also pretty easy.
Wow, that sounds really exciting. How would this work for something like a service that runs for a long time, and periodically needs to make a web request (and therefore periodically opens a TCP socket)?
Are you counting the ability itself to open sockets as a "file descriptor"? Is it straightforward to implement a "namespace" (not sure if I'm using that correctly) that limits network access to certain IP addresses? Certain domains?
Namespaces on redox are probably what you are looking for. They are incredibly powerful, but difficult to describe. Processes can offer isolated filesystems called "schemes". These are usually at the default namespace (1). Processes can move to the null namespace (0) which disallows them from opening file descriptors from most schemes. Moving to a new namespace allows a process to control the view of the system for all its children. This can be used, for example, to implement chroot.
Syscalls are mostly sync, but with some syscalls for doing blocking operations asynchronously, like on Linux.
What is your long term strategy for hardware support? Do you want to target a few devices, or aim for broad support? Will you support some sort of virtualized/embedded Linux process to leverage all of the Linux drivers that have already been written?
Super exciting, congrats on the new release, it's been so long since the last release!
One question I have is: Is there any plan or prioritisation to get Firefox running on Redox? Totally understand if that's way down the line of prerequisites of course :)
The next priorities will be to make the image installable, and to improve how rustc runs on Redox (for self-hosting). After that, it will be easier to develop on Redox OS and work on porting larger pieces of software like Firefox.
Servo never made it to a place where it could consistently render most websites correctly. People underestimate the amount of work required to get something like that production ready by several orders of magnitude.
Hi, Redox OS looks very interesting and I'd love to help contribute. Using rust for an OS seems like a big win for safety and stability down the road. I've emailed info@redox-os.org a while ago to try and get account approved so I can join the chat and begin to contribute - However I have had no response. Is there another way of me being able to get onto the chat?
I tried v0.6 a couple of weeks ago, shortly after TheRegister.co.uk had an article on it.
v6's major lack was self hosting and from the release notes it seemed far away, but with v7 it's now mentioned as one of the main user visible new features...
only I can't find 'rustc' or 'cargo', so I'm afraid that capability isn't quite there yet, correct?
Like your hardware btw. mine's rather similar only home-grown with same CPU and RAM, but an RTX2080ti GPU, 10Gbit Ethernet, dual NVMe but also dual tray-less 2.5" SATA SSD hot-swap enclosure, pretty much like 1.44" floppy disks at SSD speed and Terabyte capacity, so I can swap operating systems like floppies.
I'd love to have the same for NVMe, but those solutions are rare, pricey and most likely troublesome, unless you have retimers in place.
Is there any good reason releases don't have the ISA they target in the filename or path?
Going by the screenshot, I am guessing it'll require x86_64, and that I should built it myself for some other architecture (which ones are supported? This is not easy to find either, yet it belongs to the bulletpoint list in the front page).
Spoiler alert: I am also the maintainer of Pop!_OS and the Principal Engineer at System76 so it will be easy to guess.
I have loads of computers (which helps when doing OS work!) but my main one is my desktop. I have a System76 Thelio Mira with AMD Ryzen 9 5950X CPU, AMD Radeon RX 6900 XT GPU, 128 GB DDR4-3200 ECC RAM, a couple PCIe Gen 4 drives, and a couple larger PCIe Gen 3 drives. The most important parts of my setup, though, are my System76 Launch keyboard and 3x LG 27GL850 monitors. There's also probably a mouse somewhere.
This computer runs primarily Pop!_OS 22.04 LTS, but on those extra drives I often have some other OS's installed for testing. I also use loads of VM's, as you can probably imagine.
For apps, I mostly use Alacritty for my terminal, Firefox for my browser, and Vim for my editor.
Could you lay out some of the differences between Zircon and Redox? I know that both are vaguely Plan 9-inspired, but some of the finer details are unclear.
(This would be a great thing to flesh out in the official docs, currently there are a lot of TODOs in those sections)
No, I do not. Redox OS is hard to install permanently (there is no easy installer yet). Most of us are running Redox OS in a VM, with occasional experiments on real hardware.
because 3 operating systems apple-linux-windows isn't enough! Just like the 3 web browsers webkit-mozilla-chromium isn't enough. Remove the derivatives, and there aren't really that many different freshly updated and fully functional desktop / phone operating systems available, but it's good to see some. Thank you https://www.redox-os.org/
> Because UNIX and its derivatives do suck. (huge TCB, drivers in the kernel, global namespaces, ambient security)
This is a unix-like, and none of those are inherit to unix/derivatives; there are small unixen, there are microkernel unixen, containers are popular, and whatever security model you want, someone has hacked it onto an existing unix-family OS.
It looks cool, when I was young and Linux was just few years around it was very limited and people considered it a toy, but it being limited in supporting stuff was the reason I loved it, as it would force me to go around and explore and experiment, and I guess it developed my passion for informatics. Now Linux is a bit of low maintenance system. But I hope your system may become the reason why kids of today explore and read and experiment and which light their passion for this world in them. Good luck! I say it because every now and then I think about my history and am afraid that kids of today between all the ready to use and black boxes stuff have little to experiment
Hardware support is always a big issue with a new OS designed to be run directly, it is much easier for a new OS to start the other way as a VM run by a more mature OS. Getting qemu working is also quite a bit of work, although Xen Dom0 support would be easier. There are security implications of the hosting implemention as well. However, long term a general purpose OS will almost certainly want to support VMs so the extra work to do a WSL2-style integration is less than trying to keep up with the large number of complex Linux system calls for direct binary compatability and there are also major security implications to doing things that way.
This is what most of the existing open source operating systems are and it is much easier to contribute to those or fork one that does most of what you want. If you are aiming at a POSIX system then there is a fair amount of work but you at least then get a huge amount of already written software that you can run (IIUC Redox is aiming for this but written in Rust). A structure like Qubes OS would make it easier to do something less like POSIX while still running some existing software.
If you are interested in OS design, I suggest taking a look at NetBSD. It is a full OS supporting a bunch of different platforms all in one source tree and not quite as complex as Linux while still supporting most software the works on Linux. It has a nice crosscompile system and "rump kernels" that allow large parts of the kernel to be run in userland for testing (I think GNU Hurd also uses this for some device support). I think it has had at least a couple hundred active volunteer developers at any particular time for about three decades now (vs 7 years with mostly one developer it looks like for Redox). It is really quite a lot of work. src/sys is the kernel and src/sys/arch has the platform specific code, such as:
x86 has the generic x86 support shared between 32-bit and 64-bit systems while amd64 has the 64-bit specific stuff. The rest of the tree is relatively easy to understand as well (e.g. most devices are under src/sys/dev), although a few things are in less than optimal place due to NetBSD still using CVS (there are git and hg mirrors so no need to learn CVS). The tech-* mailing lists can have interesting discussions.
I don't know anything about building a POSIX OS from scratch. I don't know much about Rust as well. That said, Redox code base is clean and very approachable. Kudos!
I do see a lot of unsafe keyword, are they inevitable?
As soon as there's a working compiler it might be fun to implement something like gentoo's ports system, would be quite fun to run something like that as an excercise in how far pure rust can get you. :D
pkgsrc has been ported to various OSs, is the default in at least two and supports both binary and source packages.
If I were to choose a package system for a new OS, it'd probably be my choice.
I hope that this distro's package management system follows the best practices of The Update Framework[0] or just reimplements a well-engineered existing architecture for distro updates.
Actually the Rust ecosystem is doing some exciting work on supply chain security[1], but it would be good to have something like pacman-bintrans[2] supported from day one of any new distro.
As Kerla, this is an excellent project, that they will could be a replace of Linux (as kernel) but not, because they lost the opportunity in the start.
