Abstract: |
FreeBSD is an OpenSource implementation of a complete UNIX-compatible operating system. It contains everything you need for a running system, including kernel, C libraries, commandline tools, installation program and a superb system to integrate and update third-party applications. This page gives an overview on some of the outstanding features. |
|---|---|
| Intended audience: | You know Windows is unusable and UNIX-like systems offer much more value for your invested time, but you feel you don't know enough about the differences between the available UNIX derivates. |
| Required knowledge: | Varies. Users already familar with UNIX will feel at home, although people new to UNIX won't feel locked out. |
FreeBSD is complete
FreeBSD isn't just an operating system kernel. It's a kernel, the C libraries and compiler, the usual commandline utilities and those network servers and clients needed for basic operations. In a word, you get everything you need for a running system out of one hand. You can always count on the integrity of these parts, they fit together.All parts are modified by one group and every group member has access to all parts. When a person makes in change in one part of the system, changes in other parts may also be required. If those other parts wouldn't be part of the same project, he/she would have to ask the maintainer of those packages to do the updates for him/her. This causes communication problems. When you get FreeBSD at one point in time, you can expect that changes in one part are synchronized in all other parts that required changes.
Serious concept for frequent updates
The integrety of the base system of FreeBSD also makes it easy to update it. If you want to follow the newest versions either of the "stable" or "development/current" branch, you don't have to update parts manually. If you are a power user who requires the newest system (and that means the whole base system) FreeBSD's way of recompiling itself is unmatched.The FreeBSD developers don't just make changes to the base system, they also take care that updates go smooth, that they don't break updates. This isn't perfect, but so far it's the closest I've seen. If you have a look into news or mailing lists archive how smooth the a.out to ELF object format change went for FreeBSD (an object file format change can cause major headaches for the users), you're just looking at the tip of the iceberg.
Serious concept for third-party software
As with the base system, a user might want to track the newest versions of his third-party packages.The FreeBSD approach to third-party software focuses on the following:
- Don't provide "black box" preconfigured software. Go as far as possible to build the software from its original state, so that the user can easily verify in what ways the software has been changed to be integrated into FreeBSD.
- Don't waste resources by duplicating source code distributions with slight changes. Instead, use the application's source code in its original form, surrounded by thin wrappers.
- Don't depend on the user to get the source "somewhere". Provide a standard way to automatically get it over the Internet or from CDROM if the user wants it. Do it in a way that all packages it depends on are fetched and built as well.
Imagine the following: You want one application that requires version 1.2 of a C library and another application that requires version 2.1. Obviously, you have to install the library with its include files, but which version? If you just install both one after another, the latter will overwrite parts of the first.
The usual approach is:
- install library version 1.2
- install application one
- remove library version 1.2
- install library version 2.1
- install application two
- Hope that you remember to reinstall 1.2 if you ever have to recompile application one.
This works and leaves both applications in usable state, since the reinstall of the library overwrites only parts that are needed at compile time, not (application) run time. But the drawback is that you can't recompile application one without overwriting the library with version 1.2 again.
The approach taken in the FreeBSD ports system is this: For every library where there are applications that require one version and other applications that require another and no common library can be found, install the library two times. But not to the same place, one of the version will be installed to a nonstandard place where applications don't seek for it unless explicitly told so. Usually, those version of the library that is considered to be in an unstable development ("cutting edge") state is chosen. Then, compile those applications that need the normal library as usual. And compile those applications that need the unusual library with special configuration so that it searches for the library in the nonstandard place.
Safe filesystem operations and softupdates
When the system suddenly, unexpectedly can't write out its data (power outage, broken harddisk, pilot error etc.), you will obviously lose data from files your applications just wrote to, due to the write buffering any modern operating system does.Now, that's only part of the story. Besides the data inside your files, there are also so-called "metadata" operations, i.e. creating, deleting and renaming files.
These operations are much more dangerous when they're interrupted. We're not just talking losing data from those files you just wrote, we're talking losing files you didn't even touch in last days! The "meta-data" operations can cause you to lose your whole filesystem (partition) or they can delete or truncate files that just happened to be "neighbors" of the files you wrote.
Hence, operating system usually apply different write buffer mechanisms for metadata than for normal data (the data your applications write into their files).
If you are too conservative (i.e. if you write out all metadata immediatly) the systems is very slow for some operations, for example unpacking files that have many files inside them (zip or tar files). All BSD-derived OSes and OSes with the BSD filesystem default to an almost- immediatly mode (called "synchronous"), which makes them very slow for those operations.
In Linux, metadata is written out as asynchronous/delays as normal is, which is the other extreme in the saveness/speed tradeoff.
To solve this dilemma, FreeBSD (since 3.x) offers "softupdates", which is an extension to the internal filesystem code that keeps track of metadata operations, sorts them and always writes metadata out in an order that guarantees that the filesystem may not be in a damageable state ever and that you will lose only data from files you actually modified during the interrupted session. And it is about as fast as asynchronous metadata operation, just needs more RAM.
Usable as a base for commercial products
The license of FreeBSD allows you to take base FreeBSD and its source, modify it and sell the result. It does not require you ship sources with your product. Some elements of FreeBSD come with more restricted license, especially the compiler (but not the libraries), some commandline utilities and the softupdates code. These parts are not required for a running system, and they are cleanly separated from the free sources.If you think it's better to have a more restricted license like the GPL, please see my GPL web page.
CAM-based SCSI layer and filesystem performance
Since version 3.x, FreeBSD's SCSI layer is based on the standard- It follows a standard API to access SCSI devices, one that is implemented on other platforms as well. That means that application developers don't have to write applications twice, they can move our sourcecode between all CAM-implementing operating systems. For the user, that means he/she will get applications earlier and they will contain less errors since the same version is used by much more people.
- It is also fast and great. In February 1999 I build a system with a 450 MHz 512KB cache Pentium II, an Asus P2B mainboard, two Adaptec U2W controllers and 4 IBM 10000 U/min 4MB cache harddisks. This system delivered 80 MioB/sec reading and 55 MioB/sec writing through the filesystem. This was after tuning with FreeBSD-specific knowledge.
- Even without tuning, just by plugging everything together and
creating filesystem like any user without special knowledge would, the
system delivered 42 MioB/sec writing and 62 MioB/sec reading.
I think that is just plain stunning. Remember that while these disks aren't exactly cheap, the whole system is just some random stuff from the PC part dealer at the next street corner and the price is laughable compared to commercial solutions that reach such throughput regions (usually RAID systems).
Memory subsystem
The virtual memory (VM) subsystem of FreeBSD is the result of a lot of work by some of their brightest developers, written to perform good under heavy load.Linux's VM code is only good when you have the "right" amount of RAM. If you don't have enough RAM for your workload, you suffer from its slow paging, caused by oversimplified data structures and searching algorithms in the VM code. If you have more RAM than you would need, the system doesn't slow down, but FreeBSD can make better use of the additional RAM. Linux still tries to optimize RAM usage in situations where it really isn't needed anymore.
The FreeBSD VM is targeted to withstand heavy load. Where heavy load doesn't have to be ninja-macho multiuser Internet server. It's also heavy memory load when you on your personal workstation put all those great graphical applications (X, KDE, GNOME, ghostscript) on your seriously underpowered PC with 16 or less MB RAM. In both cases, you gain from FreeBSD's optimized paging system.
The point here is not to design a good performing VM subsystem from scratch. You can't do that, it is always a tradeoff of sacrificing performance in one area for another. What you need to do is to watch a live system, under realistic load (most load simulations don't have much in common with reality) and find out the bottlenecks by actually verifying they're there. It is of no use just to look at the code and spot areas with inefficient code. Code that reaches only 50% of its maximum speed doesn't matter if it is called 100000 times less than some other piece with 98% efficiency.
FreeBSD's VM is nothing revolutionary, it's based on the old 4.4BSD/Mach code, but is has been watched and people eliminated bottlenecks based on the performance damage they cause in practice.
Existing big installations
FreeBSD is the operating system for the biggest single-machine ftp server in the world, ftp://wcarchive.cdrom.com/. Most other big sites aren't single machine, but collections of machines with some load balancing mechanism that redirect accesses.Now, what is the practical use of having such a big system as a reference?
It's bugs, software errors. Yes, we all think our software is more or less bug-free. But in reality, it works quite well when driven at load level the developer intended and tested for. If you push it to the limits, all kinds of problems show up. Especially timing problems, overlooked hard limits and improper synchronization of simultaneously updated data structures. It is a matter of fact that all software systems, commercial or free, written in C or a so-called memory-managing programming language, hit such limits when put on a unexpected big machine, with unexpected masses of simultaneous users and in the case of a network server thousands of simultaneous network connections. Having such a real-world loaded machine is a requirement to raise your level of scalability, and yes, if you are on the bleeding edge, you will bleed. Hopefully, your OS has already gone through it without you.
Other big FreeBSD sites include Yahoo, which isn't particularly small either.
FreeBSD removes some annoying limits
The FreeBSD developers are persons who use the system themself, they spend a major part of the time using it. This shows when people take great effort to remove some of the annoyances UNIX (and other OSes) had in the past.Some of these will immediately raise a signal for those of you who tangled with older UNIX system that had these restructions.
Examples:
umount -f. This doesn't sound like a big deal. You can force a filesystem to be unmounted no matter what happens, you can overwrite the protection that a filesystem should not be unmounted while it is in use. If you don't have this features, runaway processes may cause you not to be able to get rid of mounted filesystems. That's bad and can have any number of consequences, among them being unable to eject a removable medium like a CD or not to be able to remount the medium with different settings. In the end, this forces you to reboot the machine to resolve the situation.- The CAM-based SCSI layer can find new devices attached while the machine is running without reboot. It also survives removing "unremovable" mediums like disks (of course, it's the user's problem to write out the data to those disks before pulling it, but the FreeBSD system doesn't prevent you from doing so like other system do).
- I don't even start to compare the reboot frequency of FreeBSD with Windows. You can do all usual administrative operations in FreeBSD without reboot. Changing IP addresses, changes to routing, changing hostname, installing software. Exceptions are modifications of hardware drivers and some subsystems that have major parts implemented in the kernel. The latter problem is solved by running a kernel with all such features built in just in case. On modern machines with enough RAM that will rarely make a performance drop. Linux has the edge in hardware settings changes at runtime, though, since it makes much more use of loadable modules.
In some cases, Linux emulation can be better than native Linux
FreeBSD has a mode that allows you to run Linux applications on it. Don't be mislead by the word "emulation", this is neither slow or unusable like other OS emulations. The difference between the Linux emulation on FreeBSD and - say - Windows emulation on a Macintosh is that in the FreeBSD/Linux case the base OS is very similar and the emulation layer doesn't provide a full emulated system, but is a very thin layer to map the difference of the Linux and FreeBSD API. Since both are UNIX derivates, these differences are very small. No hardware emulation is required.As a result, almost all Linux applications run on FreeBSD. I don't give a list here, because it's a very moving target, you should see the FreeBSD Web pages for details. It should be noted that Linux compatibility includes the possibility to build Linux binaries on FreeBSD (so that you can use Linux packages that contain binary C libraries to be linked to your apps) and even things like 3dfx video card support.
The emulation layer is so thin that it doesn't have an inherited performance drop. The emulation layer just adds a few computations to every system call. A system call on a UNIX system is always a costly operation that requires several times the operations the biggest parts of the emulation layer take.
FreeBSD is faster in some areas than Linux, as said in maximum filesystem throughput, if your machine doesn't have enough RAM or if you have very much RAM. All these equally apply to FreeBSD and Linux programs, there is no different filesystem or memory subsystem in the emulator. If you don't believe this, it's time to get rid of that binary- hardcoded- hardware- addresses applications writer style from DOS and Mac times. UNIX binaries are forced to use the documented API and only only the documented API. That makes them easy to emulate and that prevents them from messing with anything that depends on one filesystem or memory structure. Linux probably has areas where it is faster as well, I don't say every application is faster on FreeBSD. But if your application need system resources that are faster on FreeBSD, there's nothing that prevents it from running faster.
Perhaps the biggest advantage of Linux emulation on FreeBSD compared to running on native Linux is that you can change the C libraries (and other libraries, of course) as you like without risking the operational integrity of your base system. The Linux emulation layer in FreeBSD has native Linux C libraries for Linux programs. These are completely separate from the C libraries the basic FreeBSD system uses. Hence, playing around with C libraries for you Linux programs can only affect Linux programs (which usually will not include any program required for operation or programs that may damage your system, since all your system management is native FreeBSD).
Thus, you can take just those C libraries the vendor of your application requires. Or you can experiment as you like and the maximum accident is that your Linux application doesn't run.
If you want to know what it means to experiment with you C libraries if the base system depends on them, go to http://www.dejanews.com/ and search for "libc5, libc6, glibc, glibc-2.1, fdisk, fsck, partition, damage" and similar topics. Of course, this is also a result of Linux being a kernel only.
Bootloader
The FreeBSD boot process can read the kernel to load from virtually everywhere, no matter where the bootloader was started from. I.e. the bootloader can be on a floppy and still load a kernel from a harddisk. And it doesn't have to be told which kernels it should prepare for, it can read the filesystem by itself.Other OSes either narrow down your possible choices which kernel to load or they force you to prepare your bootloader for the target kernels. This is an obvious problem if you already shut down the system and forgot to tell the bootloader about the new kernel location. FreeBSD's bootloader can search for itself.
The new bootloader in 3.x is also a remarkable piece of flexibility and configurability and still growing. If you like forth programming, have a look.