Here's an interesting email reply I got from the man behind http://objectroot.org/ , Timo Lehtinen, which I think enriches the discussion.

Quote:> There are a lot of things I've just brushed upon and didn't dig
> into. For instance, I haven't discussed anything regarding why
> we're restricting ourselves to the default hierarchy and why it's
> structured the way it is. That's the topic of categorization,
> which you've revisited with your project.
>
> What's your take on that?

The Unix model has been successful because of its component
architecture: if you have a better idea of how to implement, say, a
file compressor or some other type of data processing filter, just
write your own. And then others can plug it into their processing
pipelines without even thinking. This evolution has been going on for
40+ years now.

But, unfortunately, at the file system organisation level, similar
evolution has not been possible: programmers, sysadmins, and
installation scripts expect to find things in their traditional,
familiar places. I.e. you can't change things just for your needs,
as it will affect other peoples wares as well.

> Someone on the extended thread, where we discuss the subject, has
> compared the way you mount filesystems in your hierarchy to the
> one of plan9.

What Plan 9 did was open our minds to the possibility that we can
innovate in the file system hierarchy. Coming from the creators of
Unix itself, it shook our minds loose, and let us view the file system
more as a database.

What my proposal does is move away from type-orientedness (organizing
files by their type) to containment by authority. This is to solve
namespace collisions (or at least delegate them futher), and allow
more natural sandboxing, among other things.

My thinking has been affected by Plan 9, for sure, but more in overall
'empowerment' than in specific ideas.