Sofware in Review
Tech news
at TheJemReport.com
Software reviews
at SoftwareinReview.com
Hardware reviews
at HardwareinReview.com
Discuss technology
at TJRForum.com
Sofware in Review → Operating systems → BSD →

FreeBSD 7.0 review

By Jem Matzan

Here we are at the moment of truth for the FreeBSD operating system -- the 7.0 release. This is what FreeBSD users and developers have been waiting for ever since the dark days of the 5.X series when the promises of superior performance, threading, and stability fell flat. Though each release in the FreeBSD 6.X series improved markedly in quality and performance, 7.0 has been widely anticipated as the release that FreeBSD fans can have confidence in. I wish I could say that FreeBSD 7.0 lived up to the hype.

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. The FreeBSD Foundation is now the legal controlling entity for everything that encompasses FreeBSD.

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, but scalability drops off after 8), 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 18,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 little or 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). Your FreeBSD skills and expertise will be totally meaningless at an OS X terminal.

The majority of the FreeBSD base system is licensed under the 3-clause BSD license, although some included programs are governed by the GNU GPL or other open source licenses.

What's new in 7.0

There is nothing revolutionary about the 7.0 release in terms of the number or complexity of changes. Many new technologies are supported, many in-progress features are either ready for production or much closer to it, and one architecture has been dropped. You can read the full list of changes on your own, but here are the highlights:

  • Initial/experimental support for UltraSPARC T1-based computers
  • The Alpha architecture is no longer supported
  • Improved dual core CPU support
  • The 1:1 libthr threading model is now the default
  • Finer-grained IPC, networking, and scheduler locking
  • ZFS filesystem support
  • XFS filesystem read-only support
  • Bugfixes in the unionfs implementation
  • SCTP (Stream Control Transmission Protocol) support
  • New wireless network and sound card drivers
  • Improved support for experimental ARM-based devices
  • A new, more scalable user-level memory allocator
  • The freebsd-update utility, which provides binary release upgrades and security fixes, is now part of the base system

In terms of updated software at the time of release (these packages will upgrade over time through Ports), FreeBSD 7.0 offers:

  • X.Org 7.3
  • KDE 3.5.8
  • GNOME 2.20.2
  • GCC 4.2.1
  • BIND 9.4.2

Putting it to the test

