Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:12444 comp.os.386bsd.misc:3248 Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.Hawaii.Edu!ames!pacbell.com!att-out!rutgers!koriel!olivea!charnel.ecst.csuchico.edu!yeshua.marcam.com!MathWorks.Com!news.duke.edu!convex!convex!constellation!rex!ben From: ben@rex.uokhsc.edu (Benjamin Z. Goldsteen) Subject: Re: Whats wrong with Linux networking ??? Message-ID: <CuACx4.Etu@rex.uokhsc.edu> Date: Tue, 9 Aug 1994 20:58:15 GMT Reply-To: benjamin-goldsteen@uokhsc.edu References: <Cu107E.Mz3@curia.ucc.ie> <31vo1b$87t@quagga.ru.ac.za> <325760$rc9@ra.nrl.navy.mil> <Cu8CBr.Fx@calcite.rhyolite.com> <328d6v$s0p@ra.nrl.navy.mil> Organization: Health Sciences Center, University of Oklahoma Lines: 84 cmetz@sundance.itd.nrl.navy.mil (Craig Metz) writes: >In article <Cu8CBr.Fx@calcite.rhyolite.com>, >Vernon Schryver <vjs@calcite.rhyolite.com> wrote: >>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. >>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? > Vernon, for all your ranting and raving about the evils of Not- >Invented-Here, you sure take an open mind to things that aren't BSD. > UofG Linux > Freely redistributable Yes Yes > Actively maintained Yes Mostly > TCP as well as UDP Yes Yes > Supports AMD Yes Yes > Used in 4.4BSD Yes No > So, the 4.4BSD NFS has two things per your mentioning over Linux's >NFS. First off, it's better maintained. The Linux code has been handed off >a few times now and tends to get handed to extremely competent and extremely >busy people, who generally can do no more than fix major bugs. Second, the >UofG code is used in 4.4BSD. Apparently, this is absolutely essential to >meet your approval. 4.4BSD and its NFS predate Linux (at least in alpha versions) >>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, why don't we all use Version 7 UNIX? Why is there a BSD >in the first place? > Even for the exercise itself, it is essential to do things over >in order to see if it can be done better. Sometimes all that is gained in >such a thing is insight into the problem. Sometimes room for improvement >is found and the status quo is raised. The only thing that is certain is >that not doing anything will certainly get you nowhere. > Don't get me wrong, folks. I'm not going around saying that the >Linux network code is the best on the planet or that the Linux NFS code >is better than the UofG NFS code. What I'm saying is that, unlike what >Vernon seems to be advocating, it should not be written off as an arrogant >waste of time because it's (gasp) NOT BSD. It's different. It's new. It's >decidedly not better. That doesn't mean it can't be improved. That doesn't >mean it can't someday become something better than the BSD code (sacrilege!). NIH means reimplmenting something in a way that isn't that much better than what it replaces (or in this case, not quite as good) for no good reason. > You'll never find out if there's a better way unless somebody has >the guts to go and try doing it differently. No problem: just state what didn't work about the old version and how the new version fixes the problem. Why didn't Linux just take the UofG NFS code and run with it? I can see in the BSD terminal handling interface (sgtty) the statement: something is less than optimal with termio interface. The problem was: - the new interface wasn't a revolution, - the critical features could have been added to the old interface - sgtty was never adopted by "real" UNIX - POSIX choose something similar to termio. The Linux group should have just imported the UofG NFS code and look for something else to do; a superior replacement to NFS would be nice (with a license such that any UNIX vendor could implement it without having to make their entire kernel public). -- Benjamin Z. Goldsteen