Newsgroups: comp.os.386bsd.questions
Path: bga.com!news.sprintlink.net!hookup!swrinde!gatech!
howland.reston.ans.net!agate!doc.ic.ac.uk!uknet!EU.net!uunet!
psinntp!hk.super.net!uxmail!hpg30a.csc.cuhk.hk!hkuxb.hku.hk!
ipc17!cfwong
From: cfw...@csd.hku.hk (Andrew C. F. Wong)
Subject: Linux or FreeBSD?
Message-ID: <Cq6u20.KFw@hkuxb.hku.hk>
Sender: use...@hkuxb.hku.hk (USENET News System)
Nntp-Posting-Host: ipc17.csd.hku.hk
Organization: The University of Hong Kong
X-Newsreader: TIN [version 1.1 PL6]
Date: Sun, 22 May 1994 05:03:36 GMT
Lines: 15
Dear all,
I want to setup a unix-compliant system on my 486 machine.
However, I am stuck to which one shall I choose, Linux or
freeBSD? If you suggest Linux, then which Linux? There
are several packages, namely, slackware, MCC Interim, TAMU,
SLS. I just don't know which one is the most powerful and
popular. Besides, what's the newest release of XFree86?
Thanx for your kind attention.
and RESPONDS!
Andrew
Newsgroups: comp.os.386bsd.questions
Path: gmd.de!nntp.gmd.de!newsserver.jvnc.net!darwin.sura.net!
howland.reston.ans.net!cs.utexas.edu!swrinde!pipex!uknet!EU.net!
goya!sanson!cdt94001
From: cdt94...@oasis.dit.upm.es (GARCIA VALDEARENAS)
Subject: Re: Linux or FreeBSD?
Message-ID: <CqH2z7.29E@dit.upm.es>
Sender: use...@dit.upm.es (System Management uucp news)
Nntp-Posting-Host: lprog04
Organization: Dpto. Ingenieria de Sistemas Telematicos, UPM, Madrid, Spain
X-Newsreader: Tin 1.1 PL4
References: <Cq6u20.KFw@hkuxb.hku.hk>
Date: Fri, 27 May 1994 17:52:19 GMT
Lines: 14
Linux is faster than FreeBSD, but has a very poor network support. If you are not
going to be connected to a network Linux is better. Linux supports graphics whithout
X. Linux can execute many MS-DOS programs using a MS-DOS emulator (exceptions are
all MS-Windows programs). Linux can execute all SCO binaries (so you can buy many
programs for Linux) .
Support for MS-Windows programs under Linux and FreeBSD is under development.
Currently only very few programs can run under MS-Windows emulator ("wine").
The most popular distribution of Linux is Slackware. It is very easy to install.
The last version of XFree86 is XFree 3.0 included in X11R6 but is not very popular.
XFree86 2.1.1 is more suitable for people not involved in X development.
Path: bga.com!news.sprintlink.net!hookup!news.kei.com!MathWorks.Com!
europa.eng.gtefsd.com!news.uoregon.edu!usenet.coe.montana.edu!
bsd.coe.montana.edu!nate
From: n...@bsd.coe.montana.edu (Nate Williams)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Linux or FreeBSD?
Date: 27 May 1994 23:54:50 GMT
Organization: Montana State University, Bozeman MT
Lines: 23
Message-ID: <2s618a$34t@pdq.coe.montana.edu>
References: <Cq6u20.KFw@hkuxb.hku.hk> <CqH2z7.29E@dit.upm.es>
NNTP-Posting-Host: 153.90.192.29
In article <CqH2z7....@dit.upm.es>,
GARCIA VALDEARENAS <cdt94...@oasis.dit.upm.es> wrote:
> Linux is faster than FreeBSD, but has a very poor network support. If
Where do you get your numbers? Have you benchmarked Linux and FreeBSD
on the same hardware?
> Linux
> supports graphics whithout X. Linux can execute many MS-DOS programs
> using a MS-DOS emulator (exceptions are all MS-Windows programs). Linux
> can execute all SCO binaries (so you can buy many programs for Linux) .
^^^ (I'm pretty sure this isn't true either, though it
can execute some)
The above are all true however except for the one mention.
Nate
--
n...@bsd.coe.montana.edu | FreeBSD core member and all around tech.
n...@cs.montana.edu | weenie.
work #: (406) 994-4836 |
home #: (406) 586-0579 | Looking for a good job.
Path: bga.com!news.sprintlink.net!hookup!swrinde!gatech!prism!prism!
not-for-mail
From: gt81...@prism.gatech.edu (Robert Sanders)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Linux or FreeBSD?
Date: 28 May 1994 15:36:19 -0400
Organization: Georgia Institute of Technology
Lines: 55
Sender: gt81...@prism.gatech.edu
Message-ID: <2s86fj$cn4@acmex.gatech.edu>
References: <Cq6u20.KFw@hkuxb.hku.hk> <CqH2z7.29E@dit.upm.es>
<2s618a$34t@pdq.coe.montana.edu>
NNTP-Posting-Host: acmex.gatech.edu
n...@bsd.coe.montana.edu (Nate Williams) writes:
>In article <CqH2z7....@dit.upm.es>,
>GARCIA VALDEARENAS <cdt94...@oasis.dit.upm.es> wrote:
>> Linux is faster than FreeBSD, but has a very poor network support. If
>Where do you get your numbers? Have you benchmarked Linux and FreeBSD
>on the same hardware?
I don't think he has *any* numbers :-) My roommate installed FreeBSD on his
machine because we were both curious about how the other half lives. We
weren't entirely happy with it: it's not as tuned for interactive response as
Linux is, it has *apparently* slower disk access because of the synchronous
meta-data updates (I turned that option for Linux on and the slowdown is
similar), the shared libraries, whilc more conceptually "cleaner", were
slower than Linux's (or, at least, executable loading seemed slower), and
the base system was very spare (= didn't include perl, or much of any non-
BSD utility). No numbers for anything, of course, since we trust our own
subjective feelings; even if it's slower, we'd rather have a system that
*feels* faster, and Linux definitely feels faster under heavy load.
We also ran into some "gotchas", most of which I've forgotten. One that sticks
out in my recollection is the poor compatibility of /bin/sh. We replaced it
with bash, but didn't think to link /bin/sh statically. The system refused to
boot, apparently because the system uses /bin/sh to configure sharedlibs upon
startup.
Another problem was that the sound driver was apparently an old version and
produced poor results when used with GMOD on our Gravis Ultrasounds.
A point I hesitate to bring up is that FreeBSD didn't seem to work with Linux's
NFS server. Knowing that no *BSD will admit that it got things wrong, and not
knowing that Linux's NFS server got it right, all I'll say is that Solaris,
an MS-DOS client, and Chameleon NFS/32 for NT all worked perfectly with it, as
did Linux's client.
>> Linux
>> supports graphics whithout X. Linux can execute many MS-DOS programs
>> using a MS-DOS emulator (exceptions are all MS-Windows programs). Linux
>> can execute all SCO binaries (so you can buy many programs for Linux) .
> ^^^ (I'm pretty sure this isn't true either, though it
> can execute some)
>The above are all true however except for the one mention.
And except for the "very poor" network support, as I've mentioned in another
post. Linux's networking is very close to being fully mature. You can also
run many MS-Windows program under dosemu if you have a copy of Win3.0 (for real
mode), but since that's rare, that part is practically true.
--
_g, '96 --->>>>>>>>>> gt81...@prism.gatech.edu <<<<<<<<<--- CompSci ,g_
W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~' ro|-<ert s/_\ nders | who am I??? ^ from Superman '~~~**@@@@W
`*MV' hi,ocie! |-/ad! / \ss!! | ooga ooga!! | II (cool)! `VW*'
Newsgroups: comp.os.386bsd.questions
Path: bga.com!news.sprintlink.net!hookup!usc!howland.reston.ans.net!
wupost!csus.edu!netcom.com!hasty
From: ha...@netcom.com (Amancio Hasty Jr)
Subject: Re: Linux or FreeBSD?
Message-ID: <hastyCqJBED.9yz@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <CqH2z7.29E@dit.upm.es> <2s618a$34t@pdq.coe.montana.edu>
<2s86fj$cn4@acmex.gatech.edu>
Date: Sat, 28 May 1994 22:49:24 GMT
Lines: 93
In article <2s86fj$...@acmex.gatech.edu> gt81...@prism.gatech.edu
(Robert Sanders) writes:
>n...@bsd.coe.montana.edu (Nate Williams) writes:
>
>>In article <CqH2z7....@dit.upm.es>,
>>GARCIA VALDEARENAS <cdt94...@oasis.dit.upm.es> wrote:
>>> Linux is faster than FreeBSD, but has a very poor network support. If
>
>>Where do you get your numbers? Have you benchmarked Linux and FreeBSD
>>on the same hardware?
>
>meta-data updates (I turned that option for Linux on and the slowdown is
** I have never lost a file system on any of my FreeBSD systems... **
>similar), the shared libraries, whilc more conceptually "cleaner", were
>slower than Linux's (or, at least, executable loading seemed slower), and
Does Linux have Dynamic Shared Libraries?
Because we do ....
>the base system was very spare (= didn't include perl, or much of any non-
>BSD utility). ^^^^
If you look just a tiny bit at any freebsd ftp site you will
definitely fine ported packages for sound, lang, etc...
For instance for the ported languages, freebsd.cdrom.com,
the official home of FreeBSD show:
257 "/.1/FreeBSD/FreeBSD-current/ports/lang" is current directory.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
CVS
bwbasic
Makefile
gcc1
perl
sather
schemetoc
scm
sml
tcl
tclX
xlispstat
franz
logo
itcl
>
>Another problem was that the sound driver was apparently an old version and
>produced poor results when used with GMOD on our Gravis Ultrasounds.
>
Hmmm...
Well if you get an old kernel you are liable to get poor results.
GMOD works fine over here...
We do have the latest Linux sound driver working and
additionally I modified the sound driver so it can support
bi-directional dma operations for the GUS.
The added functionality will be rolled back into the linux sound driver
and I heard reports that my mods do work under linux.
Also, Jim Lowe (for FreeBSD) modified the sound driver to support VAT, Van
Jacobsen's visual audio tool. What is vat? well it is currently being
used in the internet for voice conferencing, radio broadcast, or just
to chat with someone on the internet.
The *sources* for vat are not available!
vat also uses IP Multicasting not sure if IP multicasting is available
for Linux.
>A point I hesitate to bring up is that FreeBSD didn't seem to work with Linux's
>NFS server. Knowing that no *BSD will admit that it got things wrong, and not
>knowing that Linux's NFS server got it right, all I'll say is that Solaris,
>an MS-DOS client, and Chameleon NFS/32 for NT all worked perfectly with it, as
>did Linux's client.
>
How odd, that Sun OS NFS seems to work with FreeBSD...
Amancio
--
FREE unix, gcc, tcp/ip, X, open-look, netaudio, tcl/tk, MIME, midi,sound
at freebsd.cdrom.com:/pub/FreeBSD
Amancio Hasty, Consultant |
Home: (415) 495-3046 |
e-mail ha...@netcom.com | ftp-site depository of all my work:
| sunvis.rtpnc.epa.gov:/pub/386bsd/X
Path: bga.com!news.sprintlink.net!hookup!swrinde!gatech!prism!prism!
not-for-mail
From: gt81...@prism.gatech.edu (Robert Sanders)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Linux or FreeBSD?
Date: 28 May 1994 20:07:19 -0400
Organization: Georgia Institute of Technology
Lines: 117
Sender: gt81...@prism.gatech.edu
Message-ID: <2s8mbn$e1o@acmex.gatech.edu>
References: <CqH2z7.29E@dit.upm.es> <2s618a$34t@pdq.coe.montana.edu>
<2s86fj$cn4@acmex.gatech.edu> <hastyCqJBED.9yz@netcom.com>
NNTP-Posting-Host: acmex.gatech.edu
ha...@netcom.com (Amancio Hasty Jr) writes:
>In article <2s86fj$...@acmex.gatech.edu> gt81...@prism.gatech.edu
(Robert Sanders) writes:
>>n...@bsd.coe.montana.edu (Nate Williams) writes:
>>
>>>In article <CqH2z7....@dit.upm.es>,
>>>GARCIA VALDEARENAS <cdt94...@oasis.dit.upm.es> wrote:
>>>> Linux is faster than FreeBSD, but has a very poor network support. If
Okay, before I have to fend off Amancio's hostile remarks, let me emphasize
that all the "performance" issues I brought up were simply to help explain
why several people who have used Linux and *BSD have remarked that Linux
was "faster." I didn't want to start yet another penis-size war, just
explain that design decisions made by both sides will affect perceived
speed. Sheesh.
>>meta-data updates (I turned that option for Linux on and the slowdown is
>** I have never lost a file system on any of my FreeBSD systems... **
Er, ok. I never said you did, and I never said that the synchronous updates
were a bad thing. For your information, I've lost filesystems twice, both
times due to bad disks; Linux's ext2fs has proven very reliable for me.
The fact is that synchronous updates are merely one small measure against
filesystem corruption; recently-updated files may have a better chance
against corruption than on a non-synchronous system, but serious damage
won't care either way. I'd rather trust fsck when I have problems than suffer
throughput loss all the time for this unlikely occurrence.
If you want to impress me with filesystem stability, show me BSD 4.4's
log-structured filesystem running under FreeBSD. Then I'll agree that
*BSD has a definite advantage over Linux in that area.
>>similar), the shared libraries, whilc more conceptually "cleaner", were
>>slower than Linux's (or, at least, executable loading seemed slower), and
>Does Linux have Dynamic Shared Libraries?
>Because we do ....
I'm very well aware of the advantages of both implementations, thank you.
FreeBSD's implementation is inherently slower, but the tradeoff is a "cleaner"
system. What do you mean by "Dynamic Shared Libraries"? Linux has shared
libraries, and symbols in the executable can override those in the shared
library. But is the linking done at runtime? No. It's done at compile-time.
And we save a lot of CPU and page-dirtying for it.
>>the base system was very spare (= didn't include perl, or much of any non-
>>BSD utility). ^^^^
>If you look just a tiny bit at any freebsd ftp site you will
>definitely fine ported packages for sound, lang, etc...
Yes, thank you. We did do that, but we were rather surprised that the "base"
system didn't include many programs we had come to expect. Please read
my posts more closely before mouthing off.
>>Another problem was that the sound driver was apparently an old version and
>>produced poor results when used with GMOD on our Gravis Ultrasounds.
>Well if you get an old kernel you are liable to get poor results.
>GMOD works fine over here...
It was FreeBSD 1.1 Gamma. At the time, there was no newer kernel except
one culled from the -current tree. I thought you *BSD people were so
uppity about not having to play patch-of-the-day like Linuxers supposedly
do?
>Also, Jim Lowe (for FreeBSD) modified the sound driver to support VAT, Van
>Jacobsen's visual audio tool. What is vat? well it is currently being
>used in the internet for voice conferencing, radio broadcast, or just
>to chat with someone on the internet.
> The *sources* for vat are not available!
You keep harping on this in a thousand newsgroups. Frankly, Amancio, if I
want radio I will turn on my *radio*. I'm not interested in some bandwidth-
sucking audio net.geek IRC that Van Jacobsen was too high-and-mighty to
release the sources to. And if I were, it wouldn't be too terribly
difficult to get BSD binary compatibility working under Linux. We both
know how low a demand there is for that.
>vat also uses IP Multicasting not sure if IP multicasting is available
>for Linux.
Last I heard it wasn't officially available for FreeBSD, either, and you were
causing hackles to be raised by insisting that it was. Linux's device drivers
support multicast lists, but the actual protocol stack isn't ready. Seems
there isn't much demand for that, either.
>>A point I hesitate to bring up is that FreeBSD didn't seem to work with Linux's
>>NFS server. Knowing that no *BSD will admit that it got things wrong, and not
>>knowing that Linux's NFS server got it right, all I'll say is that Solaris,
>>an MS-DOS client, and Chameleon NFS/32 for NT all worked perfectly with it, as
>>did Linux's client.
>How odd, that Sun OS NFS seems to work with FreeBSD...
In which direction? And, if you wish to exchange childish snotty remarks,
how odd that SunOS's NFS worked with Linux (Linux->SunOS and SunOS->Linux).
If anyone's curious, FreeBSD would work well as a NFS client, but when
reading large files, the reading program would die with a "protocol not
supported" error in the middle. As I said, I'm not blaming anyone for
this, but it was one reason my roommate switched back to Linux.
I'd like to know why it didn't work: if it's Linux's problem, I'd like
to get it fixed. If it's FreeBSD's problem, I'm sure someone on the
core team would like to get it fixed. If it's an interoperability
problem that nobody but the spec can be blamed for, then perhaps
Linux (or FreeBSD) ought to be changed to conform to the "reference"
implementations. And don't say FreeBSD *is* the reference implementation,
because that code was rewritten for Net/2.
--
_g, '96 --->>>>>>>>>> gt81...@prism.gatech.edu <<<<<<<<<--- CompSci ,g_
W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~' ro|-<ert s/_\ nders | who am I??? ^ from Superman '~~~**@@@@W
`*MV' hi,ocie! |-/ad! / \ss!! | ooga ooga!! | II (cool)! `VW*'
Path: bga.com!news.sprintlink.net!news.onramp.net!convex!cs.utexas.edu!
swrinde!pipex!sunic!trane.uninett.no!eunet.no!nuug!EU.net!ieunet!
news.ieunet.ie!jkh
From: j...@whisker.hubbard.ie (Jordan K. Hubbard)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Linux or FreeBSD?
Date: 29 May 1994 03:01:01 GMT
Organization: Jordan Hubbard
Lines: 128
Message-ID: <JKH.94May29030102@whisker.hubbard.ie>
References: <CqH2z7.29E@dit.upm.es> <2s618a$34t@pdq.coe.montana.edu>
<2s86fj$cn4@acmex.gatech.edu> <hastyCqJBED.9yz@netcom.com>
<2s8mbn$e1o@acmex.gatech.edu>
NNTP-Posting-Host: whisker.hubbard.ie
In-reply-to: gt8134b@prism.gatech.edu's message of 28 May 1994 20:07:19 -0400
In article <2s8mbn$...@acmex.gatech.edu> gt81...@prism.gatech.edu
(Robert Sanders) writes:
Ok, everyone generally knows that I'm always careful to stay neutral
on the classing FreeBSD vs Linux issue, and I have always felt that
it's most important when discussing the two to BE HONEST about the
relative strengths and weaknesses of each one. You don't win
credibility for your OS of choice by saying things like "Our OS never
ever crashes and is totally and absolutely good in every respect and
anything you say to the contrary is BS, so there!" With that in mind,
I'd like to clear up a few points.
were a bad thing. For your information, I've lost filesystems twice, both
times due to bad disks; Linux's ext2fs has proven very reliable for me.
I'm sure that ext2fs has improved immeasurably since it first came
out, but just to note that some of its well-deserved suspicions have
come from early instability and the fact that one little f**kup could
generally cost you major chunks of your filesystem! If it's since
come along to the point where its stability ranks up there with FFS,
that's great, but also acknowledge that some people who've known it
for awhile have every right to be suspicious until it's really earned
its stripes.
If you want to impress me with filesystem stability, show me BSD 4.4's
log-structured filesystem running under FreeBSD. Then I'll agree that
*BSD has a definite advantage over Linux in that area.
If that's what it will take, then all I can say is wait about, say,
8-10 weeks or so for the first ALPHA snapshot of FreeBSD 2.0 :-)
I'm very well aware of the advantages of both implementations, thank you.
FreeBSD's implementation is inherently slower, but the tradeoff is a "cleaner"
system. What do you mean by "Dynamic Shared Libraries"? Linux has shared
libraries, and symbols in the executable can override those in the shared
library. But is the linking done at runtime? No. It's done at compile-time.
And we save a lot of CPU and page-dirtying for it.
This is another area where I think comparing the two quickly becomes
an exercise in thin justifications for Linux's approach (and shouldn't
even be raised as a point of argument when Linux has so many other
clear strengths that it could raise in its favor!). Sure, Linux's
approach is faster, but it's a F**KING NIGHTMARE from the application
developers point of view! I've talked about this quite a bit with
Warner Losh from ParcPlace (the OI people) and he often goes into
convulsions at the mere mention of how much time and agony he had to
put in to get OI's shared libs to work with Linux. By comparison,
building a shared lib under *BSD is generally no harder than it is on
a Sun (which is to say quite easy). Sometimes the advantages of a
`cleaner' implementation over the long run far outweigh some of the
more minimal run-time overhead issues (which can be made up in other
ways as you have time to add optimization), and I think that Linux's
approach will come to haunt its proponents more and more as the
popularity of it increases, eventually resulting in their being almost
_forced_ to go down the same road!
Parallels in industry already exist - Sun, DEC and HP generally went
the "FreeBSD" approach (though it's more accurate to say the opposite,
really) and now customers and important VARs simply accept that as a
rather seamless bit of functionality in the system, the fact that
almost no one even cares to make special mention of the functionality
being a testament to its ease of use. SCO, on the other hand, went
the Linux route and their customers and VARs screamed so loud
(especially the latter) that SCO is now so publically embarassed by
the shared library mechanism as to *actively discourage its use*!
I think no more need be said here as history will inevitably prove me
right. Like I said, Linux has some great features and I'm always
ready to give it its proper due, but its shared library implementation
is not one of those features.
Yes, thank you. We did do that, but we were rather surprised that the "base"
system didn't include many programs we had come to expect. Please read
my posts more closely before mouthing off.
I think what he meant to say was that such things are readily
available (even more so than the raw ports - look in the packages
directory). You definately can't please everyone, with 2/3 of the
people screaming for *smaller* releases and another third yelling for
more "base programs", and the bottom line is that I think we did it
right by decoupling a lot of this stuff from the system. In truth, we
will probably end up adding PERL as it's such a generally useful tool,
but things like emacs and xview will probably almost always remain
packages, and I think that's for the best. Did you try actually
adding any of the packages? I find it hard to see how anything could
be simpler..
It was FreeBSD 1.1 Gamma. At the time, there was no newer kernel except
one culled from the -current tree. I thought you *BSD people were so
uppity about not having to play patch-of-the-day like Linuxers supposedly
do?
We are, and if anything I'd have even preferred that you wait for the
first RELEASE version before evaluating it, but that's all water under
the bridge.
Last I heard it wasn't officially available for FreeBSD, either, and you were
causing hackles to be raised by insisting that it was. Linux's device drivers
Well, it will be present in 1.1.5 so just to make a note of it, it's
about to be `officially available' in less than a month's time.
>How odd, that Sun OS NFS seems to work with FreeBSD...
In which direction? And, if you wish to exchange childish snotty remarks,
how odd that SunOS's NFS worked with Linux (Linux->SunOS and SunOS->Linux).
I think he was referring to the fact that some Linux user had said
that Linux worked fine with all his other workstation hardware and
that FreeBSD didn't. Suffice to say that FreeBSD boxes happily
coexist in a mixed NIS/NFS environment containing both Suns, ALPHAs,
DECStations and IBM's so it DOES work. In some cases, if you use
cheap networking hardware (see our most recent FAQ) you will have to
reduce the R/W io size in order to get things working properly since
the faster workstation will swamp the network card completely.
We have examined the problem in detail and found that this is neither
a FreeBSD, workstation or NFS problem - it's a configuration problem.
Sure, we could pick defaults that make it interoperate in a guaranteed
fashion for each and every FreeBSD box, but we'd end up severely
penalizing folks with faster 16 bit ethernet cards and speedy PC's
(with which most NFS servers are actually configured). Now that it's
properly documented in the FAQ (and it wasn't for a long time - our
fault!), I anticipate that everyone will be able to get satisfactory
performance.
Jordan
--
Jordan K. Hubbard FreeBSD core team Friend to mollusks
Path: bga.com!news.sprintlink.net!demon!bt!pipex!howland.reston.ans.net!
gatech!prism!prism!not-for-mail
From: gt81...@prism.gatech.edu (Robert Sanders)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Linux or FreeBSD?
Date: 28 May 1994 23:47:09 -0400
Organization: Georgia Institute of Technology
Lines: 185
Sender: gt81...@prism.gatech.edu
Message-ID: <2s937t$7sp@acmex.gatech.edu>
References: <CqH2z7.29E@dit.upm.es> <2s618a$34t@pdq.coe.montana.edu>
<2s86fj$cn4@acmex.gatech.edu> <hastyCqJBED.9yz@netcom.com>
<2s8mbn$e1o@acmex.gatech.edu> <JKH.94May29030102@whisker.hubbard.ie>
NNTP-Posting-Host: acmex.gatech.edu
j...@whisker.hubbard.ie (Jordan K. Hubbard) writes:
>In article <2s8mbn$...@acmex.gatech.edu> gt81...@prism.gatech.edu
(Robert Sanders) writes:
>Ok, everyone generally knows that I'm always careful to stay neutral
>on the classing FreeBSD vs Linux issue, and I have always felt that
But this isn't one of those issues! Sure, that's the subject, but the
whole point of my two (now three) posts was to simply explain why
some people who had used both Linux and FreeBSD came away with the
subjective feeling that Linux was much faster. I don't give a damn
about feature comparisons from other people: my roommate and I went
out and *tried* it. In the same vein, I don't try to offer authoritative
feature comparisons; I merely summarize my expereinces.
If anything, I was trying to cut this flamewar off at the pass by
explaining that much of the apparent speed difference wasn't as
significant as it seems.
>it's most important when discussing the two to BE HONEST about the
>relative strengths and weaknesses of each one. You don't win
>credibility for your OS of choice by saying things like "Our OS never
>ever crashes and is totally and absolutely good in every respect and
>anything you say to the contrary is BS, so there!" With that in mind,
>I'd like to clear up a few points.
You're fighting straw men, Jordan. I never said that. I'm not trying
to win credibility for anyone, but if I were, it would be for FreeBSD.
Two separate messages on this group expressed dismay at the relative
speed of FreeBSD; one even said that out of Linux, Windows, etc., FreeBSD
was the slowest OS he'd had on the machine. I was trying to explain
that it isn't that slow, that it's just tuned less for interactive response
than Linux was.
> were a bad thing. For your information, I've lost filesystems twice, both
> times due to bad disks; Linux's ext2fs has proven very reliable for me.
>I'm sure that ext2fs has improved immeasurably since it first came
>out, but just to note that some of its well-deserved suspicions have
>come from early instability and the fact that one little f**kup could
>generally cost you major chunks of your filesystem! If it's since
>come along to the point where its stability ranks up there with FFS,
>that's great, but also acknowledge that some people who've known it
>for awhile have every right to be suspicious until it's really earned
>its stripes.
Well, this caveat could apply to all of Linux; none if it was very stable
until fairly recently (in UNIX time). I'm talking about the here and
now, and ext2fs in versions 1.0 and later is a *very* stable filesystem.
I've been using ext2fs since the very first ALPHA release. I know how
unstable it used to be, but believe me, it's fine now.
> If you want to impress me with filesystem stability, show me BSD 4.4's
> log-structured filesystem running under FreeBSD.
>If that's what it will take, then all I can say is wait about, say,
>8-10 weeks or so for the first ALPHA snapshot of FreeBSD 2.0 :-)
I can't wait. I'd like some of the BSD4.4 magic to filter over into
Linux. We should all benefit from the CSRG's dying breath.
> I'm very well aware of the advantages of both implementations, thank you.
> FreeBSD's implementation is inherently slower, but the tradeoff is a "cleaner"
> system. What do you mean by "Dynamic Shared Libraries"? Linux has shared
> libraries, and symbols in the executable can override those in the shared
> library. But is the linking done at runtime? No. It's done at compile-time.
> And we save a lot of CPU and page-dirtying for it.
>This is another area where I think comparing the two quickly becomes
>an exercise in thin justifications for Linux's approach (and shouldn't
>even be raised as a point of argument when Linux has so many other
>clear strengths that it could raise in its favor!).
Here you misinterpret my purpose. I'm not trying to justify Linux's approach
or promote Linux at all. I'm merely stating the facts. Yes, I admit that
Linux's approach is tougher for the developer. But it's like compilation
swicthes: gcc takes a hell of a lot longer with -O2, but you run the damn
thing much more than you compile it. Where should you pay?
>Sure, Linux's
>approach is faster, but it's a F**KING NIGHTMARE from the application
>developers point of view! I've talked about this quite a bit with
>Warner Losh from ParcPlace (the OI people) and he often goes into
>convulsions at the mere mention of how much time and agony he had to
>put in to get OI's shared libs to work with Linux.
Warner wasn't bitten by the shared library approach by itself; he was
also bitten by major changes in gcc name mangling and an ill-advised
reorganization of the Linux shared libraries without a corresponding
major version change. I feel for him, but nobody's had as hard a time
as Warner has.
>By comparison,
>building a shared lib under *BSD is generally no harder than it is on
>a Sun (which is to say quite easy). Sometimes the advantages of a
>`cleaner' implementation over the long run far outweigh some of the
>more minimal run-time overhead issues (which can be made up in other
>ways as you have time to add optimization), and I think that Linux's
>approach will come to haunt its proponents more and more as the
>popularity of it increases, eventually resulting in their being almost
>_forced_ to go down the same road!
I'm no proponent; I can't wait for Linux to use ELF-style executables and
shared libraries. We can already *use* them, in fact, we just can't generate
them because of deficiencies in the binutils. My kernel can load a version
of gzip compiled on SVR4 and link it against a version of the Linux shared
library compiled to be a Solaris-style (ELF) shared library. And then it
can run it :-)
But if you want to air dirty laundry, pull it all out. There's a greater
cost for purity of shared library implementations than just longer load
times and page dirtying. If you don't assign shared libraries fixed addresses,
you must compile the libs with position independent code. On the i386,
this has a much greater cost than on RISC processors with more registers to
spare. Eric Youngdale long ago measured a 10-15% slowdown for library
code (don't hold him to these numbers; he'd probably kill me for quoting
him).
I don't know if the Kranenberg/FreeBSD shlib implementation uses fixed
addresses; I doubt it does. Has anyone benchmarked statically linked
vs. dynamically linked executables on speed of *library* code? I'll
bet it's not insignificant. Again, I know Linux's implementation isn't
perfect, but there are good reasons to have it. Linux developers aren't
idiots.
>I think no more need be said here as history will inevitably prove me
>right. Like I said, Linux has some great features and I'm always
>ready to give it its proper due, but its shared library implementation
>is not one of those features.
I'm using them every day as a user with no problems. Now, as a developer,
they're causing problems because there's no clean interface for dynamic
loading of .o files prelinked against shared libraries into a running
application. But I think that if you surveyed Linux users, an overwhelming
majority wouldn't even be aware of any fault in the shared library mechanism.
It works (unlike, from what I hear, SCO's).
>You definately can't please everyone, with 2/3 of the
>people screaming for *smaller* releases and another third yelling for
>more "base programs", and the bottom line is that I think we did it
>right by decoupling a lot of this stuff from the system.
[...]
>Did you try actually
>adding any of the packages? I find it hard to see how anything could
>be simpler..
Yes, it was simple. It was a minor nit to pick, but there it was. I'm
not a very less-is-more person, and I didn't like the smallness of
FreeBSD. All a matter of taste, and all easily remedied. I shouldn't have
mentioned it.
> >How odd, that Sun OS NFS seems to work with FreeBSD...
> In which direction? And, if you wish to exchange childish snotty remarks,
> how odd that SunOS's NFS worked with Linux (Linux->SunOS and SunOS->Linux).
>I think he was referring to the fact that some Linux user had said
>that Linux worked fine with all his other workstation hardware and
>that FreeBSD didn't.
You may be misquoting me; I said that Linux worked fine with all my
other workstation hardware, but FreeBSD didn't work well with Linux.
Big difference. And I was very careful not to lay blame; it's just
something I mentioned because it was one of the reasons my roommate re-
installed Linux over FreeBSD.
>Sure, we could pick defaults that make it interoperate in a guaranteed
>fashion for each and every FreeBSD box, but we'd end up severely
>penalizing folks with faster 16 bit ethernet cards and speedy PC's
>(with which most NFS servers are actually configured).
Both our machines are 486dx33s with SMC Elite 16 cards. Not top-of-the-
line, but plenty fast for NFS service. I imagine the NFS problem was
some small vague corner of the NFS spec, but I didn't have the time
to trace it.
To sum it up: I wasn't contributing to the Linux-vs-FreeBSD thread
itself, but merely trying to comment on the apparent speed difference.
--
_g, '96 --->>>>>>>>>> gt81...@prism.gatech.edu <<<<<<<<<--- CompSci ,g_
W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~' ro|-<ert s/_\ nders | who am I??? ^ from Superman '~~~**@@@@W
`*MV' hi,ocie! |-/ad! / \ss!! | ooga ooga!! | II (cool)! `VW*'
Path: gmd.de!nntp.gmd.de!Germany.EU.net!EU.net!ieunet!news.ieunet.ie!jkh
From: j...@whisker.hubbard.ie (Jordan K. Hubbard)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Linux or FreeBSD?
Date: 29 May 1994 09:39:59 GMT
Organization: Jordan Hubbard
Lines: 116
Message-ID: <JKH.94May29093959@whisker.hubbard.ie>
References: <CqH2z7.29E@dit.upm.es> <2s618a$34t@pdq.coe.montana.edu>
<2s86fj$cn4@acmex.gatech.edu> <hastyCqJBED.9yz@netcom.com>
<2s8mbn$e1o@acmex.gatech.edu> <JKH.94May29030102@whisker.hubbard.ie>
<2s937t$7sp@acmex.gatech.edu>
NNTP-Posting-Host: whisker.hubbard.ie
In-reply-to: gt8134b@prism.gatech.edu's message of 28 May 1994 23:47:09 -0400
In article <2s937t$...@acmex.gatech.edu> gt81...@prism.gatech.edu
(Robert Sanders) writes:
But this isn't one of those issues! Sure, that's the subject, but the
whole point of my two (now three) posts was to simply explain why
some people who had used both Linux and FreeBSD came away with the
subjective feeling that Linux was much faster. I don't give a damn
about feature comparisons from other people: my roommate and I went
out and *tried* it. In the same vein, I don't try to offer authoritative
feature comparisons; I merely summarize my expereinces.
Well, I guess I should point out that I came in late to this
discussion and haven't seen your earlier posts, so I may have
misinterpreted your basic viewpoint from lack of sufficient context.
In fact, I do have to say that your basic approach is one that I
greatly approve of - I wish more people in this generally useless
FreeBSD vs Linux debate would actually _take the trouble_ to load and
run both for awhile before spouting off, and your willingness to do so
is only to your credit. That said, I think that it's also pretty
important in these `debates' (only in quotes because so few of them up
to now have qualified for such an exalted label ;-) to differentiate
between the *subjective* points and the *objective* points, since it's
sometimes hard to tell the genuine technical gripes from the personal
preference issues. Your later comments regarding packaging indicate
that you've probably realized that in retrospect, so I'll say no more
about it.
You're fighting straw men, Jordan. I never said that. I'm not trying
to win credibility for anyone, but if I were, it would be for FreeBSD.
Two separate messages on this group expressed dismay at the relative
speed of FreeBSD; one even said that out of Linux, Windows, etc., FreeBSD
was the slowest OS he'd had on the machine. I was trying to explain
that it isn't that slow, that it's just tuned less for interactive response
than Linux was.
Ok, fair enough. Again, blame me for coming in late. I might also
note that FreeBSD's detractors should also bear in mind that we, too
are still evolving and still have more than a few optimizations to go
- we're not at all insensitive to the criticisms of those Linux users
who make unfavorable (and credible) comparisons between FreeBSD's and
Linux's interactive response. When I met Linus in Holland last year,
one of the major points of discussion was, in fact, Linux's VM and
scheduling algorithms and how FreeBSD would do well to take a closer
look into how interactive processes were scheduled in environments
with small process counts. It should always be noted, of course, that
there's no free lunch with these things. Linux's scheduling and VM
code does offer superior performance with light job mixes, but the
`ramp' of performance vs number of system intensive processes actually
declines much faster on a Linux system as well, so you have to pay the
price somewhere. At least this was my experience with Linux 0.99, and
also backed up by a number of others (some of whom were die-hard Linux
fans).
This is, again, just being honest about where the plusses and minuses
lie and my personal preference would, of course, be a pan Linux and
FreeBSD team actively engaged in looking at performance issues (in
both light and heavily loaded environements) across BOTH operating
systems, trying to merge in some of the best features of each in order
to strengthen the quality of both. I would actively support such a
movement.
We should always bear in mind (and I don't necessarily mean you
personally, Robert, since I sense I'd be preaching to the choir) that
UNIX itself is what's living a somewhat besieged life here, not
FreeBSD or Linux specifically. If we want to extend the lives of both
in the face of competition from a number of `young turk' operating
systems now coming down the pike, we may someday have to seriously
consider working together just a little more (and I almost cry at the
amount of effort being gratuitously spent on parallel efforts or
competing implementations where there's _really no need_ for a lot of
it).
This is not to say that I necessarily see this as an easy thing, as
the frequently touted FreeBSD/NetBSD mergers have pointed out in very
painful detail, simply that it's a damn shame that it has to be the
case. I personally think that Linux and FreeBSD are also not so far
apart, ideologically speaking, and if FreeBSD and NetBSD cannot enjoy
a closer working relationship (though in truth it's far more cordial
as of late) then perhaps FreeBSD and Linux can. I'd be more than keen
to extend the requisite olive branches!
I don't know if the Kranenberg/FreeBSD shlib implementation uses fixed
addresses; I doubt it does. Has anyone benchmarked statically linked
vs. dynamically linked executables on speed of *library* code? I'll
bet it's not insignificant. Again, I know Linux's implementation isn't
perfect, but there are good reasons to have it. Linux developers aren't
idiots.
I never said they were, simply that I wasn't a big fan of some of the
trade-offs they chose. It's more than just a one-off hit to the
developers, as well. Did you know, for example, that OI lets you
create your own subclasses interactively, flesh them out, then bring
them up in the builder? Probably not since Linux's OI version has
never allowed you to do this (and boy, was I annoyed when I found this
out since I was trying to use the OI port to Linux to do some work!)
since it was too much trouble to generate a shared library
automatically without any intervention by the `customer'. I am happy
to see that Linux is heading down the ELF route, and I expect that
this will render many points like this moot, I simply wanted to point
out that it's not always a `one time cost' borne only by the developer
and then completely transparent to all users thereafter.
To sum it up: I wasn't contributing to the Linux-vs-FreeBSD thread
itself, but merely trying to comment on the apparent speed difference.
Ok.. Like I said, we're both still evolving OS's with great potential
for gains in performance and functionality, and if we can learn from
eachother's implementations, all the better. That is why an honest
appraisal of Linux's strengths is actually of *benefit* to me, and why
I generally have so little patience with these (in general, not yours)
Linux/FreeBSD flame wars that generate much heat but shed so little
useful light.
Jordan
--
Jordan K. Hubbard FreeBSD core team Friend to mollusks
Path: bga.com!news.sprintlink.net!hookup!news.moneng.mei.com!
howland.reston.ans.net!gatech!prism!prism!not-for-mail
From: gt81...@prism.gatech.edu (Robert Sanders)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Linux or FreeBSD?
Date: 29 May 1994 14:48:31 -0400
Organization: Georgia Institute of Technology
Lines: 99
Sender: gt81...@prism.gatech.edu
Message-ID: <2sao1v$guc@acmey.gatech.edu>
References: <CqH2z7.29E@dit.upm.es> <2s618a$34t@pdq.coe.montana.edu>
<2s86fj$cn4@acmex.gatech.edu> <hastyCqJBED.9yz@netcom.com>
<2s8mbn$e1o@acmex.gatech.edu> <JKH.94May29030102@whisker.hubbard.ie>
<2s937t$7sp@acmex.gatech.edu> <JKH.94May29093959@whisker.hubbard.ie>
NNTP-Posting-Host: acmey.gatech.edu
j...@whisker.hubbard.ie (Jordan K. Hubbard) writes:
>Linux's interactive response. When I met Linus in Holland last year,
>one of the major points of discussion was, in fact, Linux's VM and
>scheduling algorithms and how FreeBSD would do well to take a closer
>look into how interactive processes were scheduled in environments
>with small process counts. It should always be noted, of course, that
>there's no free lunch with these things. Linux's scheduling and VM
>code does offer superior performance with light job mixes, but the
>`ramp' of performance vs number of system intensive processes actually
>declines much faster on a Linux system as well, so you have to pay the
>price somewhere. At least this was my experience with Linux 0.99, and
>also backed up by a number of others (some of whom were die-hard Linux
>fans).
I agree as well. On the ephemeral compile benchmark, a FreeBSD system that,
to my Linux-trained senses, seemed like it was struggling actually outran
my underloaded Linux system. There have been at least 2 alternate
schedulers for Linux written and posted.
This issue of interactive response vs. performance under heavy load is
one that needs to be tunable for both systems. I usually prefer interactive
feel to overall performance, but there are situations in which I'd like to
have a hardier system.
>UNIX itself is what's living a somewhat besieged life here, not
>FreeBSD or Linux specifically. If we want to extend the lives of both
>in the face of competition from a number of `young turk' operating
>systems now coming down the pike, we may someday have to seriously
>consider working together just a little more (and I almost cry at the
>amount of effort being gratuitously spent on parallel efforts or
>competing implementations where there's _really no need_ for a lot of
>it).
In some ways I think it's unavoidable. To be sure, the iron curtain
keeping *BSD code from migrating to Linux has been the USL/BSDI lawsuit,
and the barrier in the other direction has been the GPL, but even if
we resolved all that, parallel development would still continue. Some
people are more interested in having fun hacking on something than in
creating the perfect OS, and I don't blame them.
It would be nice if efforts from one side could benefit the other, even
if the original effort didn't take that into account. I imagine part
of this problem could be solved once in code (i.e. kernel interface
emulation layers), but it'll never go away.
>case. I personally think that Linux and FreeBSD are also not so far
>apart, ideologically speaking, and if FreeBSD and NetBSD cannot enjoy
>a closer working relationship (though in truth it's far more cordial
>as of late) then perhaps FreeBSD and Linux can. I'd be more than keen
>to extend the requisite olive branches!
The problem is that Linux is more like a cheap sci-fi hive organism; it's
difficult to decide where the head is. Linus is the obvious person, but
he doesn't do most of the work anymore. There are three people that I
think already have an olive branch or two: Hannu Savolainen, the author
of the VoxWare (nee Linux) sound driver, Matthias Urlichs, who single-
handedly ported the BSD networking code to Linux, and Bill Metzenthan,
who (I believe) re-released his math coprocessor emulator under a BSD-like
copyright so *BSD could benefit from his excellent work. These are
all Linux people who decided to write for everybody, not just Linux.
Then again, I think Alan Cox et. al are doing a bang-up job on the Linux
networking code, and who am I to say that they should just drop it all
and adopt that of BSD? Like Ted T'so (I think) once said long ago, it's
not always useless competition; sometimes it's nice to explore different
problem spaces or to check the effectiveness of different solutions. The
*BSD people didn't like Linux shared libraries, so they didn't use the
Linux work.
The fact is that some Linux developers aren't as committed to the end
product as the *BSD teams are. To us, Linux is a wide open hacking ground,
and whether some luser likes the OS isn't a real issue. I'm not saying
that's a good thing (in many ways it's not), but that's how it is.
You know where I'd really like to see a coherent development effort? I'd
like to see some good people get together and write a Unix word processor.
More so than the many competing flavors, that issue is killing Unix.
FreeBSD, NetBSD, and Linux are all very competent operating systems,
but you've got to give people something to *do* under them.
>Did you know, for example, that OI lets you
>create your own subclasses interactively, flesh them out, then bring
>them up in the builder? Probably not since Linux's OI version has
>never allowed you to do this (and boy, was I annoyed when I found this
>out since I was trying to use the OI port to Linux to do some work!)
Well, no, because I've never used OI :-) Like I said, I'm helping to
port perl5 to Linux, and Linux really is the black sheep of dynamic loading.
I got word that the next binutils will support ELF on i386, so maybe
Linux is just a short step away from having a much more palatable
alternative.
--
_g, '96 --->>>>>>>>>> gt81...@prism.gatech.edu <<<<<<<<<--- CompSci ,g_
W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~' ro|-<ert s/_\ nders | who am I??? ^ from Superman '~~~**@@@@W
`*MV' hi,ocie! |-/ad! / \ss!! | ooga ooga!! | II (cool)! `VW*'