On Mon, Feb 08, 2021 at 12:11:08PM -0600, Will Senn wrote: I can answer the microkernel question I think. It's discipline. The only microkernel I ever liked was QNX and I liked it because it was a MICROkernel. The entire kernel easily fit in a 4K instruction cache. The only way that worked was discipline. There were 3 guys who could touch the kernel, one of them, Dan Hildebrandt, was sort of a friend of mine, we could, and did, have conversations about the benefits of a monokernel vs a microkernel. He agreed with me that QNX only worked because those 3 guys were really careful about what went into the kernel. There was none of this "Oh, I measured performance and it is only 1.5% slower now" nonsense, that's death by a hundred paper cuts. Instead, every change came with before and after cache miss counts under a benchmark. Stuff that increased the cache misses was heavily frowned upon. Most teams don't have that sort of discipline. They say they do, they think they do, but when marketing says we have to do $WHATEVER, it goes in.

On 2/8/21, Will Senn &lt;will.senn(a)gmail.com&gt; wrote: Yes, those are almost exactly my thoughts on the current state of OSes. I'm hoping that I can change it by writing my own OS <https://gitlab.com/uxrt/>, because I don't see anyone else making anything that I consider to be a particularly good effort to solve those issues. However, it's still anyone's guess as to whether I will succeed. I'm trying to give it every chance of success that I can though by using existing code wherever possible and focusing on compatibility with Linux (or at least I will be once I get to that point). BTW, I welcome any contributions to UX/RT. I currently am still only working on the allocation subsystem (it's a bit trickier under seL4 than it would be on bare metal due to having to manage capabilities as well as memory), but I think I am pretty close to being able to move on. A lot of people still seem to believe that microkernels are inherently slow, even though fast microkernels (specifically QNX) predate the slow ones by several years. Also, it seems as if much of the academic microkernel community thinks that there's a need to abandon Unix-like architecture entirely and relegate Unix programs to some kind of "penalty box" compatibility layer, but I don't see any reason why that is the case. Certainly there are a lot of old Unix features that could be either reimplemented in terms of something more modern or just dropped entirely where doing so wouldn't break compatibility, but I still think it's possible to write a modern microkernel-native Unix-like OS that does most of what the various proposed or existing incompatible OSes do. I still don't get why QNX hasn't had more influence on anything else even though it's been fairly successful commercially. If i am successful, UX/RT will only be the second usable non-QNX OS with significant QNX influence that I am aware of (after VSTa; there have been a couple other attempts at free QNX-like systems that I am aware of but they haven't really produced anything that could be considered complete). seL4 is fairly similar to QNX's kernel both in terms of architecture and design philosophy. That's why I'm using it in UX/RT. I may end up having to fork it at some point, but I am still going to keep to a strict policy of not adding something to the kernel unless there is no other way to reasonably implement it. For the sake of extensibility and security I'm also going to have a strict policy against adding non-file-based primitives of any kind, which is something that QNX hasn't done (no other OS has AFAICT, not even Plan 9, since it has anonymous memory, whereas UX/RT will use memory-mapped files in a tmpfs instead). On 2/8/21, Dan Stromberg &lt;drsalists(a)gmail.com&gt; wrote: The biggest problem I see with Redox is that they insist on writing everything from scratch, whereas with UX/RT I am going to use existing code wherever it is reasonable (this includes using the LKL project to get access to basically the full range of Linux device drivers, filesystems, and network protocols). Also, their VFS architecture is a bit questionable IMO. Otherwise I might have been inclined to just contribute to Redox (UX/RT will use quite a bit of Rust, but it won't try to be a "Rust OS" like Redox is). I may end up incorporating more code from Redox though (I'm already going to use their heap allocator but will enhance it with dynamic resizing of the heap). In addition they claim it to be a microkernel when it is actually a Plan 9-style hybrid, since the kernel includes a bunch of Unix system calls as primitives, disqualifying it from being a microkernel. This is unlike QNX where the process server that implements the core of the Unix API is built into the kernel but accessed entirely through IPC and not through its own system calls (the UX/RT process server will be similar in scope to that of QNX and will similarly lack any kind of multi-personality infrastructure and be built alongside the kernel, but will be a separate binary).