Aside from Linux, the other major "family" of Unix-like operating systems is the somewhat fragmented family based on the 4.4 BSD "Lite" release from University of California.
Had this code base been released to the world somewhat sooner, and the mixture of personalities been somewhat less volatile, Linux might well have been still-born, and people would be using some form of "BSDix" instead. Linus Torvalds has been quoted as saying that had 386BSD been available at the time, he would not have started building Linux. It is certainly the case that BSD code has strongly influenced the implementations of TCP/IP implementations on all sorts of platforms, free as well as commercial.
FreeBSD is a state of the art Unix-like operating system for "PC Compatible" computers, developed and maintained by a large team of individuals. (See: The FreeBSD Mall )
The NetBSD operating system is a freely available and redistributable BSD system that runs on a variety of hardware platforms.
The OpenBSD OS Project involves continuing development of a free multi-platform 4.4BSD-based Unix-like operating system. It very closely tracks NetBSD, and was originally established as a (rather messy) "fork" from NetBSD. Their "distinctive" is in the area of security. They seek to specifically provide a very secure version of BSD.
WindRiver BSD/OS is the commercial version of BSD.
What is Mac OS-X? -- an architectural overview
A project intended to be a continuation of FreeBSD providing a lightweight threaded port/message passing system, allowing massively increased asynchonicity.
The RetroBSD Project: 2.11BSD operating system for microcontrollers
These OSes tended in the past to be somewhat more stable than Linux, although the current situation is far more arguable. Network code in the BSD variants was traditionally much better than that in Linux, but this is far less true now as Linux users and developers have taken great interest in networking, and have greatly improved Linux code quality. They are probably still superior nonetheless for people with heavy server requirements, e.g. heavily loaded news, web, or database servers. There may remain some differences in code quality, but the differences are far less significant than they used to be.
There are periodic "wars" as to which of these OSes (Linux, FreeBSD, NetBSD, OpenBSD) is the "best." Technical criticisms are often based on problems in ancient versions that have since been partially or fully fixed. In my (theoretically humble) opinion, the following points would be worth considering:
FreeBSD tends to have more binary-level "emulation" options than the others. For instance, a Linux "emulator" library allows it to run many (most?) Linux programs.
Linux supports a greater variety of oddball PC devices such as parallel port scanners and the likes; it also supports a greater variety of file systems than the *BSDs.
FreeBSD "runs best" on IA-32 systems. If you want to use some non-IA-32 CPU, FreeBSD is not likely the preferred option. There are efforts underway for ports to Alpha , SPARC, Itanium, and AMD64 architectures, but IA-32 is still the primary platform of interest.
On the other hand, FreeBSD is one of the platforms supporting Wine (Windows Emulator) efforts, which require an x86 CPU, and DOSemu .
As FreeBSD can make various assumptions about the platform's architecture, it is probably the easiest of all the Unix-like OSes to install. It seems to be a decent "drop-in" system on which to host a web server that can gracefully handle high variations in quantity of traffic; lots of web sites run Apache atop FreeBSD.
Linux uses the GPL (GNU Public License) ; the BSDs (aside from BSDI) use variants on the BSD License. The GPL requires that works derivative of GPLed works also be GPLed; in effect, enforcing the notion of "once free, always free." BSDL licenses allow BSDLed code to be turned into proprietary products.
There is much fissiparousness over which approach is more "right," and these discussions tend to get acrimonious and are generally fruitless.
For more "obscure" systems such as NSC 32032-based boxes, Vaxes, and other minicomputers no longer supported by their manufacturers, NetBSD is often the only choice for getting a system running, as NetBSD targetted easy portability as a primary goal right from the start. Network Computers from Oracle and Digital run NetBSD as the underlying OS kernel.
It is a little dangerous to tell what's up between the NetBSD and OpenBSD groups. The projects have very similar goals. OpenBSD claims that it "tracks NetBSD changes very closely," and the web page claims that they have fixed many problems "which NetBSD has not yet fixed."
Indications are that OpenBSD was "founded" to deal with perceived security problems in NetBSD. Hearsay suggests that the NetBSD "core team" was willing to receive the patches, but was unhappy with having Theo De Raadt on the core team. And so OpenBSD was "born."
The main available set of public documentation on this has been [ The "Theo de Raadt Story"] describing " Why OpenBSD was Started." It is an archive of the flurry of email between Theo and (largely) NetBSD folks concerning the ending of his involvement with NetBSD. It's a bit one-sided, in that it involves only the email that he archived of what he sent or received; it demonstrates that there is some "political complexity" to running any sort of sizable project, as well as the notion that personality is important. There are some people that may be quite competent at writing code, but whom you'd never want to work with. Theo De Raadt is one person with a sometimes-abrasive personality, but it is worth noting that he wasn't alone. It seems there were multiple people with abrasive personalities associated with NetBSD; the combination was sufficiently explosive to make it impossible for them all to work on the same core OS.
There are features in the *BSD systems not presently available in Linux and vice-versa, which can be the "selling features" to swing people one way or the other.
NetBSD and OpenBSD support more "old" platforms than Linux likely ever will
... Which is true, but Linux has grown to support more newer "embedded" platforms...
Linux supports a greater variety of PC hardware than the BSDs
Many of the more obscure bits being shoddy stuff of dubious stability, so it's sometimes a bit of a wash!
But sometimes the differences matter. We briefly considered FreeBSD for some AMD64-based database servers. Unfortunately, we ran into both perceived and real problems with hardware support:
We couldn't get the fibrechannel controllers we had to work in 64 bit mode
Our disk array vendor, EMC, was prepared to "officially" support some Linux distributions; they haven't (yet?) got equivalent support for FreeBSD.
Not only was there the political challenge of a lack of support; disk array access didn't work. Of course, what was a problem in late 2004 may no longer be an issue come 2008.
BSD 4.4-Lite provides both a log-structured file system and a memory-mapped file system, both of which can help enhance performance over the Linux offerings. There's work on similar functionality for Linux, so that this difference may no longer be important in another year.
There have been heated debates on whether ext2 or BSD-FFS are superior in the way they handle metadata updates.
The development of the Berkeley FFS has been quite directly based on the body of theoretical research on the development of Unix file systems. The development of Linux has taken place in a more pragmatic fashion, and is not so well grounded from a theoretical perspective. As such, the update semantics of FFS are likely superior to those used in the Linux ext2 file system.
Some opinions expressed have been strong, and have done little to resolve differences. For systems that do not require "many 9s" up-times, there seems to be little practical difference. FFS and ext2 have both proved robust enough for many peoples' purposes. And development of new Linux filesystems appears to entered something of a renaissance, with a number of projects relating to journalled filesystems.
There seems to be more support for "system emulations" (e.g. Wine, IBCS2, Executor) under Linux, although FreeBSD comes close.
Linux supports a greater variety of external file systems (e.g. DOS FAT, VFAT, NTFS, HPFS, Amiga FS, and lots more)
To "what's the difference?" such answers as the following have been proposed. That they are not totally serious responses suggests that the question deserves disrespect...
FreeBSD installs tcsh as /bin/csh .
The others don't.
NetBSD runs on a Cobalt Qube2.
The others don't.
OpenBSD can encrypt swap.
The others don't.
As OpenBSD's "official home" is outside the United States, it has been unique amongst operating systems in that it can make use of strong cryptography throughout the system.
This comparison was written by a FreeBSD fan; it presents its claims and arguments very nicely.
The more severe disagreements tend to surround which license the disputant prefers to despise. Such disputes tend to go around in circles due to the arguers choosing to pick on the licenses for expressing differing "ethics" surrounding the sharing of software when what they probably should be picking on is the ethics themselves.
Less important differences between Linux and *BSD...
"Linux" has five letters compared to the 7 in "FreeBSD," 6 in "NetBSD," and 7 in "OpenBSD." Presumably that makes NetBSD either 20% better or 20% worse, and OpenBSD and FreeBSD 40% better/worse.
The really notable things about FreeBSD relate to the ability to do a make world whereby you compile, locally, the entire source code for the base operating system and utilities, as well as using the Ports collection whereby to build and install (say) The clisp Common Lisp implementation, you might use the command: cd /usr/ports/lang/clisp ; make install .
Interim results are all visible locally; all of these installation aspects function via ordinary makefiles.
Ports and make world have become available on the other free BSD implementations, but the pioneering work was largely on FreeBSD.
FreeBSD: ...And one port to install them all!
On building "meta-packages" so that you request one package (your metapackage) which then pulls in all the other packages on which it is dependant (which are what you really want to install).