We over at Sequoia-PGP, which gets a honorable mention by the OP, are not merely trying to create a new OpenPGP implementation, but to rethink the whole ecosystem.
The homepage has some meaningless marketing bullet points about the greatness of pgp itself. Where would I find the ways in which you rethink the whole ecosystem? It seems like Sequoia is just a library, not even a client. Wondering how this could change pgp by much if at all.
I know you're just trying to be funny, but I don't think it's funny at all.
The Linux kernel undoubtedly many features that the Hurd system lacks, but that is due to the severe lack of manpower of the latter system and the billions of Dollars being poured into the former.
On the other hand the Hurd has features that the Linux kernel can never hope to achieve because of its architecture.
> The Linux kernel undoubtedly many features that the Hurd system lacks, but that is due to the severe lack of manpower of the latter system and the billions of Dollars being poured into the former.
That's why GNU Hurd is essentially a dead project. Sadly it never attracted the attention and manpower necessary for it to survive.
> On the other hand the Hurd has features that the Linux kernel can never hope to achieve because of its architecture.
Fault isolation. We're doing it for daemons, we're doing it for web browsers, it is insane we're not doing it for operating system services. I bought a graphic tablet and the first time I plugged it into my laptop the Linux kernel crashed. And this was merely a faulty driver, not even malicious hardware.
Also think of the effort it took to introduce namespaces to all the Linux subsystems. After a decade the user namespace still has problems. This is ridiculously easy on a distributed system, yet very hard on a monolithic one.
I also have high hopes for Guix, and in fact there is a gsoc project to port Guix to the Hurd. Guix tries to empower the user, a goal shared by the Hurd. They are a perfect match.
I do not believe that it is easy to provide the Mach IPC interface in the Linux kernel. The IPC mechanism is tightly integrated into the thread switching and scheduling systems.
Furthermore, I do not see much benefits in doing that, the main point would be drivers, which we want to run as a userspace process anyway. And we are doing that using the DDE framework. Rump is interesting, and it wouldn't even be that hard. It just lacks someone actually doing it.
What people don't realize is how compatible the Hurd is. We are shipping the glibc. Debian/Hurd contains ~80% of the software that is found in Debian/Linux. We have Firefox. The other day I deployed two Django sites on my Hurd development server to work out some issues I had with the Apache configuration I had on the production system. I was curious how it would go. All the Python stuff worked out of the box, I merely had to select a different Apache mpm module, because the default didn't work. Need to rescue a box? Append "init=/bin/bash" to the kernel command line to circumvent sysvinit.
Other microkernel based systems might have more ambitious goals, but many of them sacrifice compatibility to reach them. Some aspects in POSIX are hard to implement in a distributed fashion, for example fork(2). But what good is a fancy system if it requires a huge effort to port applications to it?
Right, the hypothetical tiny Linux kernel would probably be built without driver support and have NetBSD's rump kernel drivers in place of both Hurd's DDE and the monolithic Linux drivers, which keeps the userspace advantage.
It's true that a Mach port is quite tricky (particularly the virtual memory semantics).
Apparently there was an old abandoned attempt to port Mach on top of POSIX, which if someone obtains the source, might be a useful reference to see what went wrong or is incomplete [1].
It's worth noting that the reverse (Linux on top of Mach) was already done by Apple nearly a couple of decades ago as MkLinux, but they ultimately settled on XNU.
Hurd developer here. You are spot-on. The Hurd solves a problem today that Linux (and all the other monolithic systems) will never solve: Fault containment.
Native support for smart cards and TPMs is planned and being worked on.