What are your main motivations to use GNU Hurd? Not wanting to troll, fishing for a link for good background reading
Also, in a world of unikernels and app containers (trending toward the most static and restricted deployment unit possible), having an os being able to change its parts while running seems a bit useless.
But, who knows ? maybe we'll see new patterns emerge. That's a fantastic time for people interested in OSes.
Yeah, good luck with that. OO is great but I'm not sure major redesigns are any easier in OO compared to any other arch.
Having a completely different OS arch in play does sound good though, perhaps opening up possibilities we havent realised yet. Perhaps someone should re-write that 'advantages' page to encompass the massive changes in Software thinking since it was first written in 2001.
It depends on what they mean by OO. I can't find a source at the moment, but I've heard of Smalltalk applications that have been running the "same" incrementally modified image[1] since the 1970s or 1980s.
http://en.wikipedia.org/wiki/Smalltalk#Image-based_persisten...
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
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.