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.
I said it before, but my theory to explain this accelerated pace of development of late is that Redox benefitted from a windfall of Rust talent after the apparent failure of “Rust on Linux”.
Have any of the “Rust on Linux” people gone to Redox? It feels like quite a small core of people that have been working on Redox since the beginning.
I think Rust itself explains some of the pace. However, there is some overlap with their day jobs ( witness COSMIC on Redox for example ). Given the small number of people, the progress has been impressive especially given the scope of what they are taking on: microkernel, COW filesystem, full C library, and ground-up graphics to name a few.
I am not sure they are even self-hosting yet ( though self-hosting a full LLVM / Rust toolchain is quite an achievement ) but it is interesting to see how much “real” software they are starting to run. Certainly a project to watch.
As a final thought: has “Rust on Linux” failed? First, I assume you mean Rust “in” Linux as there is A LOT of Rust on Linux already ( including the upcoming COSMIC of course ). Just this morning I installed ab-av1 to help maximize quality for video encoding and I see that it is written in Rust. I cannot keep track of how many Rust apps I see these days. As for Rust “in” the kernel, while there are some clear obstacles, it seems to be moving about as fast as anything significant in Linux does. I was certainly impressed with how fast the Apple Silicon GPU driver for Linux was written in Rust and the dev write-up about it was pretty glowing. Its evolution since the first release has been very impressive as well.
I stand corrected: it is not “rust on linux” but Rust *for* linux. I understand the idea is that Rust would be supported in Linux kernel alongside C for things like drivers.
Anyhow this project has apparently experienced acrimony with the leader of these efforts resigning in frustration.
https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_down/
Yeah, I think understand the issue there. There isn’t a right or wrong party. The interaction and roles between the C devs and rust devs hasn’t been established to each’s satisfaction. It not being a company to tell people how to behave and clearly define responsibilities, means it has to happen gradually.
Oh for sure, there is lots of conflict. And Rust is causing more than perhaps past issues have. But directionally, this is just what Linux kernel dev is like. Linus has certainly left a few devs consumed by flames and people do quit the community or give up contributing as a result. Check out the drama between the bcachefs filesystem maintainer and Linus for example ( who has threatened to remove it from the kernel ). To me, the resistance to Rust and the frustration with how hard it is to drive change through the Linux kernel community feels like the latest incarnation of an old tradition.
tanishaj,
Maybe I’m biased, but Ted Tso seems to exhibit hostility towards rust and memory safety initiatives. He does not seem interested in finding a way to work together towards the common goal, and this undermines rust uptake inside of linux. For better or worse he did deal a blow. I wholly understand why Filho felt his work was not welcome nor appreciated.
I can understand why Tso may feel insecure with newcomers joining the project with different ideas for linux, but I still kind of wish he could set a better example for working together.. A point was made in Squizzler’s link that complacency increases the risk that linux will fall behind on security as safe programming language advocates get pushed out and discouraged from working on linux.
@Alman
I agree with you completely. Ted is doing real damage. He is also being a jerk and, from afar, it appears to be mostly insecurity. I do not argue any of that.
The first point talked of the “apparent failure” of Rust in Linux though. I do not believe that it has failed at all. In the end, If Ted does not come around, he will eventually be left behind.
Change in Linux is often slow. They are not going to adopt Rust everywhere overnight. As far as I can tell though, it has not failed at all. Early days is all.