Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nexus.coast.net!simtel!noc.netcom.net!news.sprintlink.net!howland.reston.ans.net!Germany.EU.net!zib-berlin.de!news.tu-chemnitz.de!irz401!uriah.heep!bonnie.heep!not-for-mail
From: j@bonnie.heep.sax.de (J Wunsch)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: When did this become linux.advocacy
Date: 22 Jun 1995 14:44:06 +0200
Organization: Private U**x site, Dresden.
Lines: 121
Message-ID: <3sboim$ue@bonnie.tcd-dresden.de>
References: <marcus.114.00E9749F@ccelab.iastate.edu> <3s8pet$m65@bonnie.tcd-dresden.de> <3s9vmk$f9p@agate.berkeley.edu>
Reply-To: joerg_wunsch@uriah.heep.sax.de
NNTP-Posting-Host: 192.109.108.139
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Nick Kralevich <nickkral@octans.EECS.Berkeley.EDU> wrote:
>First of all, let me apologize in advance for even posting here again.
Not really needed, not for _that_ article. :) As promised in my mail,
here my public response.
>My first experiences with FreeBSD were bad. My roommate initially
>had 2.0_RELEASE installed. When I tried compiling programs (pine and
>lynx) I had lots of problems that I didn't have when I installed them
>on my Linux computer. In another one of my articles (not here, but
>on comp.os.linux.advocacy) I complained how sluggish I/O felt (30
>seconds to recursively delete a directory in Linux took 45 seconds in
>FreeBSD 2.0_RELEASE). The I/O problem improved when my roommate
>installed FreeBSD 2.0.5_RELEASE, and so did the compiling problems.
The IO problems are a different approach in the file system handling.
It's only apparent for those operations that cause heavy traffic
related with disk i-nodes (like an ``rm -r''), since the BSD approach
(and this has been discussed endlessly and is unlikely to be changed)
is rather conservative and does immediately and synchronously update
file system meta-data on the disk (unlike normal file data). This is
a conceptual decision made with the knowledge in mind that it might go
faster with asynchronous updates, but better safe than sorry. OTOH,
it's rather hard to crash a BSD UFS. (E.g. my experiences with SGI's
rather fast efs implementation are quite the opposite: turn off the
power of an Indy three times in short sequence, and you will almost
certainly need to re-install it from scratch.)
Many of the other problems with 2.0 require some basic knowledge of
FreeBSD's history. FreeBSD 1.1.5.1 is (as many here will certainly
confirm) a wonderfully stable system. I'm just typing on one of
these, used in a production environment as an NFS server with 36 MB
buffer cache... Everybody here is rather satisfied with it, silently
serving day by day. No comparision to some of the commercial work-
stations... (no names, please :).
Unfortunately, FreeBSD 1 has been based on Berkeley's Net-2 tape,
which later became subject of the quarrel between BSDi, the UCB and
USL/Novell. As a consequence, Walnut Creek has only been allowed to
distribute it until June, 1994. The decision of the core team has
been then, to re-vamp FreeBSD 2 from the grounds of the (legally
``blessed'') 4.4BSD release, and it was clear to everybody that this
process will take some time. Finally, after 5 months of not getting
any official release out, in November 1994 it has been decided to make
FreeBSD 2.0 ready, regardless of the many known problems and future
plans (like the merged VM/buffer cache). This has not been only to
let Walnut Creek CDROM make money again :), but also to ``stay on the
market''. Due to some timing problems (the release had to get out
before Jordan was flying to Europe for some time, or it would have
been delayed undefinately 'till after Christmas), it has also been
fairly incomplete with respect to the ``ports'' section. Many people
felt stronger to debug the basics of the operating system and didn't
have time to port foreign software to have it Plague&Pray-ready for
the 2.0 customer.
Numerous bugs have been fixed for the time being, and several hundred
of `ports' have been established meanwhile. Most of them are also
available as pre-compiled `packages'. The decision for release 2.1
has been that it will only leave the door if it's at least as stable
as 1.1.5.1 proved to be, in order to deserve the label ``2.1''.
That's why the current release is named ``2.0.5''. (But on the way to
2.0.5, it came out that we are not very far away from 2.1's expected
stability now, so the development for 2.1 is now closed except for
necessary bug fixes, and the main development is already done for
2.2.)
>... I also thought it was amazing that
>you couldn't change the serial port interrupt without recompiling a
>kernel (linux has a utility called "setserial". I still may be wrong
>about having to recompile the kernel, though).
FreeBSD had the `UserConfig' facility since 2.0R; you'll have to boot
with option `-c' and can not only change a single setup but any and
all of the hardware parameters for the configured drivers. Meanwhile,
there's also a way to merge these settings back into the /kernel
image, and it's being enabled by default in 2.0.5 (the name is
`dset').
>... Or the fact that the kernel compiling isn't
>more automatic like the Linux kernel config utilities.
We'd certainly most appreciate if somebody would provide a nice and
suitable package for this. :-)
>Other problems were just plain baffling, like "ifconfig" not being able to
>turn on the BROADCAST flag for the loopback device,
See Terry's response.
>... My experiences with Linux have been very good.
>For example, when I found a bug with their serial driver (probing the
>serial device caused a spurrious interrupt) I reported the bug to
>the serial code maintainer. Within 12 hours I had a patch from the
>maintainer, and within 3 days a new kernel, with the serial port patch,
>was released.
This is a difference by intention. We don't wanna manage too many
releases (and remember: we're maintaining a whole operating system,
not just a kernel only). Upgrades are a major pain for most people
(including me, and by far not limited to FreeBSD only -- ``Never
change a running system.''). We intend to have releases stable enough
for people to work with them, so upgrades should only be necessary to
get new features, support for new hardware etc. (Yes, i know, 2.0 has
been an exception here -- and it's the general opinion of most FreeBSD
hackers that it shall remain *the only* exception.)
>>Never trust an operating system you don't have sources for. ;-)
>Well, I'm glad we can agree on that. :)
Btw., that's not necessarily a plea for free operating systems only.
I've also seen kernel code from Data General, and it's been a great
help for me to understand the issues involved with that part of the
kernel. I've not seen other parts of the kernel code where i would
really have felt like fixing the bugs if i only had the d*mned
source...
--
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. ;-)