Re: 20 years without semantic innovation is enough

Jeff Merkey (jmerkey@timpanogas.com)
Wed, 30 Jun 1999 15:31:33 -0600

I heard these same arguments at Novell about OS development and how everyone
had a new idea on doing it better -- in the end, we discovered that we were
just re-inventing Unix and MVS. The real question is do things ever really
change. The answer lies in how HUMANS interact with computers. When this
changes, it will drive the needs for new and different semantics. Try as
you may, you will find when you reach the end of your journey of
exploration, you walked in a circle and are back at the beginning.

Regards,

Jeff

----- Original Message -----
From: Hans Reiser <reiser@ceic.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: Hans Reiser <reiser@ceic.com>; David S. Miller <davem@redhat.com>;
<pongheng@starnet.gov.sg>; <linux-kernel@vger.rutgers.edu>;
<reiserfs@devlinux.com>
Sent: Wednesday, June 30, 1999 3:40 PM
Subject: Re: 20 years without semantic innovation is enough

>
>
> Alexander Viro writes:
> >
> >
> > On Wed, 30 Jun 1999, Hans Reiser wrote:
> >
> > > My point though is that the file system semantics have been static
for
> > > 20 years. It is time for them to change. When they change NFS will
> > Could we avoid metaphysics?
> > > break, at least it will if the changes are substantive. For this
> > > reason, to argue that NFS cannot be broken is to argue that there
should
> > > be no semantic innovation for file systems. That make the argument
> > > invalid in my eyes.
> >
> > > NFS must be broken.
> >
> > Not in the kernel that runs here. Period. You break it, your patch is
not
> > applied on my boxen. If anything like that will make its way into the
main
> > tree (e.g. you'll tie Linus and give him one-way trip) be bloody sure
that
> > code split *will* follow. If reiserfs will require kernel changes that
> > break NFS (I hope it will not) - though luck for reiserfs. Deal with
it.
> > NFS sucks in many, many ways. So does SMTP. So does DNS. So does IP.
> > Unfortunately dropping any of them is not an option, unless you are
> > willing to move into the brave new world where you can't interoperate
with
> > anything except the stuff written by vendor foo. We've been there. SNA
> > lost. And one personal note - you've made everything to ensure that
I'll
> > treat any code from you as potentially maliciuos. Double audit and all
> > such. Somehow I suspect that I'm not alone in that. After the things
that
> > were said I simply don't trust you.
>
>
>
> Oh dear, we've gotten into flames, and I am rather to blame in this.
>
> Don't open NFS directories as files, use Stephen's proposed solution.
>
> Stephen wrote:
>
> > Now, what we _could_ do is to provide a user-space library stub for
> > other NFS clients which translates O_DIRECTORY() opens to a file into an
> > open of something like "filename/.%%pseudodir%%", and have an NFS server
> > which detects that pseudoname and munges it into an O_DIRECTORY open on
> > the server side.
> >
> > See? Suddenly we are able to pass these calls over NFS while still
> > doing something useful with local filesystem semantics. That's the sort
> > of thing I would like to see us talking about. Simply dismissing all of
> > existing practice as irrelevant and broken just doesn't get us any
> > further, I'm afraid.
>
> I like it. Now the only thing I would like more is to stop exchanging
> flames and write some code. Of course, if I could resist getting in the
> last word, I might be able to do that....:-)
>
> Hans
>
> -
> 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/
>

-
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/