Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!zombie.ncsc.mil!paladin.american.edu!gatech!newsfeed.pitt.edu!godot.cc.duq.edu!news.duke.edu!agate!news.mindlink.net!sol.ctr.columbia.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Linux or FreeBSD
Date: 25 Aug 1995 19:48:39 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 135
Message-ID: <41l9eo$17h@park.uvsc.edu>
References: <409iah$inf@galaxy.ucr.edu> <40alp5$psg@agate.berkeley.edu> <413bkc$3t2@kadath.zeitgeist.net> <1995Aug24.222509.28085@state.systems.sa.gov.au> <41ko58$rqh@hamilton.maths.tcd.ie>
NNTP-Posting-Host: hecate.artisoft.com
tim@maths.tcd.ie (Timothy Murphy) wrote:
] I run Linux and FreeBSD, and I have never noticed the slightest difference.
]
] I read all these comments, "FreeBSD does this better", "Linux does that better",
] and I just wonder how many of the posters have actually tested their conclusions.
]
] In my view, the only serious difference is that Linux documentation is much better.
] I said this before, and was flamed for my impertinence.
] In fact, I only mentioned it to suggest that if FreeBSD is to flourish
] it ought to look to its documentation.
]
] Personally, I think there is room in the world for Linux and FreeBSD.
Me too.
However, I run both Linux and FreeBSD on a daily basis, and I have
to say that a single packet drop takes a lot longer to recover from
on Linux. I don't notice anything on BSD, but there appears to be
some problem with the TCP restart timers that I haven't bothered
to track down on Linux yet.
Basically, the BSD box will still get packets through, whereas the
Linux box wil drop the rlogin connection.
This mostly occurs when I'm starting up elm on a remote system
where I typically have a 2500 message mailbox.
On a noisy net connection (Alternet), I use the Linux box as an X
terminal for the BSD box to go out, rather than going out directly
from the Linux box to work around the problem.
The BSD box seemed to get "hiccups" -- that is, the program startup
of an xterm from the linux box is not instantaneous. I thought
this was a problem with the fill algorithm on the BSD disk caching,
meaning it was waiting for a free block. Turns out that this is a
Linux problem with swapping the X window manager (twm) when the
box is busy.
BSD still negotiates linemode when telnetting to some Solaris
boxes. Bloody annoying -- so does Windows 95's Telnet, and so
does Linux, though. mostly it's a screwup caused by using "resize"
from OpenWin3 in your .cshrc.
I've done kernel developement in both BSD and Linux. For the most
part, the BSD kernel is an easier environment to develop in, but
the Linux environment has several plusses as well. The first plus
is the kernel module loading interface in Linux is much closer to
my original design for BSD, with the restricted exported symbol
list. I'm allowed to criticise BSD's method because I designed it
back before Novell bought USL as a stopgap for console developement.
The second plus in the Linux kernel is also a minus. Linux copies
in path names from user space using a single routine; it does not
have a copyinstr. This is both bad and good. It's good because
some of the hacking I'm doing now could benefit greatly from having
just one point to change. BSD uses copyinstr to pull in pathnames,
pathnames used as data, pathnames used as hybridized data, strings
that are data, and pathnames explicitly pulled in for binary
compatability. This is also bad, since Linux can't support the
data usage or the binary compatability usage without a lot of
extra warts. Host names for NFS mounts using a kernel NFS client,
login names for setlogin/getlogin, module names for the kernel
module unload, and environment strings translated for binary
compatability all fall into the "wart" category on Linux. I've
sent several patches in through friends who are involved in the
Linux community to file system code.
Other than that, BSD's kernel design is more orthogonal. The
binary compatability issues have been most elegantly solved by
NetBSD, though they too have their warts (they effectively use
variant symbolic links, but the special case the lookup code
to get hit twice with a relative path rather than implementing
real variant symbolic links or the logcal naming support needed
to make them really work). FreeBSD is the next most elegant, and
Linux is probably least elegant because of the aformentioned
binary compatability warts.
Linux is suboptimal in the error case. In many instances, an
error will amplify and become a full blown problem. I've sent
several patches in through friends who are involved in the Linux
community... none are explicitly from me, but they *are* there.
As far as distributions are concerned, well, FreeBSD is most
uniform, followed by Linux (though you have to pick the one you
get with care -- there are many Linux distributions, even if
there is only one true kernel), followed by NetBSD (they spend
their time porting, not packaging). With FreeBSD, the file
locations, and which files constitute a part of the distribution,
don't change as arbitrarily as they do in Linux.
The Linux move towards STREAMS (as bad as STREAMS is in many
peoples opinions) opens up the possibility of running more
commercial code. Like the NetWare for UNIX server. There is
occasional noise on the Samba list about writing a NetWare
server -- why hasn't this been done? Well, you are over 400
NCP's which you have to support, none of which you can obtain
a description for without non-disclosure prohibiting you from
building a NetWare server. It's a near impossible task (even
the commercial NetWare clones, as in Windows NT and Puzzle systems.
don't correctly implement everything that's needed -- they need
a NetWare server on the wire and they need to use Novell's
utilities). So STREAMS is a plus for Linux, though it's long
term and shouldn't factor into a short term decision.
Documentation is an issue, but it's also a red herring. There is
a significant amount of printed literature that deals with BSD
and UNIX that is directly applicable to BSD. It's just not
necessarily labelled "BSD". The Linux documentation that exists
is rarely more useful than the printed materials not specific to
BSD when it comes to doing "interesting things". The main cry
in these cases (like writing device drivers) is that "the source
code is the documentation".
If you take a good, hard look under the sheets, there are massive
differences between FreeBSD and NetBSD, let alone either of them
and Linux. Unfortunately, all three are moving targets, so it's
not possible to provide a fair qualatative analysis without getting
flames to death by people who fix the problems you note in the
analysis between the time you note them and the time you post
about them (or worse: fix them between the first and second posting
and then flame you for the second posting. 8-)).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.