Submitted by A number of new projects have been introduced during this release cycle, and many improvements have been landed. Very many bugs have been squashed. This list is an extreme over-simplification of the thousands of commits done since the last release. Hopefully, releases will happen more often so this is not always the case.
o rmm, a complete rewrite of the kernel memory manager. This has eliminated kernel memory leaks, which became quite an issue with the previous memory manager. Additionally, multi-core support is far more stable.
o Much of the work of RSoC, sponsored by donations to Redox OS, has been integrated into this new release. This includes work on ptrace, strace, gdb, disk partitioning, logging, io_uring, and more.
o relibc has seen a large amount of work, culminating in improvements for anything that depends on it (i.e. everything in userspace).
Redox is a UNIX-like operating system written in Rust, running on a microkernel.
From what I can tell, Redox isn’t a microkernel in the strict sense because it has a Unix API subset including a VFS implemented as primitive system calls in the kernel. It’s more akin to a Plan 9-style atypical monolithic kernel. If it had the Unix API subset implemented as a colocated server accessed through messages rather than primitives (like QNX) I would say it could be considered a (not quite pure) microkernel, but Unix-like API primitives disqualify a kernel from being a microkernel as far as I’m concerned.
However, in practical terms I guess there isn’t a whole lot of difference when it comes to single-personality Unix-like microkernel and near-microkernel OSes whether the core Unix functionality is built into the main kernel as primitives, is implemented as a colocated server, or runs as a separate process (although running it in a separate process may make certain types of attacks slightly harder).
So many great ideas in this one.
More Plan 9 ideas in an OS: YES. And not the obvious ones like procfs, which isn’t that great of an idea without ACLs or another control mechanism.
It could grow into a pure microkernel as it matures. It would be interesting to see if it takes a concept like containers, jails, or cgroups and adapts them to fit within a microkernel where the reality is all calls are emulated and processes live in something like their own personal Matrix.
I went looking for a higher level of purpose than “Redox is written in Rust, is Unix-like and has a micro-kernel”. It seems that this is it: From https://www.redox-os.org/:
” …. Redox is a Unix-like Operating System written in Rust, aiming to bring the innovations of Rust to a modern microkernel and full set of applications.”
Why bother?
BTW – my point is more about stating a purpose at a higher inspiring level rather then Redox is a waste of time. It’s not obvious to everyone why the combo of Rust, Unix and alleged MicroKernel is such a big deal. What is the higher level benefit / breakthrough /world changing impulse?? There might be one.
It’s the Venn diagram of the three which is exciting. A Unix-like, microkernel-ish OS written in C is Minix (which is probably Redox’s closest competitor) or Hurd. A Unix-like, microkernel-ish OS written in Rust is Redox, and that is pretty unique.
It’s one of the few FOSS operating systems to move beyond C or C++, and other systems written in memory safe languages were toy research projects which went nowhere. The other FOSS OS projects aren’t interested in pulling in and supporting another toolchain, so a new OS is the best way Rust is going to get supported in a FOSS OS. All those lines of kernel C code isn’t going to rewrite itself, and as such, there isn’t a point is switching to Rust, as Theo likes to point out.
Another Unix-like means, there is software available for it. With a little effort, you to can run on Redox. It’s a very pragmatic angle to take. It could do some really weird stuff from the start, but then it would be another OS without any software. Get a solid base established, and then do the really weird stuff. As it stands, it could eventually be a replacement for any of the Unix like operating systems out there.
This thing may have a shot at being something other then an obscure oddity, and that is exciting.
The biggest problem I see with Redox is that they are reinventing the wheel for everything rather than integrating existing code wherever possible. Time spent reimplementing drivers or common Unix utilities is time that won’t be spent on improving the stuff that actually sets it apart. Also, for drivers, a small project like this is going to have a much more difficult time maintaining a decent range of hardware compatibility writing all their own drivers rather than using a library kernel like rump or LKL (which should be relatively easy to do in an OS with user-mode drivers). As far as I’m concerned, it’s not worth it to write everything from scratch just so it’s written in Rust. I think it’s better to write new components/subsystems where there’s no existing code that’s sufficient, but integrate existing code where there is. I’d be a bit surprised if Redox actually becomes particularly useful in the real world (another reason besides their insistence on NIHing almost everything is that they seem to have abandoned the idea of writing a Linux binary compatibility layer, limiting application support significantly).
I’m actually in the process of writing my own OS that’s sort of similar in concept to Redox in that it will be a Unix-like system with a significant amount of Rust code and pervasive support for user-mode filesystem servers (mine is a true microkernel system that is based on seL4 and will somewhat resemble QNX). The insistence on writing almost everything from scratch and the VFS architecture (there is no need to introduce a redundant prefix name space for schemes when you already have mount points; that makes it harder to have multiple instances of one server in a namespace or for servers to act as filters that override interfaces of other servers) are the main reasons I’m writing my own system instead of contributing to Redox (that, and I’d been planning my system out a long time before). I’m going to reuse existing code wherever it doesn’t conflict with my architectural goals (this includes using the LKL project to get full access to Linux drivers). Hopefully that plus the Linux binary compatibility layer will give my system a reasonable chance at success.
I don’t think there needs to be any purpose beyond “This is cool.” and “I wanted to do it.”
Indeed. Why does OSAlert exist if not for those two statements?