There are some similarities between the Hurd and Plan 9 regarding the file system handling -- but there are also very fundamental differences which go far beyond monolithic vs. microkernel design:

• The Hurd is UNIX (POSIX) compatible

• While (almost) all services are attached to the file system tree, not all services actually export a file system interface!

  Personally, I advocate using FS-based interfaces as much as possible. Yet, there are some cases where they get very awkward and/or inefficient, and domain-specific interfaces simply make a lot more sense.

  Also, some Hurd services are indeed used to implement the file systems in the first place -- they work below the FS level, and obviously can't use an FS interface!

• File systems are completely decentralized -- clients always talk to the FS servers directly, without any central VFS layer. (I don't think that's the case in Plan 9?)

  This offers much more flexibility -- the way the FS interfaces themselves work can be modified. Many things can be implemented as normal translators, that would require special VFS support on other systems. (Extended attributes, VFS-based union mounts, local namespaces, firmlink, magic file name suffixes etc.)

• The system design allows users and applications to change almost all aspects of the system functionality in the local environment easily and without affecting other parts of the system.

  (This is possible with Plan 9 to some extent; but the Hurd allows it at a much lower level -- including stuff like the filesystem interfaces, access control mechanisms, program execution and process management, and so on.)

I hope I didn't forget any major differences...

For a while I have been thinking about the lack of a roadmap for the Hurd; but now I realized that we lack something even more fundamental: a simple mission statement -- i.e. saying where we want to go, rather than how we want to get there. I think many of the problems we have are directly or indirectly related to that.

As we didn't have such a mission statement so far, the people currently involved have vastly different ideas about the mission, which of course makes it a bit hard to come up with a suitable one now. However, I managed to come up with something that I believe is generic enough so all contributors can subscribe to it:

The mission of the Hurd project is: to create a general-purpose kernel suitable for the GNU operating system, which is viable for everyday use, and gives users and programs as much control over their computing environment as possible.

"Suitable for GNU" in the first part implies a number of things. I explicitely mentioned "general-purpose", because this an important feature that sets the Hurd apart from many other microkernel projects, but isn't immediately obvious.

I didn't mention that it must be entirely free software, as this should be obvious to anyone familiar with GNU.

Another thing I did not mention, because it's too controversial: how much UNIX do we need? I think that being suitable for GNU requires a pretty high degree of UNIX compatibility, and also that the default environment looks to the user more or less like UNIX. However, some people claimed in the past that GNU could do without UNIX -- the wording used here doesn't totally preclude such views.

The second part also leaves a lot of slack: I for my part still believe that a Mach-based Hurd can be viable for everyday use; but those who think that a microkernel change is required, should be happy with this wording as well.

The third part tries to express the major idea behind the Hurd design in the most compact and generic way possible.