Development Priorities for 2023/24

By Jeremy Soller and Ron Williams on

We’ve made great progress this summer, as all the pieces of Redox continue to come together to create a complete operating system.

To give a big-picture perspective for where Redox development is headed, here is our view of priorities as of September, 2023.

Redox ABI

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.

Redox Server

We want to develop a Server version of Redox. This is a higher priority than desktop because it is presumed to be a smaller scope. We have some work to do on optimizing drivers, especially network drivers. The foundation is very much there and porting common server programs is an important step to take - things like Apache, Nginx, etc.

Self-Hosting the Redox Website

We would like to host the Redox website on Redox running in a virtual machine. The Redox Summer of Code projects have been filling in some of the gaps we have had for virtual machines. Having drivers like the ones Andy worked on for VirtIO will enable much lower latency and higher performance virtual machines running Redox. It gets us to the point where we might be able to run Redox on a cloud machine, like EC2 or DigitalOcean.

Virtual Machine Support

There is a lot of work to be done on virtual machine support, device virtualization and Redox as a hypervisor. Some of the Summer of Code work was in this area, and we are hoping to see this work continue.

Self-Hosting the Build System

We want to self host the build system. This has been a very long term goal that we have been working on over the entire course of Redox, and a very important one. We have been able to port GCC, Binutils and other aspects of the build system to Redox, but the one remaining issue is that rustc itself doesn’t work very well on Redox. The work we have to fix that is pretty involved, it’s at all places in the stack.

Developer Tools

We need to work on porting developer tools to Redox. That involves identifying the tools we want to port and ensuring that they are running properly. We have a lot of the basic things there, like the ability to compile C programs, Python and Lua and some other scripting languages that have been partially ported.

But the big one is still rustc, and then after that, porting other popular languages. Elixir and Go, for example, have their own runtime and are therefore more difficult than C and C++.

We also still have a lot of work to fully support C and C++, because of missing aspects of relibc that need to be fleshed out, e.g. wide string support.

Performance

We need to start giving more attention to performance and responsiveness, and making Desktop and Demo go faster is an important part of that.

A majority of how people will interact with the system is to download our ISO and try it out on real hardware. That’s a common thing for Linux distributions and we should assume that people will be trying to do with Redox. Right now we have some issues that are stopping us in that direction. The support for virtual machines is far better than for real hardware. Our device drivers try to target common hardware, but they don’t always work well. For example, the high definition audio driver may work on one machine but hang on another machine. Preventing hangs like that across the entire set of drivers that we have is a very important part to getting people to be able to see our demo image running on real hardware at native performance.

Then there is optimization. 4lDO2 has been working on various optimizations, like on demand paging. Jeremy likes to port a lot of games, emulators and things like that, because it’s another way to see the performance. When you can make a game run properly at very high speeds and very low latency, then you know the rest of the stack is basically good. It becomes an easy benchmark to compare as you make changes.

Cosmic Desktop

The Cosmic Desktop is something being worked on at System 76, where Jeremy works. It’s an open source Linux desktop environment that is written mostly in Rust, and that aligns it with the goals of Redox. There are some things we need to work on to have Cosmic Desktop on Redox.