Version 0.5 of Redox OS was released yesterday, which includes a new C library written in Rust and images based on new bootloaders for both coreboot and EFI.
It's taken a while since the previous release of Redox OS as they have been focusing their attention on Relibc, a C library implementation written within the Rust programming language. Relibc is now used as the operating system's default C library.
Redox OS 0.5 also includes improvements to its event system, Pthreads support was completed, better support for LLVM and LLVM-using projects like Mesa/LLVMpipe, improvements to EFI, and more.
Some new Rust-written packages for Redox OS include OpenGL wrappers, an audio library, and other additions. Outside of the Rust scope, Redox OS 0.5 adds in SDL2 packages, Cairo, FFmpeg, and many other important software options.
There's a new operating system that wants to do away with the old mistakes and cruft in other operating systems. It's called Redox OS and is available on GitHub. It's aimed at creating an alternative OS that is able to run almost all Linux executables with only minimal modifications. It features a pure ecosystem using the Rust programming language which they hope will improve correctness and security over other OSes. They are not afraid to prioritize correctness over compatibility. The philosophy being that "Redox isn't afraid of dropping the bad parts of POSIX while preserving modest Linux API compatibility."
Redox levels harsh criticisms at other OSes, saying "...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.
Redox OS seems to be supported on the i386 and x86_64 platforms. The aims are microkernel design, implementation in Rust language, optional GUI — Orbital, newlib for C programs, MIT license, drivers in userspace, common Unix commands included, and plans for ZFS.
They want to do away with syscalls that stay around forever and drivers for hardware that, for a long time, simply isn't possible to buy any more. They also provide a codebase that doesn't require you to navigate around 25 million lines of code like Linux.
Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system? One aspect to look out for is if they map the graphic cards into user space.
Lead Redox OS developer Jeremy Soller tweeted that "it's time for Redox OS to become a Coreboot payload." It looks like Redox OS is working on native Coreboot payload support for this interesting Rust operating system rather than first needing to use one of the bootloaders as a Coreboot payload before hitting Redox OS.
[...] The Redox OS twitter also went on to outline they are working on fixes to their networking stack, fixes to curl / cargo / git, advancing towards the state of being able to self-host itself (build Redox OS on Redox OS), improving the relibc C library implementation, porting more applications to running on Redox OS, and at that point to also prepare a new release. And, yes, exploring Coreboot payload capabilities.