Myths about FreeBSD

Draft content for the FreeBSD Myths page

FreeBSD is good for servers, not for Desktops

FreeBSD has a full-featured sound subsystem, giving low-latency in-kernel mixing allowing multiple applications to play sound (with independent volume settings) with no configuration. The default install includes X.org and installing a desktop environment such as KDE or GNOME is as easy as selecting the metapackage for whichever you prefer.

If even this is too much effort, PC-BSD is a full-featured desktop system built on top of FreeBSD, with an easy-to-use installer and the option of commercial support.

FreeBSD Has a Closed Development Model

FreeBSD has over 400 developers around the world who have commit access to the repository. Many of these are willing to commit patches from third parties. If you want to get an idea of the number of patches that have been committed on behalf of other developers, then search for 'Submitted by' in the commit logs. At the time of writing, this is just under twenty thousand, or about ten percent of all commits. After having a few patches accepted, regular contributors are usually encouraged to apply for commit access.

There is no dictator for the FreeBSD project. Decisions are made by the people willing to do the work and, in the case of disputes, resolved by a group of developers that is elected every two years, with everyone that has committed any code in the preceding year being allowed to vote.

FreeBSD is Just OS X Without the Good Bits

This is as much a myth about OS X as about FreeBSD: that OS X is just FreeBSD with a pretty GUI. The two operating systems do share a lot of code, for example most userland utilities and the C library on OS X are derived from FreeBSD versions. Some of this code flow works in the other direction, for example FreeBSD 9.1 and later include a C++ stack and compiler that were originally developed for OS X, with major parts of the work done by Apple employees. Other parts are very different.

The XNU kernel used on OS X includes a few subsystems from (older versions of) FreeBSD, but is mostly an independent implementation. The similarities in the userland, however, make it much easier to port OS X code to FreeBSD than any other system. For example, both libdispatch (Grand Central Dispatch in Apple's marketing) and libc++ were written for OS X and worked on FreeBSD before any other OS.

FreeBSD Makes Me Compile Everything From Source

The FreeBSD ports collection is a very powerful way of installing software, allowing you to customise options for a variety of third-party programs and libraries. It is not, however, the only way of installing software on FreeBSD. You have always been able to install software from binary packages. The pkgng project has added a new package format and package management tool, providing a modern set of tools for binary package management.

You can install pkgng from the ports tree (ports-mgmt/pkg) on older versions of FreeBSD. It is included by default on FreeBSD 9.1 and newer.

FreeBSD is UNIX from the '90s (or '80s)

FreeBSD is a linear descendent of the original UNIX, via the Berkeley Software Distribution, but it has continued to evolve in that time. In the last few years, we've seen ZFS become production quality, support for 10Gb and 40Gb Ethernet, massive improvements in the sound subsystem, 802.11n support, and a host of other improvements.

That's not to say that FreeBSD has abandoned its UNIX roots. There are many reasons why UNIX became popular. These include a freely redistributable system that was easy to port to new platforms, a set of simple tools doing one thing well that were easy to use together, and a kernel that performed well on computers normal humans could afford. FreeBSD maintains these traditions.

All of the Good Bits of FreeBSD Come from Solaris

FreeBSD has imported two high-profile features from OpenSolaris: DTrace and ZFS. Both of these are now well supported by FreeBSD. ZFS, in particular, is the focus of a lot of attention from FreeBSD developers, including those employed by iXsystems, a company that supports FreeNAS development and sells commercial NAS devices based on FreeBSD. FreeBSD contributors also work closely with developers of Illumos, the open-source fork of Solaris, on improving both of these features.

In spite of the advantages of ZFS, it is still a relatively small part of the overall system. ZFS and DTrace, between them, account for under 4% of the code in the kernel, which is itself only about 10% of the code in the base system. If you consider that only 0.4% of FreeBSD is good, then this is true, but hopefully you don't.

FreeBSD Has No Drivers

This is a problem faced by all operating systems - even new versions of Windows. Most of the time, users don't care about the total number of drivers, only if drivers exist for their hardware. There are some omissions in terms of driver support, most notably AMD Radeon drivers, but FreeBSD supports a wide range of network cards (including an increasing number of 802.11n chipsets), most soundcards, and Intel and nVidia GPUs.

Device support is a constantly moving target because we can't tell hardware makers to just stop releasing new hardware for a few years while we catch up. New devices do take some time to support, although some manufacturers do provide drivers themselves, for example nVidia provide drivers for their GPUs, and Intel for their newest network and storage controllers. Other manufacturers provide significant help to FreeBSD driver writers, including Broadcom, JMicron, HP and Solarflare. If you find a device that isn't supported, please let the project know and also notify the manufacturer: the only thing that motivates hardware manufacturers to support any operating system is the knowledge that their customers want it.

After 4.x FreeBSD Went Downhill

