Asahi Linux lead developer Hector Martin resigns from Linux kernel

> Which is a valid viewpoint. Let's not pretend that's not a technical argument.

So if Linus shouldn't overrule his deputies, and one deputy can completely block something in a subsystem that isn't theirs and has explicitly stated to do "everything in their power" to stop it, what exactly can the community "figure out" to get it to proceed? His decision not to get involved literally makes it impossible for the situation to change, so the confusion is why it's being phrased as if it's anything other than that.

If Linus were to come out and say "I changed my mind, I no longer think it's worth pursing trying to integrate Rust in the kernel due given the issues at hand" or even "regardless of my personal views, I don't have any desire to change the current system we have for how code gets merged into subsystems or who has the ability to block it, so I'm not going to overrule this", it would make a lot more sense to me, but by making it sound like there's anything left to figure out when someone with veto power has a stated intent to stop things from moving forward is just going to let the issue fester and produce more frustration on both sides. It almost seems inevitable that any future discussions will spiral out of control; there's no other way for it to conclude than either Linus overruling his deputy or the experiment just ending as a failure at this point, so he might as well just make that decision now rather than later.

If you're going to rewrite significant parts of the kernel, you might as well do what I've been doing and try to write what amounts to a better Linux than Linux that tries to maintain compatibility, but moves beyond the rather limiting conventional Unix architecture. The conventional Unix architecture was fine on a something like a 70s/80s-era PDP-11/VAX, but in the modern world its limitations have been apparent for quite some time.

What I've been working on is an OS very similar to QNX Neutrino in terms of general architecture, but with a somewhat different IPC protocol layering that reduces the number of user-visible primitives and allows for more consistent management of security. Most of the functionality of the system will be implemented in user-level server processes that export their services through special filesystems, with the only special/irregular parts of the system being the microkernel, the process manager (which also contains the core VFS and memory filesystems since these will be tightly linked to the process model), and the base syscall library (vaguely akin to the vDSO under Linux). Literally everything else will just be a regular process. It's not a "Rust OS" as such, as there will still be some C (for instance, the microkernel, which was forked from an older version of seL4), although it will have a fair bit of Rust code.

IMO the issues with Linux are mostly due to a combination of poor/ad-hoc extensibility and the development model that's way too decentralized in some places but excessively centralized in others. The architecture I'm going with will allow for more experimentation, since adding functionality to it will typically just be a matter of adding a regular user program (or a plugin for a regular user program), and much of the system will be based around standardized filesystem-based RPC protocols (generic tooling for implementing RPC interfaces will of course be provided). Therefore it would be easier to maintain experimental functionality in a separate repository and merge it into the base system later on.

Currently it's still quite preliminary, and it only runs some hardcoded tests built into the process server, although despite that, some developers from a major company have taken interest in it recently because of the possibility of using it as a replacement for QNX both in embedded systems and development workstations. I'm working on the VFS layer and built-in special filesystems at the moment, and hopefully should be able to get user processes running pretty soon.

https://gitlab.com/uxrt/uxrt-toplevel

Obviously the maintainer does not trust the Rust people, but they also did nothing to gain his trust, but the opposite.

Just saying "Trust me, or else I will shame you" is not a viable strategy.

The default position of any code maintainer who sees some people coming and saying that they would maintain from now on some parts of the code and that there should be no worries about that, is to not trust them immediately, but only after enough time passes during which they demonstrate that they are really competent and not just claiming to be so.

And, of course, drivers run in userspace and interact with the system through a clearly defined API.

Other systems like this include Robigalia, Lions OS and Genode.

They would likely quickly overtake Linux if they got 1% of the resources Linux receives.