Briefly, FreeBSD is a UNIX® like operating system for the Alpha/AXP, AMD64 and Intel EM64T, i386™ IA-64, PC-98, and UltraSPARC® platforms based on U.C. Berkeley's ``4.4BSD-Lite'' release, with some ``4.4BSD-Lite2'' enhancements. It is also based indirectly on William Jolitz's port of U.C. Berkeley's ``Net/2'' to the i386, known as ``386BSD'', though very little of the 386BSD code remains. A fuller description of what FreeBSD is and how it can work for you may be found on the FreeBSD home page.

FreeBSD is used by companies, Internet Service Providers, researchers, computer professionals, students and home users all over the world in their work, education and recreation.

For more detailed information on FreeBSD, please see the FreeBSD Handbook.

The goal of the FreeBSD Project is to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we definitely do not insist on it. We believe that our first and foremost ``mission'' is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, we believe, one of the most fundamental goals of Free Software and one that we enthusiastically support.

That code in our source tree which falls under the GNU General Public License (GPL) or GNU Library General Public License (LGPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed FreeBSD license whenever possible.

Yes. Those restrictions do not control how you use the code, merely how you treat the FreeBSD Project itself. If you have serious license concerns, read the actual license. For the simply curious, the license can be summarized like this.

• Do not claim that you wrote this.

• Do not sue us if it breaks.

For most people, yes. But this question is not quite that cut-and-dried.

Most people do not actually use an operating system. They use applications. The applications are what really use the operating system. FreeBSD is designed to provide a robust and full-featured environment for applications. It supports a wide variety of web browsers, office suites, email readers, graphics programs, programming environments, network servers, and just about everything else you might want. Most of these applications can be managed through the Ports Collection.

If you need to use an application that is only available on one operating system, you simply cannot replace that operating system. Chances are there is a very similar application on FreeBSD, however. If you want a solid office or Internet server, a reliable workstation, or just the ability to do your job without interruptions, FreeBSD will almost certainly do everything you need. Many computer users across the world, including both novices and experienced UNIX administrators, use FreeBSD as their only desktop operating system.

If you are migrating to FreeBSD from some other UNIX environment, you already know most of what you need to. If your background is in graphic-driven operating systems such as Windows® and older versions of Mac OS®, expect to invest additional time learning the UNIX way of doing things. This FAQ and the FreeBSD Handbook are excellent places to start.

• It may be used free of charge, even by commercial users.

• Full source for the operating system is freely available, and the minimum possible restrictions have been placed upon its use, distribution and incorporation into other work (commercial or non-commercial).

• Anyone who has an improvement or bug fix is free to submit their code and have it added to the source tree (subject to one or two obvious provisions).

• It is worth pointing out that the word ``free'' is being used in two ways here, one meaning ``at no cost'', the other meaning ``you can do whatever you like''. Apart from one or two things you cannot do with the FreeBSD code, for example pretending you wrote it, you can really do whatever you like with it.

James Howard wrote a good explanation of the history and differences between the various projects for DaemonNews, called The BSD Family Tree which goes a fair way to answering this question.

At this point in FreeBSD's development, there are three parallel development branches; releases are being made from two of the three branches. The 4.X series of releases is being made from the 4-STABLE branch and the 5.X series of releases is being made from 5-STABLE. It will be some time in mid-to-late 2005 before the first release will be made from the 6-CURRENT branch; that release (6.0) will be aimed at early adopters.

Up until the release of 5.3, the 4.X series was the one known as -STABLE. However, as of 5.3, 5.X has been designated the new -STABLE and 4.X will no longer see much new development. Instead, it will be designated for an "extended support" status and receive only fixes for major problems (such as security-related fixes.)

Version 5.3 is the latest release from the 5-STABLE branch; it was released in November 2004. Version 4.10 is the latest release from the 4-STABLE branch; it was released in May 2004.

Briefly, -STABLE is aimed at the ISP, corporate user, or any user who wants stability and a minimal number of changes compared to the new (and possibly unstable) features of the latest -CURRENT snapshot. Releases can come from either branch, but -CURRENT should only be used if you are prepared for its increased volatility (relative to -STABLE, that is).

Releases are made every few months. While many people stay more up-to-date with the FreeBSD sources (see the questions on FreeBSD-CURRENT and FreeBSD-STABLE) than that, doing so is more of a commitment, as the sources are a moving target.

More information on FreeBSD releases can be found on the Release Engineering page on the FreeBSD Web site.

FreeBSD-CURRENT is the development version of the operating system, which will in due course become the new FreeBSD-STABLE branch. As such, it is really only of interest to developers working on the system and die-hard hobbyists. See the relevant section in the handbook for details on running -CURRENT.

If you are not familiar with the operating system or are not capable of identifying the difference between a real problem and a temporary problem, you should not use FreeBSD-CURRENT. This branch sometimes evolves quite quickly and can be un-buildable for a number of days at a time. People that use FreeBSD-CURRENT are expected to be able to analyze any problems and only report them if they are deemed to be mistakes rather than ``glitches''. Questions such as ``make world produces some error about groups'' on the -CURRENT mailing list may be treated with contempt.

Every day, snapshot releases are made based on the current state of the -CURRENT and -STABLE branches. Distributions of the occasional snapshot are made available. The goals behind each snapshot release are:

• To test the latest version of the installation software.

• To give people who would like to run -CURRENT or -STABLE but who do not have the time or bandwidth to follow it on a day-to-day basis an easy way of bootstrapping it onto their systems.

• To preserve a fixed reference point for the code in question, just in case we break something really badly later. (Although CVS normally prevents anything horrible like this happening :)

• To ensure that all new features and fixes in need of testing have the greatest possible number of potential testers.

No claims are made that any -CURRENT snapshot can be considered ``production quality'' for any purpose. If you want to run a stable and fully tested system, you will have to stick to full releases, or use the -STABLE snapshots.

Snapshot releases are directly available from ftp://current.FreeBSD.org/pub/FreeBSD/snapshots/.

Snapshots are generated, on the average, daily for all actively developed branches.

Back when FreeBSD 2.0.5 was released, FreeBSD development branched in two. One branch was named -STABLE, one -CURRENT. FreeBSD-STABLE is intended for Internet Service Providers and other commercial enterprises for whom sudden shifts or experimental features are quite undesirable. It receives only well-tested bug fixes and other small incremental enhancements. FreeBSD-CURRENT, on the other hand, has been one unbroken line since 2.0 was released, leading towards 5.3-RELEASE (and beyond). Just before 5.3-RELEASE, the 5-STABLE branch was created, and FreeBSD-CURRENT became 6-CURRENT. For more detailed information, see `` FreeBSD Release Engineering: Creating the Release Branch''.

The 2.2-STABLE branch was retired with the release of 2.2.8. The 3-STABLE branch has ended with the release of 3.5.1, the final 3.X release. The only changes made to either of these branches will be, for the most part, security-related bug fixes. Support for the 4-STABLE branch will continue for some time but focus primarily on security-related bug fixes and other serious issues.

5-STABLE is the actively developed -STABLE branch. The latest release on the 5-STABLE branch is 5.3-RELEASE, which was released in November 2004.

The 6-CURRENT branch is the actively developed -CURRENT branch toward the next generation of FreeBSD. See What is FreeBSD-CURRENT? for more information on this branch.

The Release Engineering Team <re@FreeBSD.org> releases a new version of FreeBSD about every four months, on average. Release dates are announced well in advance, so that the people working on the system know when their projects need to be finished and tested. A testing period precedes each release, in order to ensure that the addition of new features does not compromise the stability of the release. Many users regard this caution as one of the best things about FreeBSD, even though waiting for all the latest goodies to reach -STABLE can be a little frustrating.

More information on the release engineering process (including a schedule of upcoming releases) can be found on the release engineering pages on the FreeBSD Web site.

For people who need or want a little more excitement, binary snapshots are made daily as discussed above.

The key decisions concerning the FreeBSD project, such as the overall direction of the project and who is allowed to add code to the source tree, are made by a core team of 9 people. There is a much larger team of more than 300 committers who are authorized to make changes directly to the FreeBSD source tree.

However, most non-trivial changes are discussed in advance in the mailing lists, and there are no restrictions on who may take part in the discussion.

Every significant release of FreeBSD is available via anonymous FTP from the FreeBSD FTP site:

• The latest release, 5.3-RELEASE can be found in the 5.3-RELEASE directory.

• Snapshot releases are made daily for the -CURRENT branch, these being of service purely to bleeding-edge testers and developers.

• The latest 5-STABLE release, 4.10-RELEASE can be found in the 4.10-RELEASE directory.

• 5.X snapshots are usually made daily.

Information about obtaining FreeBSD on CD, DVD, and other media can be found in the Handbook.

The Problem Report database of all user change requests may be queried by using our web-based PR query interface. The send-pr(1) command can be used to submit problem reports and change requests via electronic mail.

The web-based problem report submission interface is currently disabled due to persistent abuse.

Before submitting a problem report, please read Writing FreeBSD Problem Reports, an article on how to write good problem reports.

Please check the Documentation list on the main FreeBSD web site.

The project produces a wide range of documentation, available online from this link: http://www.FreeBSD.org/docs.html. The same documents are available as packages, that you can easily install on your FreeBSD system. More details on documentation packages can be found in the next paragraphs.

In addition, the Bibliography at the end of this FAQ, and the one in the Handbook reference other recommended books.

Yes. The documentation is available in a number of different formats and compression schemes on the FreeBSD FTP site, in the /pub/FreeBSD/doc/ directory.

The documentation is categorized in a number of different ways. These include:

• The document's name, such as faq, or handbook.

• The document's language and encoding. These are based on the locale names you will find under /usr/share/locale on your FreeBSD system. The current languages and encodings that we have for documentation are as follows:

  Name	Meaning
  en_US.ISO8859-1	US English
  de_DE.ISO8859-1	German
  es_ES.ISO8859-1	Spanish
  fr_FR.ISO8859-1	French
  it_IT.ISO8859-15	Italian
  ja_JP.eucJP	Japanese (EUC encoding)
  ru_RU.KOI8-R	Russian (KOI8-R encoding)
  zh_TW.Big5	Chinese (Big5 encoding)

  Note: Some documents may not be available in all languages.

• The document's format. We produce the documentation in a number of different output formats. Each format has its own advantages and disadvantages. Some formats are better suited for online reading, while others are meant to be aesthetically pleasing when printed on paper. Having the documentation available in any of these formats ensures that our readers will be able to read the parts they are interested in, either on their monitor, or on paper after printing the documents. The currently available formats are:

  Format	Meaning
  html-split	A collection of small, linked, HTML files.
  html	One large HTML file containing the entire document
  pdb	Palm Pilot database format, for use with the iSilo reader.
  pdf	Adobe's Portable Document Format
  ps	PostScript
  rtf	Microsoft's Rich Text Format[a]
  txt	Plain text
  Notes: a. Page numbers are not automatically updated when loading this format into Word. Press CTRL+A, CTRL+END, F9 after loading the document, to update the page numbers.

• The compression and packaging scheme. There are three of these currently in use.

  1. Where the format is html-split, the files are bundled up using tar(1). The resulting .tar file is then compressed using the compression schemes detailed in the next point.

  2. All the other formats generate one file, called book.format (i.e., book.pdb, book.html, and so on).

     These files are then compressed using two compression schemes.

     Scheme	Description
     zip	The Zip format. If you want to uncompress this on FreeBSD you will need to install the archivers/unzip port first.
     bz2	The BZip2 format. Less widespread than Zip, but generally gives smaller files. Install the archivers/bzip2 port to uncompress these files.

     So the PostScript version of the Handbook, compressed using BZip2 will be stored in a file called book.ps.bz2 in the handbook/ directory.

After choosing the format and compression mechanism that you want to download, you must then decide whether or not you want to download the document as a FreeBSD package.

The advantage of downloading and installing the package is that the documentation can then be managed using the normal FreeBSD package management comments, such as pkg_add(1) and pkg_delete(1).

If you decide to download and install the package then you must know the filename to download. The documentation-as-packages files are stored in a directory called packages. Each package file looks like document-name.lang.encoding.format.tgz.

For example, the FAQ, in English, formatted as PDF, is in the package called faq.en_US.ISO8859-1.pdf.tgz.

Knowing this, you can use the following command to install the English PDF FAQ package.

# pkg_add ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/packages/faq.en_US.ISO8859-1.pdf.tgz

Having done that, you can use pkg_info(1) to determine where the file has been installed.

# pkg_info -f faq.en_US.ISO8859-1.pdf
Information for faq.en_US.ISO8859-1.pdf:

Packing list:
        Package name: faq.en_US.ISO8859-1.pdf
        CWD to /usr/share/doc/en_US.ISO8859-1/books/faq
File: book.pdf
        CWD to .
File: +COMMENT (ignored)
File: +DESC (ignored)

As you can see, book.pdf will have been installed into /usr/share/doc/en_US.ISO8859-1/books/faq.

If you do not want to use the packages then you will have to download the compressed files yourself, uncompress them, and then copy the appropriate documents into place.

For example, the split HTML version of the FAQ, compressed using bzip2(1), can be found in the doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 file. To download and uncompress that file you would have to do this.

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2
# bzip2 -d book.html-split.tar.bz2
# tar xvf book.html-split.tar

You will be left with a collection of .html files. The main one is called index.html, which will contain the table of contents, introductory material, and links to the other parts of the document. You can then copy or move these to their final location as necessary.

You can find full information in the Handbook entry on mailing-lists.

You can find full information in the Handbook entry on newsgroups.

Yes, most major IRC networks host a FreeBSD chat channel:

• Channel #FreeBSD on EFNet is a FreeBSD forum, but do not go there for tech support or try to get folks there to help you avoid the pain of reading manual pages or doing your own research. It is a chat channel, first and foremost, and topics there are just as likely to involve sex, sports or nuclear weapons as they are FreeBSD. You Have Been Warned! Available at server irc.chat.org.

• Channel #FreeBSDhelp on EFNet is a channel dedicated to helping FreeBSD users. They are much more sympathetic to questions than #FreeBSD is.

• Channel #FreeBSD on DALNET is available at irc.dal.net in the US and irc.eu.dal.net in Europe.

• Channel #FreeBSD on UNDERNET is available at us.undernet.org in the US and eu.undernet.org in Europe. Since it is a help channel, be prepared to read the documents you are referred to.

• Channel #FreeBSD on HybNet. This channel is a help channel. A list of servers can be found on the HybNet web site.

Each of these channels are distinct and are not connected to each other. Their chat styles also differ, so you may need to try each to find one suited to your chat style. As with all types of IRC traffic, if you are easily offended or cannot deal with lots of young people (and more than a few older ones) doing the verbal equivalent of jello wrestling, do not even bother with it.

DaemonNews provides commercial training and support for FreeBSD. More information can be found at their BSD Mall site.

FreeBSD Services Ltd provide commercial support for FreeBSD in the UK (as well as selling FreeBSD on DVD). See their web site for more information.

The FreeBSD Mall provides commercial FreeBSD support. You can get more information at their web site.

Any other organizations providing training and support should contact the project in order to be listed here.

Full instructions on this procedure and a little bit more about installation issues in general can be found in the Handbook entry on installing FreeBSD.

Installation instructions can be found in the Handbook entry on installing FreeBSD.

See also Chapter 4.

Have a look at the multi-OS page.

In general, no. However, we would strongly recommend that you install, at a minimum, the base source kit, which includes several of the files mentioned here, and the sys (kernel) source kit, which includes sources for the kernel. There is nothing in the system which requires the presence of the sources to operate, however, except for the kernel-configuration program config(8). With the exception of the kernel sources, our build structure is set up so that you can read-only mount the sources from elsewhere via NFS and still be able to make new binaries (due to the kernel-source restriction, we recommend that you not mount this on /usr/src directly, but rather in some other location with appropriate symbolic links to duplicate the top-level structure of the source tree).

Having the sources on-line and knowing how to build a system with them will make it much easier for you to upgrade to future releases of FreeBSD.

To actually select a subset of the sources, use the Custom menu item when you are in the Distributions menu of the system installation tool.

Building a new kernel was originally pretty much a required step in a FreeBSD installation, but more recent releases have benefited from the introduction of much friendlier kernel configuration methods. In 4.X and earlier, when at the FreeBSD boot prompt (boot:), use the -c flag and you will be dropped into a visual configuration screen which allows you to configure the kernel's settings for most common ISA cards. In FreeBSD 5.X and later this has been replaced by much more flexible "hints" which can be set from the loader prompt.

It may still be worthwhile building a new kernel containing just the drivers that you need, just to save a bit of RAM, but it is no longer necessary for most systems.

For complete details see the kernel config section of the Handbook.

Please take a look at the ports page for info on software packages ported to FreeBSD. The list currently tops 11,800 and is growing daily, so come back to check often or subscribe to the freebsd-announce mailing list for periodic updates on new entries.

Most ports should work on the 4.X, 5.X, and 6.X branches. Each time a FreeBSD release is made, a snapshot of the ports tree at the time of release in also included in the ports/ directory.

We also support the concept of a ``package'', essentially no more than a compressed binary distribution with a little extra intelligence embedded in it for doing whatever custom installation work is required. A package can be installed and uninstalled again easily without having to know the gory details of which files it includes.

Use the package installation menu in /stand/sysinstall (under the post-configuration menu item) or invoke the pkg_add(1) command on the specific package files you are interested in installing. Package files can usually be identified by their .tgz or .tbz suffix and CDROM distribution people will have a packages/All directory on their CD which contains such files. They can also be downloaded over the net for various versions of FreeBSD at the following locations:

or your nearest local mirror site.

Note that all ports may not be available as packages since new ones are constantly being added. It is always a good idea to check back periodically to see which packages are available at the ftp.FreeBSD.org master site.

Yes. Please see http://www.FreeBSD.org/java/.

FreeBSD does not include a port upgrading tool, but it does have some tools to make the upgrade process somewhat easier. You can also install additional tools to simplify port handling.

The pkg_version(1) command can generate a script that will update installed ports to the latest version in the ports tree.

# pkg_version -c > /tmp/myscript

The output script must be edited by hand before you use it. Recent versions of pkg_version(1) force this by inserting an exit(1) at the beginning of the script.

You should save the output of the script, as it will note packages that depend on the one that has been updated. These may or may not need to be updated as well. The usual case where they need to be updated is that a shared library has changed version numbers, so the ports that used that library need to be rebuilt to use the new version.

If you have the disk space, you can use the portupgrade tool to automate all of this. portupgrade includes various tools to simplify package handling. It is available under sysutils/portupgrade. Since it is written in Ruby, portupgrade is an unlikely candidate for integration with the main FreeBSD tree. That should not stop anyone from using it, however.

If your system is up full time, the periodic(8) system can be used to generate a weekly list of ports that might need updating by setting weekly_status_pkg_enable="YES" in /etc/periodic.conf.

The X Window System is the most widely available windowing system capable of running on UNIX or UNIX like systems, including FreeBSD. The X.Org Foundation administers the X protocol standards. The current release of the specification is 11.6, so you will often see references shortened to X11R6 or even just X11.

Many implementations are available for different architectures and operating systems. For instance, an implementation of the server-side code is properly known as an X server.

Historically, the default implementation of X on FreeBSD has been XFree86™ which is maintained by The XFree86 Project, Inc. This software was installed by default on FreeBSD versions up until 4.10 and 5.2. Although Xorg itself maintained an implementation during that time period, it was basically only provided as a reference platform, as it had suffered greatly from bitrot over the years.

However, early in 2004, some XFree86 developers left that project over issues including the pace of code changes, future directions, and interpersonal conflicts, and are now contributing code directly to Xorg instead. At that time, Xorg updated its source tree to the last XFree86 release before its subsequent licensing change (XFree86 version 4.3.99.903), incorporated many changes that had previously been maintained separately, and has released that software as X11R6.7.0. A separate but related project, freedesktop.org (or fd.o for short), is working on rearchitecting the original XFree86 code to offload more work onto the graphics cards (with the goal of increased performance) and make it more modular (with the goal of increased maintainability, and thus faster releases as well as easier configuration). Xorg intends to incorporate the freedesktop.org changes in its future releases.

As of July 2004, in FreeBSD-CURRENT, XFree86 has been replaced with Xorg as the default implementation. The XFree86 ports (x11/XFree86-4 and subports) remain in the ports collection and are still the default for FreeBSD-STABLE.

The Xorg software is written to the same X11R6 specification that XFree86 is, so basic applications should work unchanged. A few lesser-used protocols have been deprecated (XIE, PEX, and lbxproxy), but in the first two cases, the FreeBSD port of XFree86 did not support them either.

The answer to this question is outside the scope of this FAQ. Note that there are voluminous postings in various mailing list archives on the Internet; please use your favorite search engine to investigate the history instead of asking this question on the FreeBSD mailing lists. It may even be the case that only the participants will ever know for certain.

The Xorg developers claim that their goal is to release more often and incorporate new features more quickly. If they are able to do so, this will be very attractive. Also, their software still uses the traditional X license, while XFree86 is now using their modified one.

See the Installing X FAQ at <blahblahblah>.

Yes, you can use emulators/doscmd, a DOS emulation program, available in the FreeBSD Ports Collection.

If doscmd will not suffice, the add-on utility emulators/pcemu emulates an 8088 and enough BIOS services to run many DOS text mode applications. It requires the X Window System.

See the Translation FAQ in the FreeBSD Documentation Project Primer.

The FreeBSD.org mail system implements some of the stricter Postfix checks on incoming mail and rejects mail that is either misconfigured or is potential spam. Your mail might bounce for one of the following reasons:

• The email is being sent from a known spam domain or IP block.

  The FreeBSD mail servers reject email from known spam sources. If you have service through a company or domain who generates or relays spam, please switch to a service provider who does not.

• The body of the email only contains HTML.

  Mail should be sent in plain text only. Please configure your mail user agent to send plain text.

• The mailer at FreeBSD.org cannot resolve the IP address of the connecting host back to a symbolic name.

  Working reverse DNS is a standard requirement for accepting mail from a host. Set up reverse DNS for your mail server's IP address. Many home services (DSL, cable, dialup, etc.) will not give you this option. In this case, relay your email through your service provider's mail server.

• The hostname given in the EHLO/HELO part of the SMTP exchange cannot be resolved to an IP address.

  A fully qualified, resolvable host name is necessary in this part of the SMTP dialogue before mail will be accepted. If you do not have a host name that is registered in the DNS, then you should use your service provider's mail server to relay your mail.

• Your message had a message ID ending with the string ``localhost''.

  Some mail user agents generate bad message IDs which will not be accepted. You will need to persuade your mail user agent to generate a valid message ID or else configure your mail transfer agent to rewrite them.

While FreeBSD does not provide open access to any of their servers, others do provide open access UNIX systems. The charge varies and limited services may be available.

Arbornet, Inc, also known as M-Net, has been providing open access to UNIX systems since 1983. Starting on an Altos running System III, the site switched to BSD/OS in 1991. In June of 2000, the site switched again to FreeBSD. M-Net can be accessed via telnet and SSH and provides basic access to the entire FreeBSD software suite. However, network access is limited to members and patrons who donate to the system, which is run as a non-profit organization. M-Net also provides an bulletin board system and interactive chat.

Grex provides a site very similar to M-Net including the same bulletin board and interactive chat software. However, the machine is a Sun™ 4M and is running SunOS™.

He does not have one, and is just called ``the BSD daemon''. If you insist upon using a name, call him ``beastie''. Note that ``beastie'' is pronounced ``BSD''.

You can learn more about the BSD daemon on his home page.

Perhaps. The BSD daemon is copyrighted by Marshall Kirk McKusick. You will want to check his Statement on the Use of the BSD Daemon Figure for detailed usage terms.

In summary, you are free to use the image in a tasteful manner, for personal use, so long as appropriate credit is given. If you want to use him commercially, you must contact Kirk McKusick. More details are available on the BSD Daemon's home page.

You will find eps and Xfig drawings under /usr/share/examples/BSD_daemon/.

MFC is an acronym for ``Merged From -CURRENT''. It is used in the CVS logs to denote when a change was migrated from the CURRENT to the STABLE branches.

It stands for something in a secret language that only members can know. It does not translate literally but it is ok to tell you that BSD's translation is something between, ``Formula-1 Racing Team'', ``Penguins are tasty snacks'', and ``We have a better sense of humor than Linux®''. :-)

Seriously, BSD is an acronym for ``Berkeley Software Distribution'', which is the name the Berkeley CSRG (Computer Systems Research Group) chose for their UNIX distribution way back when.

Principle of Least Astonishment. It means that as FreeBSD evolves, changes visible to the user should be kept as unsurprising as possible. For example, arbitrarily rearranging system startup variables in /etc/defaults/rc.conf violates POLA. Developers consider POLA when contemplating user-visible system changes.

A repo-copy (which is a short form of ``repository copy'') refers to the direct copying of files within the CVS repository.

Without a repo-copy, if a file needed to be copied or moved to another place in the repository, the committer would run cvs add to put the file in its new location, and then cvs rm on the old file if the old copy was being removed.

The disadvantage of this method is that the history (i.e. the entries in the CVS logs) of the file would not be copied to the new location. As the FreeBSD Project considers this history very useful, a repository copy is often used instead. This is a process where one of the repository meisters will copy the files directly within the repository, rather than using the cvs(1) program.

The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.

The longer and more complete answer is that after a very long argument about whether sleep(1) should take fractional second arguments, Poul-Henning Kamp <phk@FreeBSD.org> posted a long message entitled ``A bike shed (any colour will do) on greener grass...''. The appropriate portions of that message are quoted below.

Q. Has anyone done any temperature testing while running FreeBSD? I know Linux runs cooler than DOS, but have never seen a mention of FreeBSD. It seems to run really hot.

A. No, but we have done numerous taste tests on blindfolded volunteers who have also had 250 micrograms of LSD-25 administered beforehand. 35% of the volunteers said that FreeBSD tasted sort of orange, whereas Linux tasted like purple haze. Neither group mentioned any significant variances in temperature. We eventually had to throw the results of this survey out entirely anyway when we found that too many volunteers were wandering out of the room during the tests, thus skewing the results. We think most of the volunteers are at Apple now, working on their new ``scratch and sniff'' GUI. It is a funny old business we are in!

Seriously, both FreeBSD and Linux use the HLT (halt) instruction when the system is idle thus lowering its energy consumption and therefore the heat it generates. Also if you have APM (advanced power management) configured, then FreeBSD can also put the CPU into a low power mode.

Q. Is there anything ``odd'' that FreeBSD does when compiling the kernel which would cause the memory to make a scratchy sound? When compiling (and for a brief moment after recognizing the floppy drive upon startup, as well), a strange scratchy sound emanates from what appears to be the memory banks.

A. Yes! You will see frequent references to ``daemons'' in the BSD documentation, and what most people do not know is that this refers to genuine, non-corporeal entities that now possess your computer. The scratchy sound coming from your memory is actually high-pitched whispering exchanged among the daemons as they best decide how to deal with various system administration tasks.

If the noise gets to you, a good fdisk /mbr from DOS will get rid of them, but do not be surprised if they react adversely and try to stop you. In fact, if at any point during the exercise you hear the satanic voice of Bill Gates coming from the built-in speaker, take off running and do not ever look back! Freed from the counterbalancing influence of the BSD daemons, the twin demons of DOS and Windows are often able to re-assert total control over your machine to the eternal damnation of your soul. Now that you know, given a choice you would probably prefer to get used to the scratchy noises, no?

One thousand, one hundred and sixty-nine:

Twenty-three to complain to -CURRENT about the lights being out;

Four to claim that it is a configuration problem, and that such matters really belong on -questions;

Three to submit PRs about it, one of which is misfiled under doc and consists only of ``it's dark'';

One to commit an untested lightbulb which breaks buildworld, then back it out five minutes later;

Eight to flame the PR originators for not including patches in their PRs;

Five to complain about buildworld being broken;

Thirty-one to answer that it works for them, and they must have cvsupped at a bad time;

One to post a patch for a new lightbulb to -hackers;

One to complain that he had patches for this three years ago, but when he sent them to -CURRENT they were just ignored, and he has had bad experiences with the PR system; besides, the proposed new lightbulb is non-reflexive;

Thirty-seven to scream that lightbulbs do not belong in the base system, that committers have no right to do things like this without consulting the Community, and WHAT IS -CORE DOING ABOUT IT!?

Two hundred to complain about the color of the bicycle shed;

Three to point out that the patch breaks style(9);

Seventeen to complain that the proposed new lightbulb is under GPL;

Five hundred and eighty-six to engage in a flame war about the comparative advantages of the GPL, the BSD license, the MIT license, the NPL, and the personal hygiene of unnamed FSF founders;

Seven to move various portions of the thread to -chat and -advocacy;

One to commit the suggested lightbulb, even though it shines dimmer than the old one;

Two to back it out with a furious flame of a commit message, arguing that FreeBSD is better off in the dark than with a dim lightbulb;

Forty-six to argue vociferously about the backing out of the dim lightbulb and demanding a statement from -core;

Eleven to request a smaller lightbulb so it will fit their Tamagotchi if we ever decide to port FreeBSD to that platform;

Seventy-three to complain about the SNR on -hackers and -chat and unsubscribe in protest;

Thirteen to post ``unsubscribe'', ``How do I unsubscribe?'', or ``Please remove me from the list'', followed by the usual footer;

One to commit a working lightbulb while everybody is too busy flaming everybody else to notice;

Thirty-one to point out that the new lightbulb would shine 0.364% brighter if compiled with TenDRA (although it will have to be reshaped into a cube), and that FreeBSD should therefore switch to TenDRA instead of GCC;

One to complain that the new lightbulb lacks fairings;

Nine (including the PR originators) to ask ``what is MFC?'';

Fifty-seven to complain about the lights being out two weeks after the bulb has been changed.

Nik Clayton <nik@FreeBSD.org> adds:

I was laughing quite hard at this.

And then I thought, ``Hang on, shouldn't there be '1 to document it.' in that list somewhere?''

And then I was enlightened :-)

