Sofware in Review
Tech news
Software reviews
Hardware reviews
Discuss technology
Sofware in Review → Operating systems → BSD →

FreeBSD 6.2 review

By Jem Matzan

It's been a long road to recovery, but after years of mediocre releases, and months of delays in the development process, FreeBSD is finally back on its feet with 6.2-RELEASE. Though it is an excellent operating system, even this latest version offers few or no competitive advantages over Solaris or the other BSDs in a server role, and can never hope to compete with commercial GNU/Linux distributions for desktop computers. FreeBSD 6.2 is what FreeBSD 5.0 needed to be, and for those who have already switched to other operating systems, there are few or no compelling reasons to go back.

FreeBSD overview

This section is for people who are new to FreeBSD. If you're already familiar with it, you may want to skip down to the next section.

Originally developed from the Unix-based Berkeley Software Distribution, FreeBSD is among the oldest extant Unix derivatives. It is currently maintained and improved by a large team of programmers, and supported monetarily by individual and corporate donors.

From FreeBSD you can generally expect a relatively modern Unix-like operating system, heavily armed with network services and tools. As far as command-line-oriented operating environments go, FreeBSD is generally easy to install, configure, and administer on servers and desktop machines. FreeBSD is scalable up to 12 CPUs (this is as many parallel CPUs as it has been officially tested with), which includes SMP support for Hyper-Threading and multi-core processors, though it is not currently able to distinguish among these different technologies.

Aside from the programs included in the base system, FreeBSD offers extra software via pre-compiled binary packages; and a Ports system, which functions much like a less automatic version of Gentoo's Portage software management framework. From Ports you can download, compile, and install more than 13,000 programs. There are no applications in the free software canon that are not available in the FreeBSD Ports tree; beyond that, there are a few ports that are specific to the BSD world. There is also an available Linux binary compatibility layer which is efficient enough to say that there is no noticeable performance difference between Linux binaries and FreeBSD binaries running on the same system.

