What are the things about Redox that aren't strictly Unix (or maybe POSIX) which you feel are marked improvements over Unix that folks with a general interest Unix & OS development should know about?
FreeBSD has a pretty broad linuxkpi layer for Linux drivers on FreeBSD as well. E.g., the Mellanox FreeBSD NIC drivers are really Linux drivers running on this framework.
What are the plans for bridging the ecosystem?
- Is there a Linux compatibility layer?
- Is there X11 support in Orbital?
- How difficult is porting Linux apps?
- I absolutely love the idea of using a memory-safe language for an OS, but realistically people will use whatever language they feel comfortable with for writing apps.
- Is it possible to write applications in something other than Rust?
Hi Jeremy,
I'd love to hear what your thoughts are on Rust after building something like this. As someone who's relatively new to both Rust and OS development, I'm curious what some of the challenges have been around core data structures often found in kernels where ownership can be ambiguous or complex, and developing without the support of a runtime/standard library. Has Rust passed the acid test of OS development in your eyes?
core is very comprehensive and alloc adds dynamic allocation once your kernel supports a heap. The complicated data structures in kernels are much easier to write in Rust, in my opinion. And you can be certain of their consistency when you have multiple cores running kernel code because of the ownership model.
I prefer doing bare metal development in Rust if possible
Redox looks very interesting. It seems one good approach might be to force new apps and drivers for Redox itself, but provide a VM environment that would run sandboxed Linux and other OS's securely. (Similar to the Qube OS idea.)
That way Redox could offer a considerably improved API and app development environment without worrying about backward compatibility, while being useful as a daily driver in the meantime.
Making the view releases button do something that isnt propping for a gitlab login, might entice people to make it past your homepage. Heck, add a "try it" button that redirects to the Book.
The performance problem has only gotten worse with time.
Modern CPUs have a rough time switching tasks. There are all those mitigations for meltdown and spectre. Even before that though, the situation with the TLB was ugly.
Limiting your data structures to ones that are friendly to message passing will really hurt you. Hacks to minimize the performance loss add complexity.
Fundamentally, glue isn't free. The parts may be simple, but the interactions are not.
Most embedded OSes for high integrity computing are microkernel based, then there is QNX, Minix running in legions of Intel CPUs, Android's workaround to have drivers as userspace processes with Android IPC as means to increase Android security and provide a proper driver ABI with Treble, and the ongoing push from Apple to move all kernel extensions into userspace, and then all those type 1 hypervisors.
Hardware IOMMU's have certainly made microkernels a lot more viable than they used to be in the past. You can actually place meaningful protection boundaries around core hardware drivers; they're no longer part of your inherent trust base, as they would be in a system where IO transfers can involve arbitrary memory.
How mature are the network stack and FS? I see a ZFS inspired FS named TFS, very cool! I’m assuming it can run headless but see it’s got a GUI from the book.
This is more what I meant. It just seems like Redox is taking the lessons we've learned over years of development, and being willing to break compatibility in order to implement them.
That being said, I don't know much about OS/kernel development.
So is Google fuchsia - it is even capability based. (But Google is not cool here around HN circles, despite their contributions to open source and fostering one of good engineering environments, they aren't cool because they don't shout some Privacy buzzword like Apple.) Also it is not written in rust, which is webshit-favorite-of-the-month.
Redox is still Unix like, it moderately changes the file paradigm. Microkernel Unix clones are not new. They mention Minix as inspiration while there is no mention of L4 which did lot of work in microkernel performance.
At least it is capability based instead of yet another Unix clone. Not that any one of these are significantly better. But the rust crowd heralds redox as very innovative OS.
Redox also has it's own non-standard shell that has been worked on for a while, called Ion. I don't believe it's entirely POSIX-compatible, and has some neat features of its own. That said, it's certainly possible someone could end up porting over Nushell to work on Redox, but I don't think that's currently on their roadmap.
The default shell is ion, a shell written in Rust and maintained as part of Redox. But I don't see it as important what the default is, so long as it is configurable.
We have ported bash and dash, so far. I think porting nushell wouldn't take much work
What alternative data structures do you have to use inside the kernel to provide good performance and satisfy the borrow checker without writing a lot of unsafe code?