The FreeBSD installation routine is unfortunately unchanged; it still complains about BIOS disk geometry (which is alarming and confusing to people who don't know the insignificant history behind why it complains), and selecting a large number of binary packages involves hours of disc-switching among the CDs. The good news is that the partitioning scheme seems to scale better with larger disks than I remember in past releases. This can be difficult to understand from a Linux perspective because the largest partition -- /usr -- on FreeBSD is also the default location for the symlinked /home and /sys directories. I'm not sure that I agree with the small default size of /var, but it's not like you can't adjust that manually.

Unfortunately the AMD64 edition would not install on a Sun Java Workstation w2100z (dual Opteron 250). The disc would boot and almost get to sysinstall, but the program itself did not seem to start properly. I could ctrl-c and bring up a sysinstall window that gave me the option to abort or restart the installation process, but neither did anything meaningful. Turning off ACPI or starting in Safe Mode caused a hard lockup.

FreeBSD 7.0 is supposed to have significant performance gains over 6.3, so I spent about two hours setting up a testing environment and collecting benchmark data with Super Smack and Sysbench. Unfortunately, when I went to install FreeBSD 6.3 on the same machine, all it did was kernel panic during startup, so I was not able to complete the benchmark testing.

While I was working on benchmarking, I noticed that the GENERIC kernel config file had debugging symbols turned on by default. I disabled this, installed a properly tuned make.conf, compiled and installed a new kernel, and saw a measurable increase in performance (not a terribly significant increase, but it did show up in Sysbench).

Annoyingly, on test systems that use USB keyboards, I would sometimes have to unplug and replug the keyboard in order for it to work at the login prompt. In the past, the USB keyboard problem was worse, so I suppose this is an improvement.

I was surprised to discover that an old Realtek-based 802.11b wireless PC card was unsupported in FreeBSD 7.0. I could have sworn that it worked in 6.2, but when I installed 6.2 to test it out, I found that it was unsupported there as well. I must have been thinking of OpenBSD, which has had a working driver for that card for the past several releases. No luck on a sound driver on the same 3-year-old laptop test computer, which I found equally disappointing. I used to be under the impression that FreeBSD had reasonably good hardware support, but in taking notes on hardware compatibility problems in 7.0, I've discovered that among all of the Unix-like operating systems I have tested in the past year, encompassing other BSD variants and Linux distributions, FreeBSD 7.0 has by far the worst hardware compatibility of all.

Aside from the above, I could detect no other significant changes in FreeBSD from an ordinary user's perspective. All of the same old FreeBSD processes and habits remain unchanged.

Conclusions and developer recommendations

Though FreeBSD's internals have changed for better, it still needs a lot of work before I'd recommend it as a production-ready as a server or desktop operating system. In my review of FreeBSD 6.2 more than a year ago (I didn't review 6.3 -- it was only out for a month before 7.0 eclipsed it), I said that FreeBSD lacked an identity, meaning that it's difficult for an operating system to be "general purpose" and meet the needs of all niche users. FreeBSD can be many things if properly tuned, but that is predicated on the ability to tune the operating environment without breaking it or exposing its limitations. To me, FreeBSD's identity is one of theoretical superiority and realistic inconsistency. On paper, FreeBSD should be a technologically advanced operating system, but when you actually install it on a computer, its limitations are glaring: It lacks the network driver support that OpenBSD and Linux have, it doesn't work properly on established workstation hardware, and the lack of reasonably complete installed-by-default configuration files makes initial installation and configuration more of a hassle than it should be.

FreeBSD 7.0 seems to be a marginal improvement over 6.2, but I get the impression that the gigantic mistakes from 5.X are still being mopped up. The ULE scheduler still isn't finished. Some of the network drivers are still screwed up. Maximum CPU scalability still hovers around 8 processing cores. The AMD64 port is still garbage. I used to think that these problems would be fixed in the next release, but after many such disappointing releases, I now accept that they are as much a part of FreeBSD's identity as its overinflated reputation as a network server. This is an operating system with problems, and the past few years worth of releases have shown that it will probably always be this way. The "old" FreeBSD -- the reliable, stable, speedy network server -- died when 4.X ended development.

I've long since lost the hope of returning to FreeBSD as a desktop or server operating system on my computers. It's probably going to be Linux and OpenBSD for me from here on in, barring some revolutionary change in FreeBSD. But that's the trouble with FreeBSD -- like an addicted gambler, it keeps trying to raise the stakes and make big changes in every release to atone for time wasted on fixing old problems. That backfires in the form of stability and hardware support problems, and then the developers scramble to fix them, continuing the cycle of failure. It won't end until the development philosophy changes to one of a large number of small, non-disruptive changes, and a relentless focus on superior stability and hardware support.

In summary, here's what I'd like to see in future FreeBSD releases:

  • AMD64 release testing. FreeBSD has always had the most buggy and unstable AMD64 port of any operating system I've tested. Back in the early 5.X days it was almost usable, then it got worse as driver problems escalated. I can't tell if the problem is markedly better or worse in 7.0 -- it won't even install on my (three year-old) dual Opteron 250 test machine, but maybe that's better than the constant network and disk driver crashes of the old days. The grace period for AMD64 development mistakes was over several years ago.
  • A more intelligent kernel profile. The default FreeBSD 7.0 kernel configuration has debugging symbols enabled, and excludes many drivers and options that could be quite useful. Instead of forcing people to make a LINT configuration to use as a reference, I'd rather see an updated and streamlined GENERIC config with all of the potential options commented out.
  • Overhaul the installation routine. 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. Why can't the package installation logic be tuned to install all of the packages queued on a disc before needing to switch discs? Why can't I put in custom wireless network settings to connect to WEP- or WPA-enabled networks? The sysinstall utility was fine as FreeBSD was growing, but now that it's more advanced and more people are using it, it's time to take a hard, critical look at this installation program and give it a major overhaul. It doens't have to be graphical, but it does have to be practical.
  • 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 and predictable 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. At the very least, it would reduce clutter if there could be a make.conf switch to compile for a specific language, if available -- that would reduce the need for separate language categories in Ports.
  • Less hassle for the JDK and JRE. The FreeBSD Foundation has a license to distribute JDK and JRE binaries from Sun, but you still have to go to the Foundation Web site, suffer through a ridiculous "click-wrap" license agreement that no one actually agrees with, and download a file. You must then copy it 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. What's the point of having the distribution license? Why can't we just make install clean in /usr/ports/java/diablo-jdk15/ and be done with it?
  • 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 SVGA monitors for local control of servers. Why is FreeBSD emulating a terminal that could reasonably be found in a museum? 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. This would likely require a more modern command shell that has color and scrolling capabilities enabled by default, also.
Purpose Operating system
Manufacturer The FreeBSD project
Architectures x86, Xbox, AMD64/EM64T, SPARC64, PC98, 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.3 (6.2 review linked)
Product Web site Click here