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.|
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.
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.
The FreeBSD approach to third-party software focuses on the following:
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:
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.
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.
If you think it's better to have a more restricted license like the GPL, please see my GPL web page.
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).
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.
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.
Some of these will immediately raise a signal for those of you who tangled with older UNIX system that had these restructions.
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.
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.
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.