Date: Mon, 28 Aug 1995 10:06:01 +0200 From: j@bonnie.heep.sax.de (J Wunsch) To: freebsd-chat@freebsd.org Subject: Re: Linux or FreeBSD Message-ID: <199508280806.KAA26470@bonnie.tcd-dresden.de> In-Reply-To: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
For those who haven't seen it, finally a technically interesting
comparision between the various free unix systems, by Terry:
In article <41l9eo$17h@park.uvsc.edu> you write:
>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.
>
--
cheers, J"org private: joerg_wunsch@uriah.heep.sax.de
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508280806.KAA26470>