This section is for people new to OpenBSD. If you're already familiar with it, you may want to skip down to the next section on the improvements in 3.9.
The BSDs in general have a common reputation for high code quality and poor hardware support. In OpenBSD's case, the code is definitely high quality. Nothing in the default installation is half-implemented, or committed on an experimental basis. If full functionality is not yet possible for hardware drivers, basic functionality is achieved and thoroughly tested; this forms the basis for further driver development. Everything you get in the release is production-ready, secure by default (meaning the administrator does not have to lock down the system -- it is already locked down, and services must be individually enabled), and comes with possibly the finest integrated documentation in the Unix-clone world. While you might find a poorly programmed driver or other base system component in other BSDs and GNU/Linux distributions, in OpenBSD if something is supported, it works. Like all operating systems, however -- yes, even Windows -- not everything is supported.
Hardware support is a sensitive area for the OpenBSD developers. Since they won't allow any proprietary code in the base system, and since manufacturers are reluctant to dedicate resources to writing official OpenBSD drivers, the development team is notorious for creating their own drivers through reverse-engineering. As a result, OpenBSD's RAID and wireless network card support is exceptional -- better than Linux's in some ways. It also has surprisingly good ACPI support, particularly on laptop computers. In fact, because of the good, documented wireless and ACPI support, OpenBSD makes a fine laptop operating system. The only significant obstacle for desktop users is the lack of hardware 3D acceleration for video cards.
OpenBSD is among the most secure x86/AMD64 operating systems in the world. Cryptography is integrated into nearly every part of the operating system; libraries are loaded in a random fashion; and program and daemon privileges can easily be isolated from the rest of the system via chroot, and privilege separation and revocation.
A complete OpenBSD installation from the commercial CD set can be completed in about five minutes. Extra programs can be added through an APT-like package tool that has access to thousands of precompiled packages, or custom compiled through the Ports system. OpenBSD even has binary emulation layers for FreeBSD, Linux, Unix SVR4, SCO/ISC, and BSD/OS programs, so if there is no native OpenBSD port of your favorite *NIX application, you can probably still use it.
Each OpenBSD release has a graphical theme and a song that goes with it. The theme reflects a major concern that the OpenBSD programmers are addressing or bringing to light.
New in 3.9
OpenBSD advances slowly; each release represents a large collection of small changes. If you want a complete list of changes since 3.8, visit the 3.9 changelog. Below are the highlights:
- Better Apple PPC support
- Improved x86/AMD64 hardware support, especially network adapters and drive controllers (standard fare for OpenBSD releases)
- Upgrade support in the package tools
- Revamped wireless networking framework
- Support for hardware sensors
OpenBSD 3.9's theme revolves around "the blob," referring to proprietary hardware drivers that rely on a large binary file to achieve full functionality. these "binary blobs" are often poorly programmed and are incomplete, support few devices or configurations, and have bugs that the operating system's programmers can't fix because they don't have access to the source code. Blobs cannot be fixed by anyone other than the device manufacturer, and if they have security holes, the operating system developers can't patch it. Binary blobs also present a licensing threat because the proprietary agreements that govern them put heavy restrictions on redistribution. Some operating system projects or companies will work out distribution agreements, but rarely are such deals made for free, and they generally restrict the user's freedom to redistribute the software on their own. Understandably, projects like OpenBSD and GNU find situations like that to be inconvenient at best, and dangerous at worst.
Putting it to the test
Usually I try to "break" an operating system by putting it on a wide variety of computers. Since I have never been able to cause any errors (aside from trying to use RAID cards that are not supported), I skipped that phase and decided to spend the entire time using OpenBSD instead.
I found the improved package tools to be a huge benefit. Rather than
compile everything from source or download the packages and dependencies that I
wanted to install, I set the configuration to download packages automatically
when I try to install anything from Ports. So I go to /usr/ports/editors/vim
and when I run
make install clean, a package is downloaded instead
of compiling it from source; if a package isn't available, Ports goes ahead
with the compilation. I also tried out the new update option, but being so
close to the release, no updated packages were found. Just to see what would
happen, I substituted a 3.8 package directory for a 3.9 installation. The
result was that many of the packages showed upgrades which were really
downgrades to 3.8 packages. I suspect that is a bug -- package upgrade tools
should only recognize higher versions as upgrades, and there should be some
effort to verify that the source directory contains viable and up-to-date
The specific configuration options necessary to make OpenBSD fetch packages automatically are (in /root/.profile, or if you su to root, in your user's profile):
Substitute your preferred OpenBSD mirror for the false address above.
Conclusions and developer recommendations
The improved package tools make OpenBSD much easier to install, upgrade, and maintain. For those who need to install several programs on top of the base system, the new package tool functions are priceless.
Here are some features I'd like to see added to future editions of OpenBSD:
- Default color console support. The DEC VT220 terminal, along with all other monochrome consoles, is long dead -- even Digital itself replaced the VT200 series with color text and graphics terminals. Why is OpenBSD still using it if it's so old and limited? For the x86 and AMD64 OpenBSD ports, I'd like to see some enhanced console features. Color (which can be achieved presently by either hacking the terminal config files, or by installing GNU Screen and setting "screen" to the default terminal) and framebuffer support for higher resolutions are two modern conveniences that I'd love to see in the default OpenBSD installation.
- Easier Java installation. I realize that licensing restrictions prevent the Java Development Kit from being distributed with OpenBSD. Those same licensing issues prevent an easy JDK installation, but I'm sure it could be a little simpler than downloading so many files from multiple sites and waiting hours for the source code to compile, then adding the path settings by hand. Can't some kind of agreement be worked out with Sun to provide an OpenBSD binary, even if it is not included with the base system? The Java source code is available, so it wouldn't technically have the same status as a "binary blob."
- WPA support. I know that WPA is a lousy way to encrypt wireless data and that it creates a false sense of security, but there are a lot of wireless access points that require clients to use WPA. Since OpenBSD's wireless networking framework does not yet support it, you can't connect an OpenBSD machine to a router that requires it.
|Manufacturer||The OpenBSD Project|
|Architectures||x86, AMD64/EM64T, SPARC, SPARC64, Alpha, HP300, HPPA, Mac68k, MacPPC, mvme68k, mvme88k, luna88k, VAX, MIPS, Zaurus|
|Market||Servers of all kinds, for home, office, or enterprise; security-minded desktop users and sysadmins|
|Price (retail)||U.S. $45|
|Previous version||OpenBSD 3.8|
|Product Web site||Click here|