FreeBSD Myths
Draft content for a page that was removed in October 2023. For posterity, in the Internet Archive Wayback Machine:
With the removal:
http://www.freebsd.org/advocacy/myths/ began redirecting to Education & Advocacy – FreeBSD Foundation.
Contents
-
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
- ZFS will use too much memory
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.
Technically: whilst FreeBSD does not include the package tool (pkg(8)), it does include pkg(7) to enable automated installation of the tool.
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 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 TrueNAS 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.
Despite 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
We have more than thirty thousand ports. It's difficult to compare this 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
With BSD-licensed code: you can largely do whatever you want, provided you don't sue or pretend that you wrote it. Without the legal obligation to share code, it is possible to use FreeBSD code almost anywhere. Some organisations will modify code, but never share the modifications.
Without obligation: many organisations do prefer to share.
Consider 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.
Many organisations have made significant contributions to FreeBSD. 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.
ZFS will use too much memory
Generally – where memory is fast: use of memory is a good thing. Unused (free) memory can be thought of as wasteful.
ZFS and FreeBSD combine to make good use of memory. This goodness includes releasing, when appropriate. Simplified:
- first, an amount of memory put to good use with ZFS
- then, a memory-hungry application wants some of that amount
- the application gets what it wants.
If you want less put to good use with ZFS, from the outset, you can tune things. Keyword:
- ARC
– a type of cache.
vfs.zfs.arc_free_target
This determines the amount of real memory that should be kept free. When the system finds less free than there should be:
- data is evicted from ARC.
System page size, not byte size. So, for example:
1 = 4,096 bytes to be kept free
256000 = 1.049 GB to be kept free.
vfs.zfs.arc.sys_free
In OpenZFS documentation: zfs_arc_sys_free
- … the target number of bytes the ARC should leave as free memory on the system. Defaults to the larger of 1/64 of physical memory or 512K. Setting this option to a non-zero value will override the default. …
With OpenZFS in FreeBSD: the sysctl variable is vfs.zfs.arc.sys_free.
From a September 2021 discussion in Discord for FreeBSD:
… arc_free_target and arc.sys_free might need to be deduplicated a bit. sys_free is definitely nicer since it is in bytes, but it doesn't seem to actually work quite the same, needs some investigation
vfs.zfs.arc.max
In OpenZFS documentation: zfs_arc_max.
With OpenZFS in FreeBSD: the variable is vfs.zfs.arc.max.
Generally
Of the three sysctl variables mentioned above: vfs.zfs.arc.max might be the best known, however it is not necessarily the best approach, if the aim is to keep an amount free at all times.
Workload Tuning presents the Adaptive Replacement Cache (ARC) as the first basic concept.