Subject: Re: Future of NetBSD??
To: None <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 07/02/1995 11:38:34
This is the crux of the issue - NetBSD is a research and development
platform, FreeBSD is a users platform.
That's vastly over-simplified. Users want several things: features,
stability, and support; and there are trade-offs between all of them.
Since this has already turned into a political argument, I don't feel
too bad about saying the following...
For stability, I have no doubt that NetBSD is better. All you have to
do is look back at things like PPP totally failing on FreeBSD 2.0
systems, or the massive VM instabilities in the same release. (This
is sometimes excused by the release being `rushed' by legal issues,
but it's worth noting that our own 1.0 release happened earlier,
resolved similar legal issues, and has proven fairly reliable -- and
it runs on several architectures.)
For support, it's pretty much a toss-up. It was pretty clear from
several users' comments that the perceived `support' for NetBSD was
better for a long time. There was a big push in the FreeBSD camp to
change this perception. The result, as far as I can tell, is a large
barrage of `Oh; that's an interesting bug.'-like responses and no real
improvement in useful content. (This is not to say that our `support'
couldn't be improved, but it already compares favorably.)
For features, it depends on what you want. NetBSD currently runs on
11 architectures, with more coming, and has binary compatibility with
7 other OSes (and that's not counting BSDI compatibility and WINE, and
the work being done on DOSEMU). It runs most Linux and SCO software
almost entirely transparently, which means you can use commercial
software on it. (I know many people who not only do this, but rely on
it.) So far, the only `interesting' foreign program that FreeBSD has
run is the Linux version of DOOM.
For device drivers, FreeBSD is currently a little `better' on PCs.
But this has come at a cost -- GPLed code and other aggressive
licensing terms, and in some cases extremely poor code -- which the
NetBSD `core' group (which is, collectively, the system architect) is
unwilling to incur.
BTW, it's also worth noting that major components (not the least of
which is the shared library system) were taken wholesale from NetBSD
to be used in FreeBSD. In fact, early on, they incorporated the
NetBSD 0.8 source tree almost verbatim. Don't get the impression that
they developed a dancing frog by themselves.
It's really a matter of goals. The FreeBSD team is trying to compete
with Linux at a feature level. The only way to compete with fast,
sloppy coding at a feature level is to do fast, sloppy coding yourself
(unless you have a lot of money). The NetBSD group, by and large,
refuses to do this. While this means that, at any given time, NetBSD
is likely to not have some feature or other that Linux or FreeBSD has,
it means that, in general, the existing features are much more robust.
And in some cases (notably, the binary emulations, and to a lesser
extent the ports to other architectures), this careful plodding has
made significant new features so much easier to write that we have
vastly surpassed any other system.
In short, if what you really, really want is to have a Wombat 2000
driver yesterday, and that's all you care about, then perhaps you
*should* consider using a different system. (Honestly, though, you
should consider using DOS/Windows in that case, since it supports more
PC hardware than any other OS.) But if what you want is a (usually
B-)) reliable, evolving system, with significant care put into its
design, and written with a sharp eye toward portability and code
reuse, then you probably want NetBSD.