Not quite. The end goal of the GNU project on the macro level is to replace all proprietary operating systems (not just proprietary Unixes) with GNU. But then an explicit goal of the Hurd specifically was freedom from tyrannical sysadmin policy, which necessarily included freedom to host one's own private namespace in a multi-user system that doesn't affect the global namespace.

Currently, the goal is indeed exploration. RMS and GNU have given up on it and morale is low. Can you blame them?

In fact, RMS' decision to go with Unix was a pragmatic one. He himself was always more a fan of ITS and Lisp Machines (see his October 1986 speech at KTH), but rightfully sensed no one would end up using such a solution, and thus decided a clone of Unix with non-breaking semantic improvements where possible and a Lisp-y userspace was the best way to bridge adoption with wanting to push forward. Hurd satisfied the first, the second unfortunately stagnated as Guile never broke the chasm until very recently now with GuixSD.

QNX was proprietary and didn't have its architectural unveiling until work on Hurd was started. It again did not have the translator concept, but like MINIX 3 had static servers. KeyKOS' main selling point was the single store and the orthogonal persistence, which nominally could be done on Hurd e.g. by integrating Mach VMM policy into a libdiskfs. It was not a priority then. L4 was too spartan for the experiments on object-capability systems that the Hurd devs embarked: https://www.cs.cmu.edu/~412-s05/projects/HurdL4/hurd-on-l4.p...

It's true that security was never a primary orientation of the Hurd, but its security is still better than monolithic Unixes. And do keep in mind QNX and MINIX 3 are not nominally security-oriented, either. It's the communication boundary structure (and in Hurd's case, port rights and auth server) that intrinsically create superior cases.

Walfield and Brinkmann's 2007 critique was done from the perspective of developers themselves. It wasn't a general criticism of the Hurd, but one of specific problems related to resource accounting that other u-kernel and most monolithic kernel designs suffer from. Relative to the state of the industry, it is still a leap forward. Relative to the state of the art, it is not, but then so do QNX and MINIX 3 make sacrifices.

Implementing the POSIX API has nothing to do with the Hurd's problems. And, indeed, Hurd does break the POSIX model in several aspects (e.g. allowing multiple uids per process). But then we must disqualify QNX and MINIX 3 by this token, too.

The fundamental issues with the Hurd then have little to do with the 2007 critique. More pressing is its incompleteness, which hopefully rump integration will finally break its samsara. If all else fails, using rump drivers on a heavily stripped Linux with Mach module emulation to create a true hybrid kernel, coupled with functional package management and system state management via Guix with added on orthogonal persistence and network transparency could be another future direction for the Hurd I might end up exploring. Perhaps tripling both as a multi-user OS, a unikernel and a container OS via subhurds.

The Mach improvements have mostly been surface, but again, I would not see it as a huge bottleneck (only an inelegance) and in the hybrid case it becomes irrelevant beyond as a programming API, which it isn't that bad of one.