The NetBSD system

Well designed

Probably the primary goal of the NetBSD project is emphasizing correct
design and well written code.
One example is the implementation of a machine independent bus
infrastructure, which enables a single driver for a device (such as an
Ethernet or SCSI interface) to be shared across different
busses (such as PCI, EISA, Turbochannel), and across different
platforms (alpha, pmax, i386, etc),
rather than the traditional approach
of writing and maintaining many different versions of the driver, each with
their own tweaks. In NetBSD, the `tweaks' are in small 'glue' functions
that allow improvements to the core driver to benefit all ports.

This also means that, in many cases, a new port is as simple as implementing
the machine specific code to access the machine independent bus
infrastructure to utilize drivers that have already been written.

Some systems seem to have the philosophy of "If it works,
it's right". In that light NetBSD could be described as
"It doesn't work unless it's
right".

Complete

Just what defines a "complete" system?
NetBSD provides a relatively lean standard system, with all the base
functionality expected of a BSD system: the network protocols, the
ability to recompile itself, and so on. Extra facilities are provided by
a package system, which allows third party applications to be easily
installed, either from source or prebuilt binaries.
This allows the NetBSD developers to concentrate their efforts on the
core system.

Stable

NetBSD runs on a wide range of equipment with innumerable possible hardware
combinations. This makes good machine independent design essential for
success. The net result is a system that is in production use throughout the
world on dozens of distinct hardware platforms. That's the bottom line.

Fast

NetBSD runs on some of the slowest
vax and hp300 machines, to the largest
AlphaServer
8x00
and Opteron systems.
Maintaining acceptable performance on machines with
limited CPU and memory resources pays dividends on more powerful machines
as well; code bloat has to be kept to a minimum. We also support a wide
range of communications hardware, from slow serial and parallel devices,
to Ethernet, FDDI and (800Mb/s) HIPPI interfaces.

Microoptimizations can play a part in any system, but design is even more
important. Rewriting a routine to speed it up by 80% may sound impressive,
but that routine may have only been using 5% of the CPU time. Looking at
the larger picture and saving 10% overall by redesigning the way an
operation is carried out gives over double the benefit.
There is room for both in NetBSD, but we prefer getting a design right to
tweaking a poor implementation.