It goes into a special data sink in the CPU where it is converted to heat which is vented through the heatsink / fan assembly. This is why CPU cooling is increasingly important; as people get used to faster processors, they become careless with their data and more and more of it ends up in /dev/null, overheating their CPUs. If you delete /dev/null (which effectively disables the CPU data sink) your CPU may run cooler but your system will quickly become constipated with all that excess data and start to behave erratically. If you have a fast network connection you can cool down your CPU by reading data out of /dev/random and sending it off somewhere; however you run the risk of overheating your network connection and / or angering your ISP, as most of the data will end up getting converted to heat by their equipment, but they generally have good cooling, so if you do not overdo it you should be OK.

Paul Robinson adds:

There are other methods. As every good sysadmin knows, it is part of standard practise to send data to the screen of interesting variety to keep all the pixies that make up your picture happy. Screen pixies (commonly mis-typed or re-named as ``pixels'' are categorised by the type of hat they wear (red, green or blue) and will hide or appear (thereby showing the colour of their hat) whenever they receive a little piece of food. Video cards turn data into pixie-food, and then send them to the pixies - the more expensive the card, the better the food, so the better behaved the pixies are. They also need constant stimulation - this is why screen savers exist.

To take your suggestions further, you could just throw the random data to console, thereby letting the pixies consume it. This causes no heat to be produced at all, keeps the pixies happy and gets rid of your data quite quickly, even if it does make things look a bit messy on your screen.

Incidentally, as an ex-admin of a large ISP who experienced many problems attempting to maintain a stable temperature in a server room, I would strongly discourage people sending the data they do not want out to the network. The fairies who do the packet switching and routing get annoyed by it as well.

At this time, there is only one book on FreeBSD-specific OS internals, namely ``The Design and Implementation of the FreeBSD Operating System'' by Marshall Kirk McKusick and George V. Neville-Neil, ISBN 0-201-70245-2, which focuses on version 5.X of FreeBSD.

Additionally, much general UNIX knowledge is directly applicable to FreeBSD.

For a list of relevant books, please check the Handbook's Operating System Internals Bibliography.

Please see the article on Contributing to FreeBSD for specific advice on how to do this. Assistance is more than welcome!

There are currently three active/semi-active branches in the FreeBSD CVS Repository. (Earlier branches are only changed very rarely, which is why there are only three active branches of development):

• RELENG_4 AKA 4-STABLE

• RELENG_5 AKA 5-STABLE

• HEAD AKA -CURRENT AKA 6.X-CURRENT

HEAD is not an actual branch tag, like the other two; it is simply a symbolic constant for ``the current, non-branched development stream'' which we simply refer to as ``-CURRENT''.

Right now, ``-CURRENT'' is the 6.X development stream; the 4-STABLE branch, RELENG_4, forked off from ``-CURRENT'' in March 2000, and the 5-STABLE branch, RELENG_5, forked off from ``-CURRENT'' in October 2004.

Please see the Release Engineering article.

Please see the article at <blahblahblah>.