Redox OS Archive
Another month, another report from the Redox team. The Rust-based operating system saw another active month, including getting a whole bunch of new funding deals for specific features, such as adding UNIX-style signals to Redox, as well as the further development of Termion, a Redox project that is “a pure Rust, bindless library for low-level handling, manipulating and reading information about terminals”. Furthermore, the default user interface Orbital got a small makeover with new colours and a new default wallpaper, and there’s the usual documentation and website improvements. More substantial are doubling the performance of RedoxFS by improving the speed of block reads and writes, and changes in how the xHCI drivers works to drastically reduce CPU usage. The PCI/PCIe and x86 VirtIO drivers has also been improved, and you can now do userspace debugging using the GNU Debugger from outside the VM. There’s a lot more, so head on over to read the whole thing.
Another month, another Redox progress report. The Rust-based operating system, headed by system76 engineer Jeremy Soller, has made a big move by replacing Redox’ Orbital file manager, text editor and terminal by their COSMIC counterparts, COSMIC Files, COSMIC Editor and COSMIC Terminal, in the default Redox installation. COSMIC is the Rust-based desktop environment system76 is currently developing for their Linux distribution, Pop!_OS. You really have to start wondering what the long-term goals for Redox really are here. I’m not saying they’re intending to replace Linux with it – that’d be suicide – but the steady progress towards a general purpose operating system is undeniable.
Another month, another detailed report about the progress made in Redox, the Rust-based operating system. A major improvements this month is support for USB HID, allowing USB keyboards and mice to work on Redox, but the project does note USB hubs are still problematic and might not work properly. Thanks to these USB improvements, Redox’ desktop environment Orbital now also ran on ARM64 in Qemu for the first time, which is a great step towards running it on real ARM64 hardware. A massive documentation pass has also taken place, fixing various errors and improving and simplifying the writing. More programs have been ported, of course, and various lower-level improvements and fixes, along with a number of other fixes and changes across the operating system.
This year, there have been numerous improvements both to the kernel’s correctness, as well as raw performance. The signal and TLB shootdown MRs have significantly improved kernel memory integrity and possibly eliminated many hard-to-debug and nontrivial heisenbugs. Nevertheless, there is still a lot of work to be done optimizing and fixing bugs in relibc, in order to improve compatibility with ported applications, and most importantly of all, getting closer to a self-hosted Redox. Jacob Lorentzon (4lDO2) I love how much of the focus for Redox seems to be on the lower levels of the operating system, because it’s something many projects tend to kind of forget to highlight, to spend more time on new icons or whatever. These in-depth Redox articles are always informative, and have me very excited about Redox’ future. Obviously, Redox is on the list of operating systems I need to write a proper article about. I’m not sure if there’s enough for a full review or if it’ll be more of a short look – we’ll see when we get there.
Redox has published the summary of development covering February, and there’s quite a few interesting leaps forward this month. First and foremost, the operating system got a major file read/write speed boost by implementing records in RedoxFS. The migration to UNIX-format paths is ongoing, Boxedwine is currently being ported, and more and more programs are getting ported, including complex applications like Audacity, Celestia, KiCad and Neothesia. There’s a lot more this month, so be sure to read the whole report.
The Redox project has published an overview of the progress made in January, and it’s a long list. Redox now supports the Raspberry Pi 3 Model B+, a few of System76’s Cosmic Desktop applications now run on Redox, several more Linux applications haven been ported (most notably for me, nano, my CLI text editor of choice), and much more. The most important change is an overhaul of how Redox handles resource paths: Redox has a microkernel core, with drivers and other resource providers running as tasks and providing “schemes”. A scheme is the name of a resource provider, and until now, resources have been accessed using URI/URL format. For example, files would be accessed as file:path/to/my_file, and a TCP connection would be accessed as tcp:127.0.0.1. This format, while forward-looking, has not been very backwards-compatible. In order to simplify our efforts to port Linux software to Redox, we have decided to change our resource path format to the Linux-compatible /scheme/scheme_name/path/to/resource. Paths that do not begin with /scheme will be assumed to refer to the file scheme, so /path/to/my_file is treated by the system as /scheme/file/path/to/my_file, but the application will only see the /path/to/my_file portion. Using this format, normal paths now look just like Linux paths, while drivers and other resources can still be addressed without breaking software. Ron Williams The change is an ongoing process, so you might encounter some issues related to it in the coming time.
Redox OS, the Rust-based operating system aiming to be a general purpose operating system, has detailed its priorities for 2023 and 2024, and there’s ambitious stuff in there. First, the project wants to shoe up its support for server tooling so that Redox can host its own website. This will require porting a number of popular server tools, like Apache, Nginx, and so on. Second, they also want Redox to be self-hosting in the sense that it can host its own developer tooling, a project they’ve basically been working on since day one. Furthermore, a stable ABI is a must before Redox can reach 1.0.0. Before Redox can reach Release 1.0 status, we need to establish a stable ABI. This means that application binaries will be able to run on future versions of Redox without having to be recompiled. Our approach is to make our C library, relibc, the interface for the stable ABI, and to make relibc a dynamic library. This will allow us to make changes at the system call level without impacting the Redox ABI. Applications will just load the latest relibc at run time. Work needs to be done on our dynamic library support, as well as to continue to extend relibc functionality. We will also need to change programs that are currently using Redox system calls directly to use relibc instead. And finally, Redox intends to be able to run COSMIC, the Rust-based desktop environment System76 is working on for their Linux distribution. Redox’ main developer works at System76, so there’s some strong ties between System76 and Redox. This effort will include porting several applications, but also Wayland, GTK, Qt, and others, which should make porting Linux applications relatively easy. These are a set of ambitious goals, but I doubt they’d set them so specifically if they thought it’d be a fool’s errand.
This year’s Redox Summer of Code program has seen us add some exciting capabilities to Redox. Our three interns each came up with their own project proposals, and delivered major new functionality. In addition to our paid internships, our volunteer contributors also made major strides this summer. This year’s projects include VirtIO drivers, the project to use Linux drivers on Redox that we talked about earlier, and on-demand paging and other memory management improvements. There’s also a long list of other improvements outside of SoC.
The availability of support for various apps and drivers (for various hardware and software) is crucial for the general adoption of any general purpose operating system like Redox OS. Some of us developers are working on improving the core of Redox OS (like the Kernel), which should create a solid base on which high quality native drivers and apps can be created with ease. Some others are working on porting (and adapting) various open source drivers and apps (written for other OSes) such that they can work with Redox OS. This work is super important and helps Redox OS progress forward. But in the meanwhile, there’s a potential shortcut to enabling wide driver and app support for Redox OS, without having to manually port and adapt drivers to Redox OS. (which can be helpful, both today and in the future). The shortcut, in simple words, is to use our Host machine running Redox OS, to run a Virtual Machine with another OS (Linux/Windows) as the guest, and then cleverly use the drivers and apps that can run on that guest OS to help coverup the missing drivers and apps on Redox OS. This is not a novel solution, but it is quite clever and ingenious. I’m wondering how this would impact performance, and if stability suffers from going through several layers like this. There’ll be a more detailed post with technical details of the implementation later on, so keep an eye out for that one.
Today it’s been three weeks since my 4th RSoC started, where the main focus this time is to speed up Redox by implementing on-demand paging in the kernel. I don’t really understand any of this, but I know OSAlert readers love this sort of nitty gritty stuff.
We have a lot to show since the 0.7.0 release! This release, care has been taken to ensure real hardware is working, i686 support has been added, features like audio and preliminary multi-display support have been enabled, and the boot and install infrastructure has been simplified and made more robust. I highly recommend skimming through the changes listed below before jumping into the images, if you want more details. It is also recommended to read through the Redox OS book if you want more information on how to build and use Redox OS. Redox OS is written in Rust, and created and maintained by System76 Principal Engineer Jeremy Soller. There’s a ton of changes in this release – far too many to list here – and while native installation is possible, there’s always going to be struggles with hardware support for any alternative operating system.
In my last blog post, I introduced the userspace_fexec/userspace_clone features. As the names suggest, they move the inherently complex implementations of fork(3) and execve(2), from the kernel into relibc, giving userspace much more freedom while simplifying the kernel. There has been considerable progress since last post; the features userspace_fexec/userspace_clone, userspace_initfs, and userspace_initfs, have now all been merged! I understood some of those words.
So, as part of RSoC 2022, I have been working on introducing Virtualization on Redox OS. This feature/technology is called Revirt and has wide-ranging consequences for Redox OS as a secure, well-designed, virtualizable and effective operating system. This is a big new addition to Redox OS.
A lot has changed since release 0.6.0! First thing, it is impossible to collect all the changes that happened since December 24, 2020 into one set of release notes, so this will focus on the highlights. It was very important to me that this be a release targeting the foundations of Redox OS. This includes, the bootloader, the filesystem, the package manager, the kernel, the drivers, and much more. The focus was on enabling Redox OS to boot on the widest set of hardware possible. Redox is a Rust-based operating system with a microkernel and a UNIX-like paradigm and an optional GUI. Its lead developer works for System76 as principal engineer.
Now, the reason for not finishing is that I’m basically done! That’s right, GDB has served us reliably for the past few weeks, where we’ve been able to debug our dynamic linker (ld.so) and find problems with shared libraries. We got to the point where the amazing @bjorn3 has managed to run his first rust program compiled on Redox using his rustc cranelift backend! While obviously we would’ve found the bugs without gdb eventually, I’d love to attribute enough credit to it that it warrants being posted here! Redox OS is an operating system written in Rust.
Redox OS 0.5.0 has been released. It has been one year and four days since the last release of Redox OS! In this time, we have been hard at work improving the Redox ecosystem. Much of this work was related to relibc, a new C library written in Rust and maintained by the Redox OS project, and adding new packages to the cookbook. We are proud to report that we have now far exceeded the capabilities of newlib, which we were using as our system C library before. We have added many important libraries and programs, which you can see listed below. Redox OS is a UNIX-like operating system written in Rust, built around a microkernel.
Redox 0.3.3 has been released. Redox is an operating system written in Rust.
This release brings much lower memory usage with ISO - 480 MB instead of 1300 MB. There are also other bug fixes, features, and improvements.
Redox OS, a microkernel OS written in Rust, hast just released version 0.0.6, which includes bug fixes and and update to Rust.
From the project's 2016 in review post:
Today, we have a pretty mature project. It contains many core, usable components. It is already usable, but it is still not mature yet to be used as a replacement for Linux (like BSD is), but we’re slowly getting there.
The kernel was rewritten, a memory allocator was added, rendering libc out of the dependency chain, several applications were added, a file system were added, a window manager and display server was implemented, and so on.
Redox, a Unix-like operating system written in Rust, recently rewrote its kernel:
Since August 13, the kernel is going through a complete rewrite, which makes the kernel space ultra-small (about the size of L4). Everything which can run outside the kernel in practice, will do so.
It is almost complete and will likely be merged in the coming week.
The reasons cited for the rewrite include memory management, concurrent design, SMP support, and 64-bit by default.
Redox is a general purpose operating system and surrounding ecosystem written in pure Rust. Our aim is to provide a fully functioning Linux replacement, without the bad parts.
We have modest compatibility with Linux syscalls, allowing Redox to run many Linux programs without virtualization.
We take inspiration from Plan9, Minix, and BSD. We are trying to generalize various concepts from other systems, to get one unified design. We will speak about this some more in the Design chapter.
Redox runs on real hardware today.
Submitted by 
Guest post by 
Guest post by