Draft content for the FreeBSD Myths page
- FreeBSD Myths
- FreeBSD is only good for Servers, not Desktops
- FreeBSD Has a Closed Development Model
- FreeBSD is Just macOS Without the Good Bits
- FreeBSD Makes Me Compile Everything From Source
- FreeBSD is UNIX from the '90s (or '80s)
- All of the Good Bits of FreeBSD Come from Solaris
- FreeBSD Has No Drivers
- After 4.x FreeBSD Went Downhill
- FreeBSD Lacks Software
- FreeBSD Does Not Support Virtualisation
- The BSD License Means Companies Don't Contribute Back
FreeBSD is only good for Servers, not Desktops
FreeBSD doesn't just make installing a desktop easy and fast, FreeBSD makes many desktop environments available for users to choose from, straight from our official ports and binary package systems. From KDE, Gnome, Cinnamon, MATE and XFCE desktop environments through LXQt, Lumina, CDE, LXDE and many many more, FreeBSD is all about options, choice and flexibility for users when it comes to graphical and GUI based environments. These are all provided by multiple and dedicated Desktop packaging teams that work together to improve FreeBSD for the desktop.
Want something desktop ready out of the box, or not yet ready to make your own desktop pizza?
FreeBSD has a growing ecosystem of dedicated desktop distribution efforts tailored and focused on the desktop experience. You'll want to check out GhostBSD, MidnightBSD, NomadBSD (run this off a USB key on any system) and helloSystem that provide fully-featured desktops, apps and other quality of life integrations, and come with super easy installers.
Beyond that, FreeBSD has a full-featured sound subsystem, providing low-latency in-kernel mixing allowing multiple applications to play audio with independent volume settings, supports Wayland, provides actively maintained graphics drivers for AMD, Intel and Nvidia GPU's, and has over 40,000 ports and binary packages available covering almost everything desktop users need and want.
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 macOS Without the Good Bits
This is as much a myth about macOS as about FreeBSD; that macOS 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 macOS 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 macOS, with major parts of the work done by Apple employees. Other parts are very different.
Darwin - which consists of the XNU kernel, IOkit (a driver model), and POSIX compatibility via a BSD compatibility layer - makes up part of macOS (as well as iOS, tvOS, and others) includes a few subsystems (such as the VFS, process model, and network implementation) from (older versions of) FreeBSD, but is mostly an independent implementation. The similarities in the userland, however, make it much easier to port macOS code to FreeBSD than any other system - partially because a lot of command-line utilities were imported along with the BSD bits from FreeBSD. For example, both libdispatch (Grand Central Dispatch in Apple's marketing) and libc++ were written for macOS 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 in all supported FreeBSD versions.
FreeBSD is UNIX from the '90s (or '80s)
FreeBSD is a direct 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, 40Gb and 100Gb 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 missions in terms of driver support, but FreeBSD supports a wide range of network cards (including an increasing number of 802.11n chipsets), most sound cards, and AMD, 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, even though some manufacturers provide drivers themselves, like nVidia 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, Mellanox, Chelsio and Solarflare. If you find a device that isn't supported, please let the project know and notify the manufacturer: the only thing that motivates hardware manufacturers to support any operating system is knowing 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 user base. 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 46,000 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.
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. FreeBSD 11 will include Dom0 Control Domain support. 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.