Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:2897 comp.os.linux.misc:20547 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!ames!newsfeed.gsfc.nasa.gov!cesdis1.gsfc.nasa.gov!not-for-mail From: becker@cesdis.gsfc.nasa.gov (Donald Becker) Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc Subject: Re: source of TCP/IP (was I hope this wont ignite a major flame ...) Date: 29 Jul 1994 15:28:33 -0400 Organization: USRA Center of Excellence in Space Data and Information Sciences Lines: 54 Message-ID: <31bl91$3b9@cesdis1.gsfc.nasa.gov> References: <DHOLLAND.94Jul25171448@scws33.harvard.edu> <CtKBJ5.77B@rex.uokhsc.edu> <3163r7$440@quagga.ru.ac.za> <CtMp4G.7Ap@calcite.rhyolite.com> NNTP-Posting-Host: cesdis1.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In article <CtMp4G.7Ap@calcite.rhyolite.com>, Vernon Schryver <vjs@calcite.rhyolite.com> wrote: >The single consistent, non-trival, bad thing I've heard about Linux is >that it's network code is, to put it politely, not as good as it will >be someday. Given the fact that BSD network code has always been >absolutely free for the taking (requiring only those pesky copyright >notices that AT&T/USL removed from the SVR3 and SVR4 network code), I've >never understood why Linux does not use the best available network code, >BSD's. The BSD code is good, but the primary reason it's considered the best available is the BSD implementation, rather than the RFCs, is considered the definition of correct behavior. Regarding the comments (not just yours, Vernon) about the Linux network code: yes, there *was* a good reason for writing the networking code from scratch. Doesn't anyone remember the USL lawsuit? At the time everyone was shaking in their sandals, afraid that USL would lay claim to every piece of code that Microsoft didn't already own. I remember arguing that we shouldn't let the VJ slip header compression code, the one piece of BSD code in the networking section, into the kernel distribution. SLIP header compression was independent of Net-[12], but there was still the possibility that it would be considered to be derived from some Bell Labs seed. The common attitude today is that the USL suit was resolved, and nothing bad happened because of it. I strongly disagree: the lawsuit had a tremendous chilling effect, and by doing so it fully accomplished the USL goals. This is a market where one year is two product generations. BSD-derived (by that I mean non-USL) systems were delayed at least that long (vis. BSDI). As Linux developers we were faced with the choice of using Net-2, and running the risk the UC Regents would fold or that USL would win the suit. If that had happened, the best we might hope for is to be left without networking. The worst would be that the U.S. developers would be personally liable for distributing code that we 'knew, or should have known' had questionable ownership and copyright. Look at the U.S. people who were working on the Linux networking code -- What would you have done? A final note on the subject of protocol incompatibilites: when some vendors product doesn't work with Linux, people immediately blame the Linux protocol stack and scream at us. We (actually it's usually Alan Cox) usually put in changes to our already RFC-compliant code to mimic the BSD behavior and avoid the problem. AFAIK, no major vendor has fixed their protocol stack to follow the RFCs when such a problem has been revealed. Now the point: what about ATM? People are afraid of changing their protocols stacks, and the one other example of a non-BSD stack (Solaris 2) has also gotten a similarly bad reputation. Unless there is a dramatic revolution (IPNG? OSI:->?) who will be willing to risk fielding ATM on the desktop in this environment? -- Donald Becker becker@cesdis1.gsfc.nasa.gov USRA Center of Excellence in Space Data and Information Sciences. Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771 301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html