FreeLists / openbeos / [openbeos] Re: Filesystems, Namespaces and Data

["Daniel Reinhold" <danielr@xxxxxxxxxxxxx>]

>
>Data, Data, Where fore art thou Data.
>       (Sounds like a bad 'ST:TNG' quote.)
>
>I have been planning to write an article for the list on my idea, so 
here
>goes.
>
>In the original concept the designers had for the BeFS, they foresaw a
>relational database. This would allow the user to manipulate all their 
data
>as entries in a database. This is a twist of the concepts from the 
already
>existing file systems.
>
>A file system is only a means of mapping an identifier (usually a 
absolute
>file name) to data (the files contents) and its attributes (such as
>permission, ownership, creation time etc).
[snip]

Mathew, you've got alot of interesting ideas on this subject. I've 
thought about many of these things as well over the last few years. For 
those who are interested, here are a couple of links to articles with 
similar themes:

The Death of File Systems
http://www.useit.com/papers/filedeath.html

A Dream of an Ultimate OS
http://okmij.org/ftp/DreamOS.html

Both these papers, like your posting, make many profound observations 
that bear thinking about. Unfortunately, I don't see how we could apply 
these ideas to OpenBeOS. If we did, it wouldn't be an OS that anyone 
(developers or users) would recognize as the BeOS.

You make the comment "A file system is only a means of mapping an 
identifier..." Yes, and this identifier is generally tied up with the 
semantics of the file system. For example, I probably have any number 
of files called "readme". But that simple name alone is not sufficient 
to identify the object. So I have to specify '/volume/subdir/foo/
readme' and '/volume/subdir/fee/fum/readme', etc.

Now I don't claim that hierarchical trees represent the best way to 
access information, but at the system level, you have to have some kind 
of organization, and the standard Unix-like file systems have been 
around a long time and are well understood. If we want to replace it 
with something else, then what? There must be ten thousand alternative 
ways to represent information -- which is the best, which is the one 
everyone could agree to?

That's the problem I see with your suggestion, Mathew. If we took it 
seriously and actually tried to implement it, the project would 
probably be set back by at least two or three years. The notion of how 
data is stored using the file system is so engrained all thruout the OS 
from the lowest levels of the kernel all the way up to applications, 
that you couldn't pull it out without disrupting practically 
everything. Even if you could do it, it wouldn't be the BeOS, it would 
be something else (maybe better, maybe not).

You and I and probably most of the people on this list could probably 
find 1000 things that we don't like about the current BeOS architecture 
including the file system. But as long as we agree to implement it, we 
all know where we stand and the goals are clear. Take that away, and 
you have months, even years of discussion, debate, and bickering as 
everyone tries to hash out their own ideas of the new world order.

I just can't see what your proposing as being anything that could be 
implemented in even R2, R3, R4, etc. let alone R1. What you're 
proposing is a leading edge, revolutionary OS model. It's probably a 
good academic project and someday many, if not all, of those ideas will 
probably make it into real world operating systems. But I don't want to 
spend years in the OS laboratory trying to find out what new semantics 
work. I see the OpenBeOS project as a very practical, pragmatic 
undertaking.  The BeOS's design principles, if not leading edge, are at 
least solid, practical, well understood and well defined. That's the 
main reason that I think OpenBeOS actually has a chance of succeeding.