Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:12208 comp.os.386bsd.misc:3102 Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!europa.eng.gtefsd.com!news.msfc.nasa.gov!news.larc.nasa.gov!saimiri.primate.wisc.edu!news.doit.wisc.edu!decwrl!netcomsv!netcomsv!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: Re: Whats wrong with Linux networking ??? Message-ID: <Cu8CBr.Fx@calcite.rhyolite.com> Organization: Rhyolite Software Date: Mon, 8 Aug 1994 18:50:15 GMT References: <Cu107E.Mz3@curia.ucc.ie> <31vo1b$87t@quagga.ru.ac.za> <325760$rc9@ra.nrl.navy.mil> Lines: 25 In article <325760$rc9@ra.nrl.navy.mil> cmetz@sundance.itd.nrl.navy.mil (Craig Metz) writes: > ... > The Linux NFS implementation, the client side especially, is very >bare-bones. Because of this, it couldn't hold a candle to the 4.4BSD NFS >implementation. I expect, however, that someone will implement improvements >from 4.4BSD. For heavens sake, WHY!?! Rick M's Univ. of Guelph NFS implementation works fine, and is freely redistributable, actively maintained, supports TCP as well as UDP, is used in 4.4BSD, BSDI's BSD/386, and many other products, and works with the freely available AMD. Except as a training excercise or the result of a particularly bad case of Not-Invented-Here syndrome, why would anyone want to write another NFS server? If one were going to write an NFS-like-but-different protocol, say something with better cache coherence and lock mechanisms, then it would might sense to start from scratch. But something identical to the current, old NFS protocol? Why? Vernon Schryver vjs@rhyolite.com