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 is good to see the frequent communication. As an outsider, it is good to see the progress. It feels like they are starting to get broader participation in the project. Communication can help with that.
It certainly feels like Redox is poised right on the edge of greater things. The updates are starting to be more about applications and things relating to the user experience rather than deeply technical or foundational stuff. There is still lots more of that to do of course but it is interesting to think that Redox could become ready for at least some niche users and use cases.
I think that supporting COSMIC was a good decision. One, there is a lot of excitement around that desktop there is the marketing halo. More than that, this a lot of effort to harness for “free” in the project. Redox will directly benefit from all the effort that went into COSMIC files for Alpha 2 as an example. One less thing for them to do and at the same time a lot better first impression with users checking out or trying to drive Redox in the future If they are able to use not just the applications but the entire desktop in the future, that will bring Wayland which brings a whole universe of modern applications ( or certainly will by that point ). Cool that they partnered with Servo as well.
Along with their strategy around Relibc, it seems they are being very pragmatic. That provides a lot more confidence that they will get there. With Jeremy working at System76, it should not be hard to find at least some real hardware to run Redox on. I know their goal is real hardware support more generally but that is a massive undertaking. I hope it does not slow them down or distract them too much from getting the base system in a good place.
Is the acceleration in progress in Redox evidence that developers of this language are migrating across after the failure of Rust on Linux? Certainly it seems to have gone very quickly from “interesting hobby project” into “something with a future” but I wonder if it has scaled back it’s innovations in OS design to achieve that?.
On its homepage it says: “Inspired by Plan 9, Minix, seL4, BSD and Linux” but I think it most resembles HURD!
Design-wise, I would say that Redox is more ambitious than Linux in its early days. For one thing, it is a microkernel. It is creating its own Copy-on-Write filesystem. It has created its own windowing system. It is creating its own C library ( Linux created a simply one and then famously migrated to GNU ). It is also having to work towards Linux compatibility which is a harder target than just POSIX.
So, if they are making rapid progress, it is not because of a lack of ambition. It does not seem to be because of a wealth of developers either. For much of the time, it was really just one guy. There seem to be more contributors now but it is still just a handful.
The safe language advocates claim that productivity is higher because you can “fearlessly” refactor and parallelize. To oversimplify, it is harder to get your code to compile but, once it does, you have a higher confidence that it is correct. So you can be more ambitious with your design and yet spend less time chasing down bugs. I have not written anything big enough in Rust to know if this is true. Perhaps progress on Redox provides some evidence.
I also think that we “feel” the progress on Redox because they communicate well as a project. That really helps. I think it is also likely to attract more interest and maybe more devs. That will also help.
tanishaj,
There’s a ton that “just one guy” can accomplish. OS building blocks are doable but the far bigger obstacle is the significant amount of resources needed to develop & support hardware and applications that end users want/need to support. Implementing drivers eats up development resources like crazy, and in many cases even just solving the problem of hardware availability & logistics for testing is too difficult and expensive for small projects. Linux only managed to brute force it’s driver base with armies of contributors reverse engineering hardware over decades. A small number of devs can work on the building blocks as long as they limit the scope and don’t try to support everything because that’s where I think they’ll run into trouble.
It’s like reimplimenting the “Common Unix Printing System” (CUPS). It’s totally plausible for one person to implement a new printing system using safe programming languages, however actually supporting tens of thousands of printer models would be an insane undertaking. This is why change is hard. The bridge-gap solution may have to be a compatibility layer such that we keep supporting C code, but then many people won’t see the point given that manufacturers will stick with the dominant C interfaces.
Maybe there could be an opportunity for AI to reverse engineer drivers and output rust source code without having to commit so many human developers to this task.
Obviously incorrect logic can still be written & executed under rust, but it does eliminate the memory and threading faults that C is notorious for, which is a significant advantage IMHO. These kinds of faults should only exist in the rear view mirror IMHO. We are far from overcoming C’s dominance in system software though.