Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Path: bga.com!news.sprintlink.net!news.onramp.net!convex!cs.utexas.edu!
howland.reston.ans.net!EU.net!ieunet!curia!usenet
From: d...@odyssey.ucc.ie
Subject: Whats wrong with Linux networking ???
Message-ID: <Cu107E.Mz3@curia.ucc.ie>
Lines: 13
Sender: use...@curia.ucc.ie
Organization: University College, Cork
Date: Thu, 4 Aug 1994 20:47:29 GMT
OK, I keep hearing reference to how Linux networking is not as good
as FreeBSD and so forth
usually in the form of 'Linux networking, being written from the ground up,
and as opposed to 386BSD derivatives rather cleverly using the available
and stable NET/2 code' (and of course this ignites the whole
licencing debate)...
what I want to know is, can anyone back this up with facts ? What
exactly doesn't Linux do (or does do, but incorrectly) ?
thanks
David
Path: bga.com!news.sprintlink.net!hookup!yeshua.marcam.com!
charnel.ecst.csuchico.edu!psgrain!quagga.ru.ac.za!Braae!g89r4222
From: c...@cs.ru.ac.za (Geoff Rehmet)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Subject: Re: Whats wrong with Linux networking ???
Date: 6 Aug 1994 10:18:19 GMT
Organization: Rhodes University Computing Services
Lines: 22
Message-ID: <31vo1b$87t@quagga.ru.ac.za>
References: <Cu107E.Mz3@curia.ucc.ie>
Reply-To: c...@cs.ru.ac.za
NNTP-Posting-Host: braae.ru.ac.za
X-Newsreader: NN version 6.5.0 #4 (NOV)
In <Cu107E....@curia.ucc.ie> d...@odyssey.ucc.ie writes:
>OK, I keep hearing reference to how Linux networking is not as good
>as FreeBSD and so forth
...
>what I want to know is, can anyone back this up with facts ? What
>exactly doesn't Linux do (or does do, but incorrectly) ?
A major difference I have noticed is that on Linux NFS runs at a
fraction of the speed achieved on FreeBSD. This is mainly due to a far
more simplistic implementation (I didn't compare the code much, but this
is very obvious). Probably a big factor is the absence of the nfsiod
(aka biod in SunOS) in Linux. It might be a good idea to base a
reimplementation on the nqnfs work in 4.4BSD - which implements cache
coherency under NFS via leasing.
Geoff.
--
Geoff Rehmet, Computer Science Department, | ____ _ o /\
Rhodes University, South Africa |___ _-\_<, / /\/\
FreeBSD core team | (*)/'(*) /\/ / \ \
c...@cs.ru.ac.za, c...@freefall.cdrom.com, ge...@neptune.ru.ac.za
Path: bga.com!news.sprintlink.net!uunet!cs.utexas.edu!swrinde!gatech!
psuvax1!news.pop.psu.edu!ra.nrl.navy.mil!sundance!cmetz
From: cm...@sundance.itd.nrl.navy.mil (Craig Metz)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Subject: Re: Whats wrong with Linux networking ???
Date: 8 Aug 1994 12:07:28 GMT
Organization: Information Technology Division, Naval Research Laboratory
Lines: 22
Message-ID: <325760$rc9@ra.nrl.navy.mil>
References: <Cu107E.Mz3@curia.ucc.ie> <31vo1b$87t@quagga.ru.ac.za>
NNTP-Posting-Host: sundance.itd.nrl.navy.mil
In article <31vo1b$...@quagga.ru.ac.za>, Geoff Rehmet <c...@cs.ru.ac.za> wrote:
>In <Cu107E....@curia.ucc.ie> d...@odyssey.ucc.ie writes:
>
>>OK, I keep hearing reference to how Linux networking is not as good
>>as FreeBSD and so forth
>...
>>what I want to know is, can anyone back this up with facts ? What
>>exactly doesn't Linux do (or does do, but incorrectly) ?
>
>A major difference I have noticed is that on Linux NFS runs at a
>fraction of the speed achieved on FreeBSD. This is mainly due to a far
>more simplistic implementation (I didn't compare the code much, but this
>is very obvious). Probably a big factor is the absence of the nfsiod
>(aka biod in SunOS) in Linux. It might be a good idea to base a
>reimplementation on the nqnfs work in 4.4BSD - which implements cache
>coherency under NFS via leasing.
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.
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Path: bga.com!news.sprintlink.net!news.onramp.net!convex!news.duke.edu!
MathWorks.Com!europa.eng.gtefsd.com!news.msfc.nasa.gov!news.larc.nasa.gov!
saimiri.primate.wisc.edu!news.doit.wisc.edu!decwrl!netcomsv!netcomsv!
calcite!vjs
From: v...@calcite.rhyolite.com (Vernon Schryver)
Subject: Re: Whats wrong with Linux networking ???
Message-ID: <Cu8CBr.Fx@calcite.rhyolite.com>
Organization: Rhyolite Software
Date: Mon, 8 Aug 1994 18:50:15 GMT
References: <Cu107E.Mz3@curia.ucc.ie> <31vo1b$87t@quagga.ru.ac.za>
<325760$rc9@ra.nrl.navy.mil>
Lines: 25
In article <325760$...@ra.nrl.navy.mil> cm...@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!?!
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?
If one were going to write an NFS-like-but-different protocol, say
something with better cache coherence and lock mechanisms, then it would
might sense to start from scratch. But something identical to the
current, old NFS protocol? Why?
Vernon Schryver v...@rhyolite.com
Path: bga.com!news.sprintlink.net!hookup!ames!elroy.jpl.nasa.gov!usc!
howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!emory!
cherry.atlanta.com!nntp.mindspring.com!usenet
From: rsand...@mindspring.com (Robert Sanders)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Subject: Re: Whats wrong with Linux networking ???
Date: 09 Aug 1994 04:38:12 GMT
Organization: MindSpring Enterprises, Inc.
Lines: 41
Message-ID: <RSANDERS.94Aug9003813@hrothgar.mindspring.com>
References: <Cu107E.Mz3@curia.ucc.ie> <31vo1b$87t@quagga.ru.ac.za>
<325760$rc9@ra.nrl.navy.mil> <Cu8CBr.Fx@calcite.rhyolite.com>
NNTP-Posting-Host: hrothgar.mindspring.com
In-reply-to: vjs@calcite.rhyolite.com's message of Mon, 8 Aug 1994 18:50:15 GMT
On Mon, 8 Aug 1994 18:50:15 GMT, v...@calcite.rhyolite.com (Vernon Schryver) said:
> In article <325760$...@ra.nrl.navy.mil>
> cm...@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.
> 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.
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.
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?
-- Robert
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Path: bga.com!news.sprintlink.net!hookup!swrinde!elroy.jpl.nasa.gov!decwrl!
amd!netcomsv!calcite!vjs
From: v...@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.94Aug9003...@hrothgar.mindspring.com>
rsand...@mindspring.com (Robert Sanders) writes:
>On Mon, 8 Aug 1994 18:50:15 GMT, v...@calcite.rhyolite.com (Vernon Schryver)
said:
>
>> In article <325760$...@ra.nrl.navy.mil>
>> cm...@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 v...@rhyolite.com
Path: bga.com!news.sprintlink.net!hookup!swrinde!howland.reston.ans.net!
EU.net!sunic!news.funet.fi!news.csc.fi!news.helsinki.fi!not-for-mail
From: torva...@cc.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Subject: Re: Whats wrong with Linux networking ???
Date: 11 Aug 1994 12:49:04 +0300
Organization: University of Helsinki
Lines: 60
Message-ID: <32cs6g$l9t@klaava.Helsinki.FI>
References: <325760$rc9@ra.nrl.navy.mil> <Cu8CBr.Fx@calcite.rhyolite.com>
<RSANDERS.94Aug9003813@hrothgar.mindspring.com> <CuA6w1.5tF@calcite.rhyolite.com>
NNTP-Posting-Host: klaava.helsinki.fi
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
In article <CuA6w1....@calcite.rhyolite.com>,
Vernon Schryver <v...@calcite.rhyolite.com> wrote:
>
>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?
Actually, USL/AT&T had little to do with the inception of linux at all,
other than being the original home of unix.. The discussion seems to
think that linux is "new" on the unix market, but linux has actually
been out there longer than the free 386bsd variants, and the major
reason I started on linux in the first place was that there was nothing
else available to me.
Admittedly, 386bsd was being worked on back when I started it, but I had
nothing more to go on than the articles in DDJ. The USL lawsuit came in
much later, and had no impact at all on the general kernel development:
there have been very few areas where it would have made sense to borrow
code from the other unixes (the migration has in most cases been in the
other direction - the BSD projects have found several linux subsystems
very interesting).
> 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.
From a personal standpoint, I have to admit to being happy that linux
has its own networking: it has had some problems, but they haven't been
much worse than any other part of the kernel (they have /seemed/ a lot
worse, as the code gets compared to the other parts that had already
mostly stablized).
For some of the other developers, the USL lawsuit was one fear (even for
something like the CSLIP code which we *did* take from others). Another
argument was that the BSD mbufs don't make any sense these days where
memory is cheap (and caches makes pointer jumping look bad), and using
them would just be shooting oneself in the foot in the long run.
Naturally NIH has been a factor, but it hasn't been the only one, and
some of what you seem to call NIH is just a matter of deciding it's
easier to rewrite despite the problems. And it often is - the whole
linux kernel was started after 386bsd, but still was usable at an
earlier point (I'll ignore some of the reasons for 386bsd being late -
it's part of the same picture, IMHO).
>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.
Don't be silly. It's a clone on the *user* level, not internally.
Internally, it looks a *lot* different: mostly just because it has a
different history, partly because I think some "real Unix" ideas are
braindead ("spl-level" - ugh. Inherently stupid, and probably only done
because the original machines had priority-coded interrupts. Similarly
for disklabels.). And then we stole a lot of ideas from others too :-)
Linus
Path: bga.com!news.sprintlink.net!primenet!netnews.asu.edu!asuvax!gatech!
swrinde!cs.utexas.edu!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!
swidir.switch.ch!newsfeed.ACO.net!Austria.EU.net!EU.net!uunet!
gatekeeper.us.oracle.com!barrnet.net!cdrom.com!wcarchive.cdrom.com!jkh
From: j...@freefall.cdrom.com (Jordan K. Hubbard)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Subject: Re: Whats wrong with Linux networking ???
Date: 10 Aug 1994 19:08:11 GMT
Organization: Walnut Creek CDROM
Lines: 23
Message-ID: <JKH.94Aug10120811@freefall.cdrom.com>
References: <325760$rc9@ra.nrl.navy.mil> <Cu8CBr.Fx@calcite.rhyolite.com>
<RSANDERS.94Aug9003813@hrothgar.mindspring.com>
<CuA6w1.5tF@calcite.rhyolite.com> <32acqn$ghb@ra.nrl.navy.mil>
NNTP-Posting-Host: freefall.cdrom.com
In-reply-to: cmetz@sundance.itd.nrl.navy.mil's message of 10 Aug 1994 11:14:31 GMT
This conversation is getting out of hand and mutated back into the
traditional "Linux vs FreeBSD" discussion about 5 articles back.
Please cease and desist, everyone! We don't need this crap in our
lists, and if the Linux advocates want to flame on about their
favorite OS then FINE but they already have their own newsgroups for
this! Likewise, the BSD people should REFRAIN from following them
over there. There are always going to be people who say "BSD is god,
Linux is crap!" and vice-versa, that's just the nature of USENET and
the countless opinionated, no-life people who populate it. What's not
forgivable is to say such things in the OTHER camp's newsgroups!
That's called flame-baiting and we have more than enough of that already,
thank you.
Likewise, if you're from the "opposing camp" and you see something you
don't like in the other camp's newsgroup, then KEEP IT TO YOURSELF!
No one *cares* about your rebuttal and you're only making yourself
look like a royal idiot by rising to the bait! Don't *read* the other
newsgroups if they upset you and simply stay in your own patch, ok?
If we can keep our dogs off *your* lawn in return, then I think we'll
all be much happier for it and will increase the SNR of both groups
significantly.
Jordan