This section is for people who are not yet familiar with the OpenBSD operating system. Those who are may want to skip ahead to the next section on the new features in version 4.1
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 the finest integrated documentation in the operating system world. While you might find a poorly programmed driver or other base system component in other BSDs and Linux distributions, in OpenBSD if something is supported, it works. Like all operating systems, however, 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 frequently reluctant to give out hardware documentation, 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 works well as a laptop operating system, especially if you enjoy working from the command line interface. 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 more than 4000 precompiled software packages, or custom compiled through the Ports system, which has about 4200 programs available. 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 its Linux or FreeBSD binary.
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.
What's new in 4.2
The OpenBSD Project maintains a complete list of changes since 4.1 on its Web site. There have been hundreds of small improvements, but here are the highlights:
- Xenocara replaces the old monolithic X.org: An OpenBSD-specific build of the modular X.org 7.2 system -- called Xenocara -- is now the standard X11 implementation on OpenBSD.
- Performance improvements in networking code: A number of enhancements and cleanups in the network stack, especially in the Packet Filter and IPSEC, mean better network performance.
- Substantial improvements in
pkg_add: This command can now more intelligently upgrade installed packages.
- Hardware 3D acceleration for most Intel graphics chips: Integrated graphics processors that use the i810 X.org driver
- Improved SATA and IDE controller support: Among the many hardware improvements in 4.2, native high-end SATA and IDE disk controller support may be the most important to system performance and stability.
- New alpha, hppa, and sparc64 support: More machines that use these architectures will now work with OpenBSD.
- The sgi platform has been delayed: Due to technical concerns, the sgi platform was not included with the 4.2 release.
The theme for the 4.2 release is "The secure, open, and free marathon." In this metaphor-heavy cartoon footrace, characters representing OpenBSD, FreeBSD, Linux, Solaris, OS X, and Windows are trying to get to the finish line first. Windows is the first to drop out of the race, falling flat due to illness caused by viruses and deflated under the weight of too many sponsor stickers. Solaris takes a wrong turn and heads off in an "open" direction that doesn't lead to the finish line. OS X finds a trendy cafe at which it can play with Apple gadgets, essentially dropping out of the race to talk on its iPhone. Despite stealing OpenBSD's map, Linux is too busy racing around in different directions to get to the finish line, and FreeBSD is so intent on competing with Linux that it ignores the race as well, leaving OpenBSD to reach the finish line alone.
Putting it to the test
The installation procedure is mostly the same as it's been for the past several years, though the upgrade script has many improvements that make the process a little quicker and easier. There is still no option to intelligently and interactively merge old /etc/ files with new ones, though.
If there was hardware 3D support for integrated Intel graphics chips in the past, I didn't know about it until now. Most Intel-based laptop computers and many kinds of Intel brand desktop, server, and workstation motherboards have a graphics chip that will work with the kernel and X.org drivers in OpenBSD 4.2. That means 3D acceleration, which in turn translates into a much more enjoyable desktop experience. This probably means little to most desktop OpenBSD users, who are likely a minority of OpenBSD users, but it paves the way for a PC-BSD-like customization of OpenBSD for secure desktop computing. It also serves as a model for open source video driver development -- getting hardware 3D acceleration working in OpenBSD is effortless with the supported graphics chips. Few or no other command line-oriented Unix-like operating systems can make that claim.
pkg_add script gets markedly better with every OpenBSD release. It's gotten to the point now where it almost needs to be split out into separate scripts for adding and upgrading packages. In a short amount of time,
pkg_add's upgrade logic has reached a comparable level of intelligence to FreeBSD's package tools, and in fact the
pkg_add commands are now much more similar in their features and functions, assuming you have OpenBSD configured to retrieve packages from a package mirror.
Conclusions and developer recommendations
Of all of the operating systems that I regularly cover, OpenBSD is the one I most dread reviewing. It's extremely difficult to find something new to say each release -- it's always the same spiel about small improvements and superior design. Reviews generally concentrate on how much a product has changed since the last release (or review). One thing that hasn't changed in OpenBSD, thankfully, is its outstanding release engineering. OpenBSD 4.2, like all versions I have tested since 3.4, is a solid release. It's entirely reliable and delivers exactly what it claims to: A free, functional, and secure Unix-like operating system. Few operating systems, especially those that aim to be totally open source, are able to make such claims with a straight face.
So there are a lot of fundamental things about OpenBSD that I don't want to change. But there are some issues that have been bothering me over past few releases. Here's what I'd like to see in the future:
- Make mergemaster part of the base system. Upgrading is easier now than it's ever been, the only significant hurdle being upgrading configuration files, many of which haven't changed at all, some of which have changed little, and a few of which have changed in very important ways. It's not easy having to sort through every file in
/etc/and most of its subdirectories. There is an OpenBSD package for FreeBSD's mergemaster (which is made specifically for this process), but it would be helpful if it were included in the base system or made part of the upgrade process on the installation media and specialized for this task on OpenBSD. Currently it has a kind of wonky approach to updating the config files. Over the past two releases, the OpenBSD developers have made a patch available to attempt to intelligently merge old config files with the updated ones, but it doesn't work under some circumstances. Upgrading is a 6-month reality, not a potential future event, and I'd like to see OpenBSD address it as such.
- WPA support. It may be far from an ideal wireless security solution, but WPA support is important for many wireless users who need to be able to communicate with WPA-enabled access points.
- Improved wireless networking tools. Right now you have to do some fancy footwork with ifconfig to find and join a wireless network if there are multiple access points available. Joining one in specific can be difficult, especially if it requires a WEP key. Once you've configured it a few times, it's easy to remember the switches, but it would be nice to have some kind of program or script in the base system that could find and manage access points and wireless network profiles. Setting up a single network is easy, but when you're travelling and don't know the specs of the wireless network you want to connect to, it becomes a bit of a challenge.
- Better SMP support. Now that multi-core CPUs are basically the standard among laptop, desktop, and x86/AMD64 servers, and multi-core multi-CPU systems are becoming more common in servers, I think it's time to focus on expanding OpenBSD's SMP capabilities. A few releases ago we got initial SMP support, but from some basic performance tests that I've run, there's a lot of room for improvement in this area.
- Framebuffer console support. 80x25 is fine for some simple command line work, but sometimes you really need more than that, especially if you're monitoring processes through
ps. Scrolling up and down can distort continuity in the output. A barebones X.org session with an xterm is not really a good solution because it involves a lot of overhead; a framebuffer console is a superior option, and one that is available in FreeBSD and Linux, so there is plenty of existing code to reference.
|Manufacturer||The OpenBSD Project|
|Architectures||x86, AMD64/EM64T, SPARC, SPARC64, ARM, Alpha, HP300, HPPA, Mac68k, MacPPC, mvme68k, mvme88k, luna88k, VAX, MIPS, Zaurus|
|Market||Network appliances and servers of all kinds, for home, office, or enterprise; security-minded desktop users and sysadmins|
|Price (retail)||U.S. $50|
|Previous version||OpenBSD 4.1|
|Product Web site||Click here|