Messages in this thread | | | From | "Jeff Merkey" <> | Subject | Re: 20 years without semantic innovation is enough | Date | 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/
| |