Vadim Antonov's Grail

David Jeske
Mon, 4 Jan 1999 10:48:09 -0800

On Mon, Jan 04, 1999 at 09:56:37AM +0000, Fco. J. Ballesteros wrote:
> Laurent Martelli writes:
>  > files are the biggest flaw in unix systems, because when you have a
>  > file, you don't known how to interpret it, since there's no meta-data
> The one who created the file (human|app) knows. And most of the time,
> the file (i.e. #!...) knows too.

But the system dosn't know who created the file. For example, on
Linux, rpm is capable of telling you what package reciept owns a file,
but if you go into /etc, almost all the files are owned by
"setup-1.9-2" or something like that. 

Another problem is that when a program has to deal with a linux
configuration file, you have no idea what version of the file it's
expecting. For example, imagine you write a program which has to deal
directly with fstab, and the fileformat for fstab at the time is:

<device>     <mount point>    <fs type>     <options>

Then, sometime later they change the fstab format to be. (i.e. they
_did this_ in Linux):

<device>   <mounot point>  <fs type> <options> <dump frequency> <check passno>

If you run that old software and it opens "/etc/fstab", you have no
idea which version it's expecting. So even if you had some fancy way
to redirect and give it an 'emulated' version (which you don't on
standard UNIX), you couldn't, because you don't know what version it
was expecting.

What you want, is to have symbol style dependencies for all external
references. When you reference a libc function, the executable has an
import dependency which says something like "libc-5.2.1"->"write()". If
we removed the entire concept of using the filesystem to locate
information, then we could do this kind of version dependency of any

If you accessed fstab, you would reference the symbol "unix_etc-1.2.2"
-> "fstab". If we changed the format of fstab in the new version of
"unix_etc", then we could provide code to allow legacy programs to see
it in the 'legacy way' without any of the new features.

David Jeske (N9LCA) + +