Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:2918 comp.os.linux.misc:20611 Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!olivea!decwrl!decwrl!netcomsv!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: Re: source of TCP/IP (was I hope this wont ignite a major flame ...) Message-ID: <CtqrFJ.IM5@calcite.rhyolite.com> Organization: Rhyolite Software Date: Sat, 30 Jul 1994 06:59:43 GMT References: <3163r7$440@quagga.ru.ac.za> <CtMp4G.7Ap@calcite.rhyolite.com> <31bl91$3b9@cesdis1.gsfc.nasa.gov> Lines: 86 In article <31bl91$3b9@cesdis1.gsfc.nasa.gov> becker@cesdis.gsfc.nasa.gov (Donald Becker) writes: > ... >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. The nice thing about standards is that there so many to choose from. I.e. only religious dogmatists care more about the imprimature on the standard than whether the computers interoperate. The new dogmatism about TCP/IP RFC's would be funny given TCP's history, if it were not such a sad sign of the death of TCP/IP. Yes, TCP/IP is dead. IPv4 will be the last generation. TCP will be fondly remembered as a legacy protocol on a few million systems in 5-10 years, with just as much life as the OSI protocols. Ah, well. It was great while it lived. >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. > ... I've been corresponding privately on this subject recently, and I've been convinced by arguments to the contrary that you guys were suffering the NIH syndrome. No one in their right minds was worried about the USL nonsense affecting the TCP code. A lot of the kernel was plausibly at issue, but not the network code. To have worried about Van Jacobson's code, you would have to have been literally out of your gords. For crying out loud--look at the source in the Postscript version of RFC-1144! The only people with reason to worry about the USL nonsense at all were people with money involved, such as BSDI. Doesn't Linux have Finish roots? Wouldn't you expect Linux to be as safe from USL as from the U.S. Dept. of Comm, DOD, and NSA? Not-Invented-Here is a strange syndrome. I know, having suffered it myself. The suffers are often unable to preceive or admit their affliction. They discover compelling reasons for rewriting interesting code, but only the interesting stuff. The boring stuff like `cat` is bought, borrowed, stolen, or, if absolutely necessary, hacked out over a weekend. Sometimes the reasons for rewriting are valid and almost sufficient. Sometimes, as in "USL is going to take back BSD TCP/IP", they're just plain silly. I've always been boggled by the number of people who have been compelled to re-invent TCP code. I've long asked people at router vendors, real-time-operating system houses, and so on why they didn't even consider at the BSD code. Before the USL suit, I heard "mbufs are too hard," "splnet is too hard and messy," "UNIX is too big and slow", and the ever popular "the BSD TCP is implemented wrong." All of those have grains of truth, but none of them were suffient or the real reason. Maybe I ought to start a 7-step group for NIH suffers. The first step is admitting you have a problem. Too bad I don't know the other steps. > ... >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? That's strange. The main bad things I've heard about the new Sun code is that it wasn't as fast as it should have been (note the past tense), and that they were both aggressive and not quite right about MTU path discovery. I think you're entirely wrong about ATM. ATM maybe ok for WAN links and may do well there, but it is technically wrong from start to end for LAN's and will never make it on the desktop. The ATM LAN buzz is already fading. The only question is what the trade rags, seminar salescritters, and other clue-free Technology mavens will be pushing next. Multi-media, FDDI, AI, pen-computing, PDA's and object-oriented are all played out. My bet is on <<Mobile Computing>>. Vernon Schryver vjs@rhyolite.com