Redox OS Archive

Redox replaces core applications with COSMIC applications

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.

Redox gets USB HID support

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.

Redox: significant performance and correctness improvements to the kernel

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 gets massive performance boost

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.

Redox gets more Linux utilities, changes resource path format, and more

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: development priorities for 2023 and 2024

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.

Redox Summer of Code 2023 Wrapup

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.

Apps and driver support in Redox OS

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.

Redox OS 0.8.0 released

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.

RSoC: improving drivers and kernel – part 7

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.

Revirt: virtualization on Redox OS

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.

Redox OS 0.7.0 released

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.

You can now debug programs using GDB on Redox OS

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 released

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.

Rust-based Redox OS 0.0.6 Released

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.

A complete rewrite of the Redox kernel

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.

The Redox operating system

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.