No it wouldn't. People have been trying that for decades, the performance is always awful.

>>107741408
I don't see any reason why performance should be worse than on a monolithic kernel other than the fact that they tend to receive less development and support.

>>107740569
Windows will be fully Rust before Redox is complete.

>>107741514
Okay but my interest is more in the microkernel and security features than Rust. I'd extend it to GNU Hurd if I had any faith in it ever being useable.

>>107741499
That's because monolithic kernels have never been tried. No, not even Linux. It's a hybrid LARPing as a monokernel, but it's not. The Finnish retard copied the API from a self-admitted microkernel (Minix), whose explicit purpose was to keep complicated shit out of kernelspace.

A true monokernel wouldn't block on open and reads. A true monokernel would allow you to create sockets and FDs in batches. A true monokernel would have compound functions (open + mmap + close) for the most common patterns.

>>107742231
Also, a true monokernel would've probably used something like shared mappings between user and kernel to properly utilize memory layout and out-of-order execution, and write-lock the plot upon submission to make sure that the thread cannot modify the data in mid-flight. *And our current hardware doesn't support that very well* because the page table is a process-wide resource, not a thread-local one - meaning that, if you write-lock pages, you end up with per-core TLB shootdowns that can easily take much longer to complete than just copying all parameters from userspace to kernelspace, even if it's an in-order copy.

Oh, and speaking of TLB shootdowns:
>batched mmap

>>107740569
>How is RedoxOS coming along?
Well, is it at all? They had an interesting idea about "everything is a URL" but them went back on that fo rmore UNiX like philosophy. And that was after all the drama and purges. So after 10 years it is still not as advanced or usable as Linux was after 4 years.