A common misconception about FreeBSD is that Apple OS X is based on it. While there is some FreeBSD code in Darwin (which is the operating system that forms the basis for OS X), the OS X kernel is based primarily on Mach, not FreeBSD, so OS X is not "based on" or "developed from" FreeBSD in the traditional sense (such as the way the original BSD was developed from AT&T Unix from the late 1970s to the early '90s, or the way OpenBSD was forked from NetBSD in 1995).

The majority of the FreeBSD base system is licensed under the free software BSD license, although some included programs are governed by the GNU GPL or other free software licenses.

What's new in 6.2

Once again, the FreeBSD development team has chosen a more graceful, sensibly-paced development than had been its habit in years past. Instead of large, disruptive changes, 6.2-RELEASE is mostly a collection of smaller changes that bring a greater sense of stability to the operating system.

A complete list of changes since 6.1 can be found in the release notes for AMD64 and i386, but the highlights are:

  • Various bug and security fixes.
  • A new audit kernel option, which enables kernel-level security logging.
  • Updated hardware support for Atheros, Intel, and Broadcom network chips, among others.
  • New support for the VIA Padlock encryption chip integrated into some EPIA motherboards.

Putting it to the test

The first thing I noticed about FreeBSD 6.2 was that it once again failed to properly recognize the keyboard on two different systems. Both used PS/2 connections for the keyboard and mouse, and neither have any input peripheral problems with any other operating system. Oddly, switching from a PS/2 connection to USB solved the problem. The irony here is that many previous FreeBSD releases had exactly the opposite problem -- PS/2 would work perfectly, but USB keyboards wouldn't be recognized beyond the boot screen.

I was disappointed to find that the traditional, long-standing disk drive geometry bug still exists in the sysinstall utility. This bug has been around so long that it actually seems like an old friend.

Neither a Realtek PCI network card nor the onboard Marvell LAN chip would work properly in a Core 2 Duo system based on an Asus P5B motherboard. Both were recognized, but neither could find an IP address from the DHCP server. A different system based on an Asus A8N-E motherboard with an Nvidia integrated LAN chip worked fine. A PCI Atheros-based network card was recognized, but in order to configure it for my wireless network I'd have had to know the exact ifconfig parameters to type in. Since I wasn't really sure what the settings were, I couldn't test wireless during installation. Post-install, after a lengthy consultation with the ifconfig man page, I was able to get everything running perfectly.

The good news about the installation procedure in FreeBSD 6.2 is that the discs are more sensibly organized, so when you select a lot of packages to install, there isn't as much disc switching as there was in previous releases.

After installing 6.2-RELEASE I was unable to find any showstopping bugs, which is truly a relief considering the hard crashes I was used to with the 5.x series, even carrying over somewhat into 6.0-RELEASE. I gave it quite a rough time, compiling several behemoths in the Ports tree, and testing a variety of different configurations on three different machines over a period of time ranging from the last release candidate to the time of this writing.

One particular gripe I have had about FreeBSD for several years is that initial configuration is unusually labor-intensive. You start out with barebones or non-existent configuration files for important programs like make and cvsup, and the default shell doesn't do tab completion very well, nor does it have a scrollback feature. Files have to be created or copied over from /usr/share/examples/ and then heavily edited just to get the system into a halfway-usable condition. Then you have to edit the kernel configuration and compile a new FreeBSD kernel because the default options are suitable for nothing beyond FreeBSD development. Once all of this is done, you end up with a highly customized, usable, and functional operating system. Getting there shouldn't take so much work, though.

Conclusions and developer recommendations

FreeBSD 6.2 is a fine Unix-like operating system. It's too bad it took so long to iron out the wrinkles; 6.2-RELEASE is what FreeBSD needed to be 3 or 4 years ago. Because of the scheduler problems and various issues with GEOM, the big giant lock, and the struggle to get a sensible SMP implementation going, FreeBSD fell behind while other competing OSes like Solaris and various GNU/Linux distributions forged ahead. FreeBSD is left without an identity in the modern operating system market. The work that's gone into the 6.x series may be too little, too late.

Not that it's at all unsuitable for such work, but in its current condition, it is undoubtedly too late for FreeBSD to regain its once-great market share in the Internet server arena, and there is no prayer holy enough to help FreeBSD overtake GNU/Linux in the "alternative" desktop OS market (FreeBSD-based projects like DesktopBSD aside). So what's left? Perhaps it's time to bring a new identity to FreeBSD. Some suggestions follow:

  • Modernize the command line experience. The default terminal emulator -- itself an ancient and no longer valid concept -- is designed for monochrome Unix terminals like the DEC VT100 and VT220. Those have not been widely used in ages; in fact they ended production more than 20 years ago, before FreeBSD even began life in its current form. Sysadmins generally use OpenSSH for remote administration, and keyboards and monitors for local control of servers. Why is FreeBSD using a shell that doesn't at all compare feature-for-feature with more modern alternatives like zsh or Bash, and was designed to be used on terminals that could reasonably be found in museums? We all have high-resolution color screens, standard desktop keyboards, and mice or touchpads -- or at very least, the workstations and desktops we administer our servers from over OpenSSH do. Since the command line interface is a necessary part of the FreeBSD experience, it's time to drag it -- kicking and screaming, if necessary -- into the 21st century.
  • More kernel profiles. The default FreeBSD kernel is insufficient for just about every practical use I can think of, except perhaps FreeBSD kernel development. I'd like to see at least two distinct, thoughtfully tuned kernel configurations: one for network servers, one for desktop computers. Ideally you'd be able to select between the two profiles in sysinstall. At the very least, this would make modifying the kernel a little easier.
  • Fix the drive geometry bug. In every FreeBSD installation I have ever performed, sysinstall says it can't determine drive geometry settings. But then it either does detect them correctly despite the warning, or you can put in a bunch of dummy settings and it successfully redetects the second time. How many years has this bug been around for? Is someone trying to set a record?
  • Installation of default config files. After installation, FreeBSD is left with no real make.conf or rc.conf, although there are example files in /usr/share/examples. Every time I install FreeBSD, I find myself copying over these files (and cvsup supfiles) to /etc and customizing them myself. I don't see why the examples can't be installed into /etc by default -- or why this can't be an option in sysinstall.
  • Better organization of the Ports tree. Although I think that the Ports tree in general could do with a standard naming convention for categories and programs, a bigger complaint of mine is that every non-English language has to have its own directory. If all of the foreign language ports were moved to a single directory (or a metadirectory to house the current dirs), it would make finding categories and programs much easier. I also think that the science directory could include the biology and astro categories, and I strongly question the need for an "x11-clocks" software category.
  • Less hassle for the JDK and JRE. FreeBSD now has a license to distribute JDK and JRE binaries from Sun, but you still have to go to a Web site, suffer through a ridiculous "click-wrap" license agreement that no one actually agrees with, and download a file or two. You must then copy the files to /usr/ports/distfiles/ and then attempt to install the Java port again. This is not much easier than the bad old days when you had to chase down files from 3 or 4 different sites to get Java going. Maybe this will all be solved when Sun open-sources Java in the near future.
Purpose Operating system
Manufacturer The FreeBSD project
Architectures x86 (with a special port for the Microsoft Xbox system), AMD64/EM64T, SPARC64, PC98, Alpha, PPC, IA64
License BSD, although some parts of the base system are under the GPL or other free software licenses
Market Web, email, and other network servers; also useful as a desktop OS
Price (retail) Free to download, or $40 for a CD set
Previous version FreeBSD 6.1
Product Web site Click here