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". 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. 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. 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.