Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:12187 comp.os.386bsd.misc:3090 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!constellation!news.uoknor.edu!ns1.nodak.edu!netnews.nwnet.net!pnl-oracle!osi-east2.es.net!lll-winken.llnl.gov!ames!agate!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!ra.nrl.navy.mil!sundance!cmetz From: cmetz@sundance.itd.nrl.navy.mil (Craig Metz) Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc Subject: Re: Whats wrong with Linux networking ??? Date: 9 Aug 1994 17:15:54 GMT Organization: Information Technology Division, Naval Research Laboratory Lines: 54 Message-ID: <328dka$sbu@ra.nrl.navy.mil> References: <Cu107E.Mz3@curia.ucc.ie> <325760$rc9@ra.nrl.navy.mil> <Cu8CBr.Fx@calcite.rhyolite.com> <RSANDERS.94Aug9003813@hrothgar.mindspring.com> NNTP-Posting-Host: sundance.itd.nrl.navy.mil In article <RSANDERS.94Aug9003813@hrothgar.mindspring.com>, Robert Sanders <rsanders@mindspring.com> wrote: >Okay, take a deep breath, simmer down, and read before you post. Good advice for everyone. >> 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? > >He said "the client side especially." Linux's NFS server isn't the >bottleneck, the client is. That's what most needs work right now. Neither is particularly wonderful. I agree, though - the NFS server, by virtue of coming first and by running in user space, is much better done, both for stability and performance, than the client. The client was a semi-quick-hack done so that Linux would have NFS from the client side. Bugs were fixed and features improved, but it's still not anything to brag about except for simply to *have* a NFS client. I would much rather have a slow client than no client, and most of the Linux community would agree. It needs a lot of work to hold a candle to either the 4.4BSD or Sun clients. >As for a BSD NFS server, I'm not sure how easily it would fit into the >Linux kernel (if it is indeed a kernel-level server) . If you're >going to keep claiming NIH, at least restrain yourself to calling >Linux's inception a result of NIH. >Once you've accepted the fact that >Linux is *not* BSD, you have to admit that things that were written >for BSD don't necessarily fit well into Linux. There are good, >logical reasons (given that first step) why Linux isn't just a large >patch against BNR/2. Linux's inception was a result of a few things that people won't go and brag about, but I don't think NIH was a significant factor. It's different. I don't think it to be significantly better or worse in the end, and I use both (I'm typing this on a BSDI box right now). >That cuts both ways, by the way. Much of the driver support for the >two free BSDs has duplicated work already available in Linux. Why >haven't they just ported the Linux drivers? Or dosemu? Or the Linux >/proc filesystem? Or the Linux SYSV IPC implementation? Or the Linux >virtual console system? There has been a surprising amount of porting back and forth between *BSD and Linux. Things like the FPUEMU and the sound driver, for instance. But I agree - it's extremely naive to think that you can just drop in any code from one into the other and expect it to work. In many cases, it's easier to just do it from scratch.