Re: [tlug] Peeling onions.

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "ijw" == ijw  <ijw@example.com> writes:

    ijw> Martin writes:

    >> what i meant to say was either: shouldn't the unix world
    >> already be aware of the problem and wanting to solve it?

They obviously are.  What do you think the `unix-haters' mailing list
was all about?  Ian's point was that experimenting with different
specifications is much easier if you can keep the rest of the OS
running while your experimental subsystems collapse.  Isn't that why
Windows NT is such a huge improvement over Windows 9x, and why
Unix-of-choice is such a huge improvement over Windows-as-imposed-by-
buzzword-brainwashed-management?

I have direct experience with the particular case of `userspace
extensions'.  There are at least three XEmacs developers who came to
XEmacs specifically because we support a system for loading .sos (not
yet a foreign function interface, but usually the interfaces are
stable enough so that's not a major drag), while Stallman forbids any
such feature for GNU Emacs on politico-religious grounds.

If it's that important to people who are developing XEmacs subsystems,
I'm sure it's that important to people who are developing kernel
subsystems.

    ijw> If yopu want Unix programs to work you have to stick with
    ijw> Unix FS semantics as a basis.  I suspect that extending Unix
    ijw> semantics is not the best way of soilving the problem, and a

Unix semantics _are_ the problem.  They conflict with other
requirements (such as the persistent caches used by systems like Coda
and Intermezzo).  AFS and NFS provide much closer approximations to
Unix semantics, at the cost of basically being unable to provide
persistent caches.

And then there are "filesystem" semantics like those of
CVS/Subversion, ie, maintaining history.  Implementing those in terms
of Unix filesystems means that CVS and Subversion developers have had
no spare energy to support source code management (a la Bitkeeper,
darcs, or arch).

darcs is really fascinating, because it's built from the ground up on
the notion that the atomic object is not the file, but the patch.
Files, in fact filesystems as well, are a derivative concept,
constructed by applying patches to the empty filesystem.  Think wiki.
Think branched projects.  Only problem is that darcs is written in
Haskell, so the immediately available hacker audience is small.

    ijw> better way is to rethink your interface entirely and then
    ijw> implement a compatibility layer on top, if necessary.

It's not obvious to the Coda developers, at least, that this can be
done.  I'll ask what they think of trying to implement Coda on Plan 9.  ;-)

    ijw> Rewriting the VFS in Linux is one approach, but I'd approach
    ijw> it by writing a simple test environment in which to
    ijw> tinker. (***)

I think this is the only way it _can_ be done (tinkering, that is)
because Virtual Filesystem Specification TNG is not at all a
consensus.  Userspace experiments are simply a very efficient way of
supporting tinkering.



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba