Indeed, and one more way in which it fails this test is that it is
too restrictive. The typical example of forks is to put "side info"
like icons, manpages, and other such things alongside the object they
correspond to.
Well, guess what, there is no such one to one relationship. Some icons don't
correspond to any programs, others correspond to several. Same thing for
manpages.
So the links between manpages/icons/executables are much weaker than what
multiple-streams can forces upon the user.
Something like a package manager ends up providing very similar features,
but in a much more flexible way.
I can see the usefulness of "lightweight files" where the inode contains
a bare-minimum of info and delegates all the rest to its parent (access-time,
access rights, ...) if you want to allow very efficient tiny-file handling
(so as to allow the use of a directory of small files in place of a dbm file,
for instance).
But even that suffers from lack of support from the current infrastructure
(NFS access will probably suck).
Stefan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/