On Sun, Mar 06, 2005 at 05:58:22PM +0100, Raoul van Putten wrote:
> Just my personal opinions... I like the *nix file system, because it's
> universal. Dirs are files (at least thats what they taught us... On some
> systems you can do a "cat dir" instead of a "list dir" and it shows the
> same) and it's not a tree but a graph: using hard links, one can cd from
> any path to any location in the file system, even in circles.
"cat somedirectory" is an error in POSIX. Furthermore, being able to
list them with cat isn't really all that useful.
And yes, you could make your filesystem not a tree but a graph if you
are root and you hardlink the right directories. Of course, you might
want to consider that this would break almost every tool that traverses
the filesystem.
> If I had to implement a file system today, I would attach something xml'ish
> to every file for an infinite number of extra attributes and make those
> searchable, so that every application can chose what a file can be searched
> for. Common attributes like name, owner, author, etc. are there to simplify
> things, but any are possible.
No. There is no reason to add yet another namespace to an already
redundant namespace. The only reason you would want to use XML in this
case is because your filesystem sucks and doesn't efficiently handle
small nodes. Read about reiserfs for more on this.
> Another things I would want to have in a file system is versioning of
> files. Programmers know cvs & co., lets have it intrinsic to the system.
> However, applications should be able to alter the methods, because we don't
> want to version the 9 GB dvds we ripped and shrunk them to 4.7GB for saving
> space.
Versioning is good. Filesystems are bad. Whatever filesystem Unununium
has will be there for compatibility only, and as such will be exactly
like POSIX.
Just because something like versioning is a good idea does not mean it
should be "intrinsic", as you put it. Wadding functionality together is
usually a hack around poor interconnection. Look at some IDEs, for
example. They have everything crammed into the same chunk: a text
editor, a compiler, a debugger, a help system, and so on. This is useful
if you have no better way to interconnect these things, but it really
blows when you don't like one of the components. I'm not sure the "I" is
for "integrated" because they don't integrate with anything.
"Inflexible" might be more appropriate. Editors like emacs and vim try
to interconnect with other applications, but the mechanisms for them to
do so suck, so sometimes the result is less than optimal.
|
