I think hurd can bring a lot of development, that’s very good on microservices, to the application layer, like an effect system for managing effects producing patterns (like in scala), so interacting with the RPC would be explicitly an effect producing interaction and all of the mathematical work proving certain ways of doing it would make the interaction faster (user-space fibers/green threads, cancellation, error treatment, etc) and more reliable.

If every call to the micro kernel (to its RPC) IS a effect producing pattern (accessing anything in hurd is a RPC call), how can we optimize for performance? Yielding instead of blocking, reactive patterns, etc, hell, maybe even put lisp in there to build this hahaha.

Containers and dbus/portals would be a breeze, instead of a container, just make a subhurd, instead of using dbus, use the RPC abstraction for dbus with all the security features, portals? Just check the permissions with the RPC administrative API.

There are a lot of interesting things at the website, if the website works. I’m going to upload the user manual to archive.org, maybe its useful in there.

I really believe that the Hurd is the future of computing, since the 80s hahaha. It can give an edge to the Free Software world.

I think the advantage of the Hurd over Linux is that it is a microkernel. It also is built entirely on freedom 0, the ability to run a program as you may wish. Want to add a new filesystem process? Write a translator, and install it without rebooting. I also believe that GNU software should integrate well with it.