Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:12209 comp.os.386bsd.misc:3103 Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!amd!netcomsv!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: Re: Whats wrong with Linux networking ??? Message-ID: <CuA6w1.5tF@calcite.rhyolite.com> Organization: Rhyolite Software Date: Tue, 9 Aug 1994 18:48:01 GMT References: <325760$rc9@ra.nrl.navy.mil> <Cu8CBr.Fx@calcite.rhyolite.com> <RSANDERS.94Aug9003813@hrothgar.mindspring.com> Lines: 106 In article <RSANDERS.94Aug9003813@hrothgar.mindspring.com> rsanders@mindspring.com (Robert Sanders) writes: >On Mon, 8 Aug 1994 18:50:15 GMT, vjs@calcite.rhyolite.com (Vernon Schryver) said: > >> 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!?! > >Okay, take a deep breath, simmer down, and read before you post. >Whatever your credentials, you have a "more-correct-than-thou" >attitude that rubs a lot of people the wrong way. Hmmmph. Think back to that that indefensible code fragment the other day. There is an awful lot of "respect me more than most because I have done some work in NetBSD/FreeBSD/Linux" around here. Anyone who thinks that doing a little night hacking makes one a Great UNIX Hack And Guru needs to get out more often. >> 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. I was too specific. The U.Guelph code is a complete server and client. >As for a BSD NFS server, Who said anything about a "BSD NFS server"? I wrote about the U.Guelph NFS code. It appears in 4.4BSD-Lite and elsewhere, but does that make it the enemy? > 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. Wrong. Changing the U.Guelph NFS code to use whatever Linux uses for networking cannot be a fraction as much work as writing a new NFS implementation unless the Linux networking is worse than anyone has so far claimed. There was an excuse for inception of Linux. Big-bad-nasty-mean-USL/AT&T is obviously a sufficent reason for most of the kernel. Who says otherwise? For the network code, it is a weak excuse and I'm convinced that NIH was the real reason, but the excuse exists and may have been the entire reason for people working on network code who didn't know the business facts of the situation. >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? That is right. Dosemu is an obvious case. The answer is Not-Invented-Here syndrome. Everyone has it. NIH can be a good thing, since rewrites from scratch are sometimes better than the originals. NIH is bad when the result is not strictly and unambiguously better than the original in features, licensing and bugs, or when the clone takes to long to complete, or when hypocracy or dishonest is involved (e.g. dishonest denials of NIH or theft of code). I think my PPP code is better than the public domain code I could not use because of its commercial restrictions, but I freely admit NIH was a factor. The doscmd in BSDI's BSD/386 does me more good than dosemu, so I think the authors of doscmd were barely justified. The U.Guelph NFS code is competative in all regards with Sun's reference source, and so meets that unambigiously better criterion for good NIH. A form of dishonesty is self-delusion. I cannot imagine anyone with enough knowledge to write a complete NFS implementation not knowing that the U.Guelph implementation has become the de facto public domain standard. That fitting BSD code into a Linux might be hard is a crazy excuse. It makes just much sense as refusing to have an open() system call. Of course a non-BSD kernel has different internal mechanisms, but one expects a good clone (i.e. something strictly and unabigiously better than the original) to have compatibility glue. Unless Linux's only reason for existence is to give people a chance to write kernel code (which would be an entirely reasonable and sufficient reason for it to exist until the clone is complete), limited compatibility with BSD and System V drivers and protocol code should go without saying. Yes, that means that every serious UNIX clone needs STREAMS support, at least DLPI, despite the fact that System V STREAMS are a bad NIH clone (eg. slow) of the BSD protocol switch and AT&T streams (non-shouting streams). Vernon Schryver vjs@rhyolite.com