The 4.x release series was very stable, and exactly the kind of release that the FreeBSD Project is proud to be associated with. Many users continued running it for years. The 5.x series happened during the transition to better multithreading support. This involved replacing the single lock around the kernel with a set of smaller locks used by individual subsystems. As you can imagine, this involved a lot of work that was very easy to get wrong. At the same time, 5.x also shipped with two threading implementations, further complicating matters. The first two releases in the 5.x series were marked 'developers only' but 5.2 was aimed at a broader audience and failed to live up to the expectations of the FreeBSD userbase. A number of large users stuck with 4.x or moved to different systems.

The 5.x series was a painful lesson for the project, but one that we have learned from. The 6.x series regained the stability of the 4.x release. 7.x regained the single-processor performance and during the 8.x series we saw a number of published benchmarks by third parties showing FreeBSD scaling better on multiprocessor systems than any other operating system tested.

All of these releases have come with other significant improvements, such as an improved sound subsystem, ZFS, DTrace, journaling UFS, and many others, but stability and performance remain key goals for the FreeBSD system.

FreeBSD Lacks Software

The FreeBSD ports collection currently contains over 23,500 pieces of software. It's difficult to compare this number with other package repositories because programs are split up differently (for example, the gcc port in FreeBSD installs programs and libraries that are split between 6-10 packages in Debian, depending on the version of gcc), but in general most things that you will want to run are there. The fact that the ports collection provides a certain relatively obscure piece of software that they need, while other systems don't, is a frequently cited reason for people choosing FreeBSD.

Most of the software in the ports collection runs natively on FreeBSD. Most open source software is relatively OS-agnostic and requires little or no modification to compile and run on FreeBSD. There are exceptions, including things like valgrind that require a detailed understanding of the system that they are running on, but these are relatively rare and are usually ported if there is sufficient interest. Proprietary software can be more of a problem. Some vendors, such as Opera, provide FreeBSD versions of their code. If freely distributable, these are usually available from the ports collection.

Other software must run in some kind of emulation. For example, Linux binaries can run in the Linux ABI layer, where Linux system calls are translated into their FreeBSD equivalents. The only overhead of this is a slightly increased cost of system calls and it is usually difficult to measure a performance difference between running Linux programs on Linux and FreeBSD: in some cases programs have been reported running faster on FreeBSD than Linux due to more efficient implementations of the underlying calls. This is how, for example, the Linux version of the Flash plugin can run, using NSPluginWrapper in the Linux ABI layer, with a native web browser.

A similar solution exists for running Windows applications. The ports collection includes WINE, which is capable of running a lot of existing Windows applications.

FreeBSD Does Not Support Virtualisation

FreeBSD 9 supports running as a Xen guest (domU) on both x86 and x86-64, including Amazon EC2. Thanks to work done jointly by Microsoft, NetApp, and Citrix, it is also possible to run FreeBSD on Microsoft's Hyper-V hypervisor. Many versions of FreeBSD are also on the VMware Supported Guest Operating Systems list.

FreeBSD also supports VirtualBox, as both a host and a guest. You can find the VirtualBox guest additions and then hypervisor itself in the ports collection. FreeBSD 10 also acts as the host operating system for bhyve, the BSD Hypervisor, giving a variety of options for running FreeBSD VMs on top of FreeBSD.

Finally, if you don't require full virtualisation, you can use the jail subsystem to run isolated FreeBSD userlands (or even Linux userlands using the Linux ABI layer) on a single FreeBSD kernel. Jails can even be provided with their own independent network stack etc, and so a single machine can be used to emulate an entire machine room.

The BSD License Means Companies Don't Contribute Back

The BSD license means that you can take the code in FreeBSD and do whatever you want with it, as long as you don't sue us or pretend that you wrote it. Without the legal obligation to share code, it is possible to use FreeBSD code almost anywhere. Some companies, almost certainly, will take our code, modify it, and never give anything back. They are free to do this, however many don't.

Consider, for example, the case of two major Internet companies: Google and Yahoo! The former bases their internal infrastructure on a GPL'd operating system, while the latter uses FreeBSD. Because Google does not distribute their modified operating system, they can keep things like the GoogleFS private. In cases like this, where software is developed for in-house use, there are no differences in the requirement to share changes between the two licenses. There are, however, some issues with linking that mean that, for example, a GPL'd library can't be used where a BSD licensed one could be.

A lot of companies have made significant contributions to FreeBSD over the years. They don't (usually) do this out of a sense of altruism or as a result of legal threats, but out of the most dependable of motives: self interest. Maintaining a fork of any project, especially one that is developed as quickly as FreeBSD, is expensive. Pushing changes upstream is a lot cheaper. If there are changes that are useful to a wider community and not core to their own business interests, then it's cheaper to publish them and reduce the maintenance cost of the fork than to keep them private.

Myths (last edited 2013-02-18 10:46:34 by MichaelDexter)