Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:2938 comp.os.linux.misc:20657
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: 31 Jul 1994 01:31:51 -0400
Organization: USRA Center of Excellence in Space Data and Information Sciences
Lines: 124
Message-ID: <31fd07$6pq@cesdis1.gsfc.nasa.gov>
References: <3163r7$440@quagga.ru.ac.za> <CtMp4G.7Ap@calcite.rhyolite.com> <31bl91$3b9@cesdis1.gsfc.nasa.gov> <CtqrFJ.IM5@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 <CtqrFJ.IM5@calcite.rhyolite.com>,
Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
>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
Oh, just go ahead and twist my words. I didn't say that having the BSD
implementation be the standard was a bad thing. (In fact I feel that having
a reference implementation should be mandatory *before* people start working
on a standard c.f. OSI and ATM.) I was pointing out that the RFC did *not*
define TCP/IP, the BSD implementation did. By definition, the BSD code was
never incorrect.
>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.
I believe just about everything we now do with computers will be obsolete or
a legacy system in 5-10 years... except TCP/IP. The internals of a system,
both software and hardware, might be expensive and difficult to develop, but
the interfaces between systems are the high-value items that won't be
changed. TCP/IP is one of those high-value interfaces.
>>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.
I can't let this statement stand. I don't know who you have been
corresponding with -- a lot a people can legitimately claim to have
made some contribution to the Linux networking code, but I'm one of the few
(perhaps the only) long-term, consistent, major contributor to the Linux
networking code.
And I feel the major reason that Linux doesn't use the BSD networking code
was the USL lawsuit.
I'm not going to claim that there wasn't any element of NIH in the decision.
After all, the seed of Linux could be described as NIH. But it's not like
it was true NIH. OSI was NIH. Token ring was NIH. IPX was NIH. But
Linux, the POSIX compatible OS written in ANSI C communicating using TCP/IP,
wasn't ignoring working well-known interface specifications just to be
different.
>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?
Errr, I guess you haven't read any of the Linux source. Hint: I wasn't
worried about at least one of those organizations.
And no, the people *without* much money involved were worried about the USL
suit. The suit wasn't about the short term money. It was about the
ownership and control of the BSD OS source. Look at all of the anonymous FTP
sites that pulled the BSD networking source pending the resolution of the
suit. Why did they do that -- they weren't deriving incoming from
distributing the code. From your statement, you they wouldn't have been
taking any legal risk, either. Besides, it's a time-honored legal tradition
to go after smaller poorly-funded parties first in order to establish
precedent.
>Not-Invented-Here is a strange syndrome. I know, having suffered it
>myself. The suffers are often unable to preceive or admit their
>affliction.
Oh, so if I deny NIH, it must be true. But if I admit it...
>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.
I'm not too sensitive about this one. If it were true we would only have
bits and pieces of an system. Sure, you'll find minor missing pieces in any
large system if you look hard enough, but by-and-large Linux is a pretty
complete system.
>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
Wait a minute: that's not what I said. I *don't* think ATM is a good
solution. I just don't think it going to fail for the right technical
reasons (missing protocol details, hard unsolved datarate issues, etc)
but rather it will never be considered because people can't run their
existing network applications on it.
>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>>.
Oh, if only they were played out. People are still pushing all of those
things. FDDI in particular is being touted as a better, cheaper, and more
standard solution than 100{VG,baseX}. SNA is being touted as ideal for the
new ATM networks(?!), as is token ring (see Communications Week 7/18/94 pg.
47 for a good laugh -- managers *want* to believe this!).
--
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