Another month, another Redox progress report. January turned out to be a big month for the Rust-based general purpose operating system, as they’ve cargo and rustc working on Redox.
Cargo and
↫ Ribbon and Ron Williamsrustcare now working on Redox! Thanks to Anhad Singh and his southern-hemisphere Redox Summer of Code project, we are now able to compile your favorite Rust CLI and TUI programs on Redox. Compilers are often one of the most challenging things for a new operating system to support, because of the intensive and somewhat scattershot use of resources.
That’s not all for January, though. An initial capability-based security infrastructure has been implemented for granular permissions, SSH support has been improved and now works properly for remoting into Redox sessions, and USB input latency has been massively reduced. You can now also add, remove, and change boot parameters in a new text editing environment in the bootloader, and the login manager now has power and keyboard layout menus. January also saw the first commit made entirely from within Redox, which is pretty neat.
Of course, there’s much more, as well as the usual slew of kernel, relibc, and application bugfixes and small changes.
> the usual slew of kernel, glibc, and application bugfixes
I am assuming that glibc is a typo and that relibc was meant. There are indeed quite a number of updates to relibc as always. Relibc is of course the C standard library written in Rust for both Redox and Linux. Relibc replaces glibc. I do not believe that glibc supports Redox (or vice versa).
I am looking forward to relibc maturing enough that a Linux distro could use it. Something as critical and and universal as the C standard library seems like the perfect target for Rust and its emphasis on memory safety. We could have a “Redox Linux” in addition to RedoxOS.
LeFantome,
Yes, that would be (and perhaps will be) interesting milestone to get the standard C library implemented in rust.
Although I’d still argue that C interfaces should not be the long term goal, even if they happen to be implemented by rust. The C interfaces themselves still remain unsafe. Ideally we could supersede them with new interfaces that provide compile validation against memory errors. Since rust does this, it could be done with rust, but I’m not necessarily saying it has to be done in rust. It could just be a new linking standard akin to C function prototypes but with ownership & safety information built in. Then all languages that implement the new safe standard could implement it and be compatible with each other, including but not limited to rust.
This IMHO should be the long term evolution of memory safe languages and interfaces. There are still so many C developers who resist rust, but perhaps they’d be less averse to a more neutral linking standard that provides safety, yet is not specific to rust.