Redox OS Archive
Every time a new Redox monthly report comes out, I’m baffled by the fact we’ve apparently rounded another month. They just keep on coming and going, don’t they? And I even turned 40 this 1 December, so it hits even harder this time. I’m now as old as I remember my parents were in some of my oldest memories, and now I’ve got two kids of my own. Wild. Time isn’t supposed to move this fast, and I strongly advise the Redox team to stop this madness. Anyway, this month also saw the release of the 4th alpha of system76’s new COSMIC Linux desktop environment, and the parts of COSMIC available on Redox were updated to reflect that. This past months also saw a major milestone: the RISC-V version of Redox running in an emulator on the x86-64 version of Redox. That’s quite the feat, and highlights just how capable Redox has become in such a short time. There’s also the usual list of kernel, driver, and relibc improvements, as well as additional Rust programs ported to Redox. Also highlighted in this report: a video detailing how to build Redox under Windows Subsystem for Linux. This could be a great avenue for operating system developers who use Windows to get their feet wet at building Redox on their own systems.
Another month lies behind us, so another monthly update from Redox is upon us. The biggest piece of news this time is undoubtedly that Redox now runs on RISC-V – a major achievement. Andrey Turkin has done extensive work on RISC-V support in the kernel, toolchain and elsewhere. Thanks very much Andrey for the excellent work! Jeremy Soller has incorporated RISC-V support into the toolchain and build process, has begun some refactoring of the kernel and device drivers to better handle all the supported architectures, and has gotten the Orbital Desktop working when running in QEMU. ↫ Ribbon and Ron Williams That’s not all, though. Redox on the Raspberry Pi 4 boots to the GUI login screen, but needs more work on especially USB support to become a fully usable target. The application store from the COSMIC desktop environment has been ported, and as part of this effort, Redox also adopted FreeDesktop standards to make package installation easier – and it just makes sense to do so, with more and more of COSMIC making its way to Redox. Of course, there’s also a slew of smaller improvements to the kernel, various drivers including the ACPI driver, RedoxFS, Relibc, and a lot more. The progress Redox is making is astounding, and while that’s partly because it’s easier to make progress when there’s a lot of low-hanging fruit as there inevitably will be in a relatively new operating system, it’s still quite an achievement. I feel very positive about the future of Redox, and I can’t wait until it reaches a point where more general purpose use becomes viable.
Hot on the heels of releasing Redox 0.9.0, the team is back with yet another monthly update. Understandably, it’s not as massive of an update as other months, but there’s still more than enough here. There’s the usual bug fixes and small changes, but also more work on the port to RISC-V, the QEMU port (as in, running QEMU on Redox), a bunch of improvements to Relibc, and a lot more.
It’s been two years, but we finally have a proper new Redox release: the Redox team released version 0.9.0 today. Since we’ve been covering all the monthly progress reports from this Rust-based operating system for a long time now, we’ve already covered most of the improvements in this new release, so if you’ve been following along there shouldn’t be any major surprises in here, but let’s do a quick summary anyway just so we’re all up to speed. I think the primary thing anyone moving from the previous release to the new one will be massive performance and stability improvements, as well as the arrival of the first few applications from System76’s new COSMIC Desktop. Redox is led by Jeremy Soller, a System76 engineer, and since COSMIC uses Rust as well, it only makes sense for the two projects to start benefiting from each other’s progress. Porting Linux and BSD programs has also become a lot easier, which is also evidenced by a whole slew of new ports from those operating systems. Redox works in both virtual machines and on real hardware, but the former is definitely advised over the latter. In the latest monthly progress report, which was published only a few days ago, it’s mentioned that Redox performance in virtual machines has improved greatly. The team discovered that reading the system time was a huge bottleneck in the context switching code, which affects virtual machines particularly hard because it needs to be read from outside oft he VM. Redox now reads the TSC using KVM’s paravirtualized system time API to remove this bottleneck. Running in a VM, Redox is now becoming slightly faster than Linux at certain synthetic benchmarks, for example the same-core context switch latency when using POSIX pipes (tested with mitigations=off). More exciting optimizations are coming, both to reduce context switch overhead further towards the hardware limit, and to reduce unnecessary context switches overall. ↫ Ribbon and Ron Williams As time moves on and both Redox and COSMIC improve, my excitement for this operating system grows along with it. It seems the people working on both projects have their priorities quite straight, and while I’m obviously not going to make any idiotic grand statements about how Redox will replace anything, I wouldn’t be surprised to see it become a fairly solid option for those of us willing to deal with the issues that come with running something that isn’t Windows, Linux/BSD, or macOS.
In line with the release of the COSMIC alpha, parts of which are also available for Redox, we’ve got another monthly update for the Rust-based operating system. First, in what in hindsight seems like a logical step, Redox is joining hands with Servo, the Rust-based browser engine, and they proposed focus will be on Servo’s cross-compilation support and a font stack written in Rust. It definitely makes sense for these two projects to work together in some way, and I hope there can be more cross-pollination in the future. Simple HTTP Server, an HTTP server written in Rust, has been ported to Redox, and the Apache port is getting some work, too. Wget now works on Redox, and several bugs in COSMIC programs were squashed. UEFI also saw some work, including fixing a violation of the EUFI specification, as well as adding several workarounds for buggy firmware, which should increase the number of machines that can boot Redox. Another area of progress is self-hosting, and Redox can now compile hello world-programs in Rust, C and C++ – an important step towards compiling more complex programs and the end-goal of compiling Redox itself on Redox. There’s way more in this update, so head on over to get the full details.
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 OSNews 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.
