> This IPC often has a performance impact, which is a big part of why microkernels have remained relatively unpopular.

Somewhat comforting to see deeply technical people still misconstruing why approaches/projects don't get adopted.

This is an awesome effort, thank you, knowing that one of the authors is in the thread. How far is this from usability, at least in some reduced context? Would love to be able to build server images based on this kernel and play around with it.

Is it novel development: splitting kernel into small unsafe core and large safe modules? It sounds very interesting and promising. No hardware overhead of microkernel and no safety issues of monolith. Such a project, obviously, depends on a systems language with explicit unsafe/safe separation.

Seems like a great idea. We have so much software invested that alternative substrates could yield great benefits or at least alternatives when needed for less technical reasons. Kinda reminds me of kFreeBSD and of course GNU/Hurd.

This is an interesting approach, and I wish it will succeed.

I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said:

No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save.

I think he was already well aware at that time that keeping the driver interface unstable is his moat. A quarter of a century later kernels that run on virtualized hardware are a dime a dozen but practically useable operating systems in the traditional sense of abstracting away real hardware can still be counted on one hand.

I hope this project succeeds. Rust kernel-level development deserves far better than the current state of affairs.

What should be the name for these kind of things? *nux?

It is licensed under MPL. Well, there is best licenses such as GPLv3.