Hurd is a bunch of servers on top of Mach (there were attempts to get it ported to L4, Coyotos and some other kernels, but they all sadly fizzled out), so it is

Hurd is a bunch of servers on top of Mach (there were attempts to get it ported to L4, Coyotos and some other kernels, but they all sadly fizzled out), so it is dated in many extents. The main deal is the concept of translators, which are similar to 9P file servers and namespaces, and how all the Hurd servers are implemented. This design also enables easy persistence. There is no trend between "object-oriented" and "interface-oriented" design, they're both terms with lots of meanings. The actor model is a form of object model. It's not necessarily bad. The Hurd actually has its own system for running multiple concurrent instances of itself, subhurds: https://www.gnu.org/software/hurd/hurd/subhurd.html https://www.gnu.org/software/hurd/hurd/subhurd.html Application containers still depend on a host OS. In fact, they're basically a way to partition the OS resources and library namespace so that you can get around its deficiencies by limiting each logical software bundle to a sub-OS. Each individual container is not any more malleable than what the host OS provides. It's quite the hack, really. Unikernels/libOS are great, but they're just another technique that harkens back to the old days of writing code to initialize the machine, except it's now reusable through virtualization and library linking. Full OS deployments can still be useful.