>> "Should"?  Why?  What's wrong with having many namespaces?
> Many namespaces mean many different ways of managing, accessing,
> controlling, etc. the objects being accessed.

Yes - one way per namespace.  I'm not convinced this is necessarily a
bad thing.

> This means added complexity with the potential for confusion and
> unsafe assumptions being made by users; and sometimes additional
> bloat too.

Sometimes, especially when there exist objects that appear in multiple
namespaces.

But them excepted, I don't see why each object type shouldn't have a
namespace suited to its nature.  The file paradigm is remarkably
robust, but that's largely because of the unstructured ioctl() escape
hatch, secondarily because people accept pseudo-filesystems that
severely break many ordinary filesystem operations.  The filesystem
simply is not a good fit to many abstractions.  Look at all the things
you can't do with procfs, for example: both things you can do with
processes but not procfs "files", and things you can do with normal
files that you can't do with procfs "files".  (Simple examples: there's
no procfs analog to fork() - the closest would be cp, and that's not a
good fit - nor is there a process analog to mkdir().)

> The developers of Research UNIX and Plan 9 have made solid arguments
> that I won't further repeat here in favour of using the filesystem
> namespace consistently for all system objects.

It's an interesting paradigm, but as I indicated above, is has the
problem that it ends up twisting everything into the filesystem mold.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B