diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.sgml b/en_US.ISO8859-1/books/handbook/config/chapter.sgml
index 942146e4b7..97265cf92a 100644
--- a/en_US.ISO8859-1/books/handbook/config/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/config/chapter.sgml
@@ -1,1229 +1,1229 @@
ChernLeeWritten by MikeSmithBased on a tutorial written by MattDillonAlso based on tuning(7) written by Configuration and TuningSynopsissystem configuration/optimizationConfiguring a system correctly can substantially reduce the
amount of work involved in maintaining and upgrading it in the
future. This chapter describes some of the aspects of
administrative configuration of FreeBSD systems.This chapter will also describe some of the parameters that
can be set to tune a FreeBSD system for optimum
performance.After reading this chapter, you will know:Why and how to efficiently size, layout, and place
filesystems and swap partitions on your hard drive.The basics of the rc.conf configuration and
/usr/local/etc/rc.d startup systems.How to configure virtual hosts on your network devices.How to use the various configuration files in
/etc.How to tune FreeBSD using sysctl
variables.How to tune disk performance and modify kernel
limitations.Before reading this chapter, you should:Understand the basics of Unix and FreeBSD ().Be familiar with keeping FreeBSD sources up to date
(), and
the basics of kernel configuration/compilation
().Initial ConfigurationPartition LayoutPartition layout/etc/var/usrBase PartitionsWhen laying out your filesystem with &man.disklabel.8;
or &man.sysinstall.8;, it is important to remember that hard
drives can transfer data at a faster rate from the outer
tracks than the inner. Knowing this, you should place your
smaller, heavily-accessed filesystems, such as root and
swap, closer to the outside of the drive, while placing
larger partitions, such as /usr,
towards the inner. To do so, it is a good idea to create
partitions in a similar order: root, swap,
/var, /usr.The size of your /var partition
reflects the intended use of your machine.
/var is primarily used to hold
mailboxes, log files, and printer spools. Mailboxes and log
files, in particular, can grow to unexpected sizes based
upon how many users are on your system and how long your log
files are kept. If you intend to run a mail server, a
/var partition of over a gigabyte can
be suitable. Additionally, /var/tmp
must be large enough to contain any packages you may wish to
add.The /usr partition holds the bulk
of the files required to support the system and a
subdirectory within it called
/usr/local holds the bulk of the files
installed from the &man.ports.7; hierarchy. If you do not
use ports all that much and do not intend to keep system
source (/usr/src) on the machine, you
- can get away with a 1 gigabyte /usr
+ can get away with a 1 gigabyte /usr
partition. However, if you install a lot of ports
(especially window managers and Linux binaries), we
recommend at least a two gigabyte /usr
and if you also intend to keep system source on the machine,
we recommend a three gigabyte /usr. Do
not underestimate the amount of space you will need in this
partition, it can creep up and surprise you!When sizing your partitions, keep in mind the space
requirements for your system to grow. Running out of space in
one partition while having plenty in another can lead to much
frustration.Some users who have used &man.sysinstall.8;'s
Auto-defaults partition sizer have found
either their root or /var partitions too
small later on. Partition wisely and
generously.Swap Partitionswap sizingswap partitionAs a rule of thumb, your swap space should typically be
double the amount of main memory. For example, if the machine
- has 128 megabytes of memory, the swap file should be 256
- megabytes. Systems with lesser memory may perform better with
+ has 128 megabytes of memory, the swap file should be
+ 256 megabytes. Systems with lesser memory may perform better with
a lot more swap. It is not recommended that you configure any
- less than 256 megabytes of swap on a system and you should
+ less than 256 megabytes of swap on a system and you should
keep in mind future memory expansion when sizing the swap
partition. The kernel's VM paging algorithms are tuned to
perform best when the swap partition is at least two times the
size of main memory. Configuring too little swap can lead to
inefficiencies in the VM page scanning code as well as create
issues later on if you add more memory to your machine.Finally, on larger systems with multiple SCSI disks (or
multiple IDE disks operating on different controllers), it is
strongly recommend that you configure swap on each drive (up
to four drives). The swap partitions on the drives should be
approximately the same size. The kernel can handle arbitrary
sizes but internal data structures scale to 4 times the
largest swap partition. Keeping the swap partitions near the
same size will allow the kernel to optimally stripe swap space
across the disks. Do not worry about overdoing it a little,
swap space is the saving grace of Unix. Even if you do not
normally use much swap, it can give you more time to recover
from a runaway program before being forced to reboot.Why Partition? Why partition at all? Why not create one big root
partition and be done with it? Then I do not have to worry
about undersizing things!There are several reasons this is not a good idea.
First, each partition has different operational
characteristics and separating them allows the filesystem to
tune itself to those characteristics. For example, the root
and /usr partitions are read-mostly, with
very little writing, while a lot of reading and writing could
occur in /var and
/var/tmp.By properly partitioning your system, fragmentation
introduced in the smaller more heavily write-loaded partitions
will not bleed over into the mostly-read partitions.
Additionally, keeping the write-loaded partitions closer to
the edge of the disk, for example before the really big
partition instead of after in the partition table, will
increase I/O performance in the partitions where you need it
the most. Now it is true that you might also need I/O
performance in the larger partitions, but they are so large
that shifting them more towards the edge of the disk will not
lead to a significant performance improvement whereas moving
/var to the edge can have a huge impact.
Finally, there are safety concerns. Having a small, neat root
partition that is essentially read-only gives it a greater
chance of surviving a bad crash intact.Core Configurationrc filesrc.confThe principal location for system configuration information
is within /etc/rc.conf. This file
contains a wide range of configuration information, principally
used at system startup to configure the system. Its name
directly implies this; it is configuration information for the
rc* files.An administrator should make entries in the
rc.conf file to
override the default settings from
/etc/defaults/rc.conf. The defaults file
should not be copied verbatim to /etc - it
contains default values, not examples. All system-specific
changes should be made in the rc.conf
file itself.A number of strategies may be applied in clustered
applications to separate site-wide configuration from
system-specific configuration in order to keep administration
overhead down. The recommended approach is to place site-wide
configuration into another file,
such as /etc/rc.conf.site, and then include
this file into /etc/rc.conf, which will
contain only system-specific information.As rc.conf is read by &man.sh.1; it is
trivial to achieve this. For example:rc.conf: . rc.conf.site
hostname="node15.example.com"
network_interfaces="fxp0 lo0"
ifconfig_fxp0="inet 10.1.1.1"rc.conf.site: defaultrouter="10.1.1.254"
saver="daemon"
blanktime="100"The rc.conf.site file can then be
distributed to every system using rsync or a
similar program, while the rc.conf file
remains unique.Upgrading the system using &man.sysinstall.8;
or make world will not overwrite the
rc.conf
file, so system configuration information will not be lost.Application ConfigurationTypically, installed applications have their own
configuration files, with their own syntax, etc. It is
important that these files be kept separate from the base
system, so that they may be easily located and managed by the
package management tools./usr/local/etcTypically, these files are installed in
/usr/local/etc. In the case where an
application has a large number of configuration files, a
subdirectory will be created to hold them.Normally, when a port or package is installed, sample
configuration files are also installed. These are usually
identified with a .default suffix. If there
are no existing
configuration files for the application, they will be created by
copying the .default files.For example, consider the contents of the directory
/usr/local/etc/apache:-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf
-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default
-rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf
-rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default
-rw-r--r-- 1 root wheel 12205 May 20 1998 magic
-rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default
-rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types
-rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default
-rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf
-rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.defaultThe filesize difference shows that only the srm.conf
file has been changed. A later update of the Apache port would not
overwrite this changed file.Starting ServicesservicesIt is common for a system to host a number of services.
These may be started in several different fashions, each having
different advantages./usr/local/etc/rc.dSoftware installed from a port or the packages collection
will often place a script in
/usr/local/etc/rc.d which is invoked at
system startup with a argument, and at
system shutdown with a argument.
This is the recommended way for
starting system-wide services that are to be run as
root, or that
expect to be started as root.
These scripts are registered as
part of the installation of the package, and will be removed
when the package is removed.A generic startup script in
/usr/local/etc/rc.d looks like:#!/bin/sh
echo -n ' FooBar'
case "$1" in
start)
/usr/local/bin/foobar
;;
stop)
kill -9 `cat /var/run/foobar.pid`
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
exit 64
;;
esac
exit 0
The startup scripts of FreeBSD will look in
/usr/local/etc/rc.d for scripts that have an
.sh extension and are executable by
root. Those scripts that are found are called with
an option at startup, and
at shutdown to allow them to carry out their purpose. So if you wanted
the above sample script to be picked up and run at the proper time during
system startup, you should save it to a file called
FooBar.sh in
/usr/local/etc/rc.d and make sure it's
executable. You can make a shell script executable with &man.chmod.1;
as shown below:&prompt.root; chmod 755 FooBar.shSome services expect to be invoked by &man.inetd.8; when a
connection is received on a suitable port. This is common for
mail reader servers (POP and IMAP, etc.). These services are
enabled by editing the file /etc/inetd.conf.
See &man.inetd.8; for details on editing this file.Some additional system services may not be covered by the
toggles in /etc/rc.conf. These are
traditionally enabled by placing the command(s) to invoke them
- in /etc/rc.local. As of FreeBSD 3.1 there
+ in /etc/rc.local. As of FreeBSD 3.1 there
is no default /etc/rc.local; if it is
created by the administrator it will however be honored in the
normal fashion. Note that rc.local is
generally regarded as the location of last resort; if there is a
better place to start a service, do it there.Do not place any commands in
/etc/rc.conf. To start daemons, or
run any commands at boot time, place a script in
/usr/local/etc/rc.d instead.It is also possible to use the &man.cron.8; daemon to start
system services. This approach has a number of advantages, not
least being that because &man.cron.8; runs these processes as the
owner of the crontab, services may be started
and maintained by non-root users.This takes advantage of a feature of &man.cron.8;: the
time specification may be replaced by @reboot,
which will
cause the job to be run when &man.cron.8; is started shortly after
system boot.Virtual Hostsvirtual hostsip aliasesA very common use of FreeBSD is virtual site hosting, where
one server appears to the network as many servers. This is
achieved by assigning multiple network addresses to a single
interface.A given network interface has one real address,
and may have any number of alias addresses.
These aliases are
normally added by placing alias entries in
/etc/rc.conf.An alias entry for the interface fxp0
looks like:ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"Note that alias entries must start with alias0 and proceed
upwards in order, (for example, _alias1, _alias2, and so on).
The configuration process will stop at the first missing number.
The calculation of alias netmasks is important, but
fortunately quite simple. For a given interface, there must be
one address which correctly represents the network's netmask.
Any other addresses which fall within this network must have a
netmask of all 1's.For example, consider the case where the
fxp0 interface is
connected to two networks, the 10.1.1.0 network with a netmask
of 255.255.255.0 and the 202.0.75.16 network with a netmask of
255.255.255.240. We want the system to appear at 10.1.1.1
through 10.1.1.5 and at 202.0.75.17 through 202.0.75.20.The following entries configure the adapter correctly for
this arrangement: ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"
ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255"
ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255"
ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255"
ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240"
ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255"
ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255"
ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255"Configuration Files/etc LayoutThere are a number of directories in which configuration
information is kept. These include:/etcGeneric system configuration information; data here is
system-specific./etc/defaultsDefault versions of system configuration files./etc/mailExtra &man.sendmail.8; configuration, other
MTA configuration files.
/etc/pppConfiguration for both user- and kernel-ppp programs.
/etc/namedbDefault location for &man.named.8; data. Normally
named.conf and zone files are stored
here./usr/local/etcConfiguration files for installed applications.
May contain per-application subdirectories./usr/local/etc/rc.dStart/stop scripts for installed applications./var/dbAutomatically generated system-specific database files,
such as the package database, the locate database, and so
onHostnameshostnameDNS/etc/resolv.confresolv.conf/etc/resolv.conf dictates how FreeBSD's
resolver accesses the Internet Domain Name System (DNS).The most common entries to resolv.conf are:
nameserverThe IP address of a name server the resolver
should query. The servers are queried in the order
listed with a maximum of three.searchSearch list for hostname lookup. This is normally
determined by the domain of the local hostname.domainThe local domain name.A typical resolv.conf:search example.com
nameserver 147.11.1.11
nameserver 147.11.100.30Only one of the search and
domain options should be used.If you are using DHCP, &man.dhclient.8; usually rewrites
resolv.conf with information received from the
DHCP server./etc/hostshosts/etc/hosts is a simple text
database reminiscent of the old Internet. It works in
conjunction with DNS and NIS providing name to IP address
mappings. Local computers connected via a LAN can be placed
in here for simplistic naming purposes instead of setting up
a &man.named.8; server. Additionally,
/etc/hosts can be used to provide a
local record of Internet names, reducing the need to query
externally for commonly accessed names.# $FreeBSD$
#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# In the presence of the domain name service or NIS, this file may
# not be consulted at all; see /etc/nsswitch.conf for the resolution order.
#
#
::1 localhost localhost.my.domain myname.my.domain
127.0.0.1 localhost localhost.my.domain myname.my.domain
#
# Imaginary network.
#10.0.0.2 myname.my.domain myname
#10.0.0.3 myfriend.my.domain myfriend
#
# According to RFC 1918, you can use the following IP networks for
# private nets which will never be connected to the Internet:
#
# 10.0.0.0 - 10.255.255.255
# 172.16.0.0 - 172.31.255.255
# 192.168.0.0 - 192.168.255.255
#
# In case you want to be able to connect to the Internet, you need
# real official assigned numbers. PLEASE PLEASE PLEASE do not try
# to invent your own network numbers but instead get one from your
# network provider (if any) or from the Internet Registry (ftp to
# rs.internic.net, directory `/templates').
#/etc/hosts takes on the simple format
of:[Internet address] [official hostname] [alias1] [alias2] ...For example:10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2Consult &man.hosts.5; for more information.Log File Configurationlog filessyslog.confsyslog.confsyslog.conf is the configuration file
for the &man.syslogd.8; program. It indicates which types
of syslog messages are logged to particular
log files.# $FreeBSD$
#
# Spaces ARE valid field separators in this file. However,
# other *nix-like systems still insist on using tabs as field
# separators. If you are sharing this file between systems, you
# may want to use only tabs as field separators here.
# Consult the syslog.conf(5) manual page.
*.err;kern.debug;auth.notice;mail.crit /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.* /var/log/security
mail.info /var/log/maillog
lpr.info /var/log/lpd-errs
cron.* /var/log/cron
*.err root
*.notice;news.err root
*.alert root
*.emerg *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
#*.* /var/log/all.log
# uncomment this to enable logging to a remote log host named loghost
#*.* @loghost
# uncomment these if you're running inn
# news.crit /var/log/news/news.crit
# news.err /var/log/news/news.err
# news.notice /var/log/news/news.notice
!startslip
*.* /var/log/slip.log
!ppp
*.* /var/log/ppp.logConsult the &man.syslog.conf.5; manual page for more
information.newsyslog.confnewsyslog.confnewsyslog.conf is the configuration
file for &man.newsyslog.8;, a program that is normally scheduled
to run by &man.cron.8;. &man.newsyslog.8; determines when log
files require archiving or rearranging.
logfile is moved to
logfile.0, logfile.0
is moved to logfile.1, and so on.
Alternatively, the log files may be archived in &man.gzip.1; format
causing them to be named: logfile.0.gz,
logfile.1.gz, and so on.newsyslog.conf indicates which log
files are to be managed, how many are to be kept, and when
they are to be touched. Log files can be rearranged and/or
archived when they have either reached a certain size, or at a
certain periodic time/date.# configuration file for newsyslog
# $FreeBSD$
#
# filename [owner:group] mode count size when [ZB] [/pid_file] [sig_num]
/var/log/cron 600 3 100 * Z
/var/log/amd.log 644 7 100 * Z
/var/log/kerberos.log 644 7 100 * Z
/var/log/lpd-errs 644 7 100 * Z
/var/log/maillog 644 7 * @T00 Z
/var/log/sendmail.st 644 10 * 168 B
/var/log/messages 644 5 100 * Z
/var/log/all.log 600 7 * @T00 Z
/var/log/slip.log 600 3 100 * Z
/var/log/ppp.log 600 3 100 * Z
/var/log/security 600 10 100 * Z
/var/log/wtmp 644 3 * @01T05 B
/var/log/daily.log 640 7 * @T00 Z
/var/log/weekly.log 640 5 1 $W6D0 Z
/var/log/monthly.log 640 12 * $M1D0 Z
/var/log/console.log 640 5 100 * ZConsult the &man.newsyslog.8; manual page for more
information.sysctl.confsysctl.confsysctlsysctl.conf looks much like
rc.conf. Values are set in a
variable=value
form. The specified values are set after the system goes into
multi-user mode. Not all variables are settable in this mode.A sample sysctl.conf turning off logging
of fatal signal exits and letting Linux programs know they are really
running under FreeBSD:kern.logsigexit=0 # Do not log fatal signal exits (e.g. sig 11)
compat.linux.osname=FreeBSD
compat.linux.osrelease=4.3-STABLETuning with sysctlsysctlTuning with sysctl&man.sysctl.8; is an interface that allows you to make changes
to a running FreeBSD system. This includes many advanced
options of the TCP/IP stack and virtual memory system that can
dramatically improve performance for an experienced system
administrator. Over five hundred system variables can be read
and set using &man.sysctl.8;.At its core, &man.sysctl.8; serves two functions: to read and
to modify system settings.To view all readable variables:&prompt.user; sysctl -aTo read a particular variable, for example,
kern.maxproc:&prompt.user; sysctl kern.maxproc
kern.maxproc: 1044To set a particular variable, use the intuitive
variable=value
syntax:&prompt.root; sysctl kern.maxfiles=5000
kern.maxfiles: 2088 -> 5000Settings of sysctl variables are usually either strings,
numbers, or booleans (a boolean being 1 for yes
or a 0 for no).Tuning DisksSysctl Variablesvfs.vmiodirenablevfs.vmiodirenableThe vfs.vmiodirenable sysctl variable
may be set to either 0 (off) or 1 (on); it is 1 by default. This variable controls how
directories are cached by the system. Most directories are
- small, using just a single fragment (typically 1K) in the
- filesystem and less (typically 512 bytes) in the buffer
+ small, using just a single fragment (typically 1 K) in the
+ filesystem and less (typically 512 bytes) in the buffer
cache. However, when operating in the default mode the buffer
cache will only cache a fixed number of directories even if
you have a huge amount of memory. Turning on this sysctl
allows the buffer cache to use the VM Page Cache to cache the
directories, making all the memory available for caching
directories. However,
the minimum in-core memory used to cache a directory is the
- physical page size (typically 4K) rather than 512 bytes. We
+ physical page size (typically 4 K) rather than 512 bytes. We
recommend turning this option on if you are running any
services which manipulate large numbers of files. Such
services can include web caches, large mail systems, and news
systems. Turning on this option will generally not reduce
performance even with the wasted memory but you should
experiment to find out.hw.ata.wchw.ata.wc
- FreeBSD 4.3 flirted with turning off IDE write caching.
+ FreeBSD 4.3 flirted with turning off IDE write caching.
This reduced write bandwidth to IDE disks but was considered
necessary due to serious data consistency issues introduced
by hard drive vendors. The problem is that IDE
drives lie about when a write completes. With IDE write
caching turned on, IDE hard drives not only write data
to disk out of order, but will sometimes delay writing some
blocks indefinitely when under heavy disk loads. A crash or
power failure may cause serious filesystem corruption.
FreeBSD's default was changed to be safe. Unfortunately, the
result was such a huge performance loss that we changed
write caching back to on by default after the release. You
should check the default on your system by observing the
hw.ata.wc sysctl variable. If IDE write
caching is turned off, you can turn it back on by setting
the kernel variable back to 1. This must be done from the
boot loader at boot time. Attempting to do it after the
kernel boots will have no effect.For more information, please see &man.ata.4;.Soft UpdatesSoft UpdatestunefsThe &man.tunefs.8; program can be used to fine-tune a
filesystem. This program has many different options, but for
now we are only concerned with toggling Soft Updates on and
off, which is done by:&prompt.root; tunefs -n enable /filesystem
&prompt.root; tunefs -n disable /filesystemA filesystem cannot be modified with &man.tunefs.8; while
it is mounted. A good time to enable Soft Updates is before any
partitions have been mounted, in single-user mode.
- As of FreeBSD 4.5, it is possible to enable Soft Updates
+ As of FreeBSD 4.5, it is possible to enable Soft Updates
at filesystem creation time, through use of the -U
option to &man.newfs.8;.Soft Updates drastically improves meta-data performance, mainly
file creation and deletion, through the use of a memory cache. We
recommend to use Soft Updates on all of your filesystems. There
are two downsides to Soft Updates that you should be aware of: First,
Soft Updates guarantees filesystem consistency in the case of a crash
but could very easily be several seconds (even a minute!) behind
updating the physical disk. If your system crashes you may lose more
work than otherwise. Secondly, Soft Updates delays the freeing of
filesystem blocks. If you have a filesystem (such as the root
filesystem) which is almost full, performing a major update, such as
make installworld, can cause the filesystem to run
out of space and the update to fail.More details about Soft UpdatesSoft Updates (Details)There are two traditional approaches to writing a filesystem's meta-data
back to disk. (Meta-data updates are updates to
non-content data like inodes or directories.)Historically, the default behavior was to write out
meta-data updates synchronously. If a directory had been
changed, the system waited until the change was actually
written to disk. The file data buffers (file contents) were
passed through the buffer cache and backed up
to disk later on asynchronously. The advantage of this
implementation is that it operates safely. If there is
a failure during an update, the meta-data are always in a
consistent state. A file is either created completely
or not at all. If the data blocks of a file did not find
their way out of the buffer cache onto the disk by the time
of the crash, &man.fsck.8; is able to recognize this and
repair the filesystem by setting the file length to
0. Additionally, the implementation is clear and simple.
The disadvantage is that meta-data changes are slow. An
rm -r, for instance, touches all the files in a
directory sequentially, but each directory
change (deletion of a file) will be written synchronously
to the disk. This includes updates to the directory itself,
to the inode table, and possibly to indirect blocks
allocated by the file. Similar considerations apply for
unrolling large hierarchies (tar -x).The second case is asynchronous meta-data updates. This
is the default for Linux/ext2fs and
mount -o async for *BSD ufs. All
meta-data updates are simply being passed through the buffer
cache too, that is, they will be intermixed with the updates
of the file content data. The advantage of this
implementation is there is no need to wait until each
meta-data update has been written to disk, so all operations
which cause huge amounts of meta-data updates work much
faster than in the synchronous case. Also, the
implementation is still clear and simple, so there is a low
risk for bugs creeping into the code. The disadvantage is
that there is no guarantee at all for a consistent state of
the filesystem. If there is a failure during an operation
that updated large amounts of meta-data (like a power
failure, or someone pressing the reset button),
the filesystem
will be left in an unpredictable state. There is no opportunity
to examine the state of the filesystem when the system
comes up again; the data blocks of a file could already have
been written to the disk while the updates of the inode
table or the associated directory were not. It is actually
impossible to implement a fsck which is
able to clean up the resulting chaos (because the necessary
information is not available on the disk). If the
filesystem has been damaged beyond repair, the only choice
is to newfs it and restore it from backup.
The usual solution for this problem was to implement
dirty region logging, which is also
referred to as journaling, although that
term is not used consistently and is occasionally applied
to other forms of transaction logging as well. Meta-data
updates are still written synchronously, but only into a
small region of the disk. Later on they will be moved
to their proper location. Because the logging
area is a small, contiguous region on the disk, there
are no long distances for the disk heads to move, even
during heavy operations, so these operations are quicker
than synchronous updates.
Additionally the complexity of the implementation is fairly
limited, so the risk of bugs being present is low. A disadvantage
is that all meta-data are written twice (once into the
logging region and once to the proper location) so for
normal work, a performance pessimization
might result. On the other hand, in case of a crash, all
pending meta-data operations can be quickly either rolled-back
or completed from the logging area after the system comes
up again, resulting in a fast filesystem startup.Kirk McKusick, the developer of Berkeley FFS,
solved this problem with Soft Updates: all pending
meta-data updates are kept in memory and written out to disk
in a sorted sequence (ordered meta-data
updates). This has the effect that, in case of
heavy meta-data operations, later updates to an item
catch the earlier ones if the earlier ones are still in
memory and have not already been written to disk. So all
operations on, say, a directory are generally performed in
memory before the update is written to disk (the data
blocks are sorted according to their position so
that they will not be on the disk ahead of their meta-data).
If the system crashes, this causes an implicit log
rewind: all operations which did not find their way
to the disk appear as if they had never happened. A
consistent filesystem state is maintained that appears to
be the one of 30 to 60 seconds earlier. The
algorithm used guarantees that all resources in use
are marked as such in their appropriate bitmaps: blocks and inodes.
After a crash, the only resource allocation error
that occurs is that resources are
marked as used which are actually free.
&man.fsck.8; recognizes this situation,
and frees the resources that are no longer used. It is safe to
ignore the dirty state of the filesystem after a crash by
forcibly mounting it with mount -f. In
order to free resources that may be unused, &man.fsck.8;
needs to be run at a later time. This is the idea behind
the background fsck: at system startup
time, only a snapshot of the
filesystem is recorded. The fsck can be
run later on. All filesystems can then be mounted
dirty, so the system startup proceeds in
multiuser mode. Then, background fscks
will be scheduled for all filesystems where this is required, to free
resources that may be unused. (Filesystems that do not use
Soft Updates still need the usual foreground
fsck though.)The advantage is that meta-data operations are nearly as
fast as asynchronous updates (i.e. faster than with
logging, which has to write the
meta-data twice). The disadvantages are the complexity of
the code (implying a higher risk for bugs in an area that
is highly sensitive regarding loss of user data), and a
higher memory consumption. Additionally there are some
idiosyncrasies one has to get used to.
After a crash, the state of the filesystem appears to be
somewhat older. In situations where
the standard synchronous approach would have caused some
zero-length files to remain after the
fsck, these files do not exist at all
with a Soft Updates filesystem because neither the meta-data
nor the file contents have ever been written to disk.
Disk space is not released until the updates have been
written to disk, which may take place some time after
running rm. This may cause problems
when installing large amounts of data on a filesystem
that does not have enough free space to hold all the files
twice.Tuning Kernel LimitsTuning kernel limitsFile/Process Limitskern.maxfileskern.maxfileskern.maxfiles can be raised or
lowered based upon your system requirements. This variable
indicates the maximum number of file descriptors on your
system. When the file descriptor table is full,
file: table is full will show up repeatedly
in the system message buffer, which can be viewed with the
dmesg command.Each open file, socket, or fifo uses one file
descriptor. A large-scale production server may easily
require many thousands of file descriptors, depending on the
kind and number of services running concurrently.kern.maxfile's default value is
dictated by the option in your
kernel configuration file. kern.maxfiles grows
proportionally to the value of . When
compiling a custom kernel, it is a good idea to set this kernel
configuration option according to the uses of your system. From
this number, the kernel is given most of its pre-defined limits.
Even though a production machine may not actually have 256 users
connected as once, the resources needed may be similar to a
high-scale web server.
- As of FreeBSD 4.5, setting to
+ As of FreeBSD 4.5, setting to
0 in your kernel configuration file will choose
a reasonable default value based on the amount of RAM present in
your system.Network LimitsThe kernel configuration
option dictates the amount of network mbufs available to the
system. A heavily-trafficked server with a low number of MBUFs
will hinder FreeBSD's ability. Each cluster represents
- approximately 2K of memory, so a value of 1024 represents 2
+ approximately 2 K of memory, so a value of 1024 represents 2
megabytes of kernel memory reserved for network buffers. A
simple calculation can be done to figure out how many are
needed. If you have a web server which maxes out at 1000
- simultaneous connections, and each connection eats a 16K receive
- and 16K send buffer, you need approximately 32MB worth of
+ simultaneous connections, and each connection eats a 16 K receive
+ and 16 K send buffer, you need approximately 32 MB worth of
network buffers to cover the web server. A good rule of thumb is
- to multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768.
+ to multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768.
Adding Swap SpaceNo matter how well you plan, sometimes a system doesn't run
as you expect. If you find you need more swap space, it's
simple enough to add. You have three ways to increase swap
space: adding a new hard drive, enabling swap over NFS, and
creating a swap file on an existing partition.Swap on a New Hard DriveThe best way to add swap, of course, is to use this as an
excuse to add another hard drive. You can always use another
hard drive, after all. If you can do this, go reread the
discussion of swap space
from the Initial Configuration
section of the Handbook for some suggestions on how to best
arrange your swap.Swapping over NFSSwapping over NFS is only recommended if you do not have a
local hard disk to swap to. Swapping over NFS is slow and
inefficient in versions of FreeBSD prior to 4.X. It is
reasonably fast and efficient in 4.0-RELEASE and newer. Even
with newer versions of FreeBSD, NFS swapping will be limited
by the available network bandwidth and puts an additional
burden on the NFS server.SwapfilesYou can create a file of a specified size to use as a swap
file. In our example here we will use a 64MB file called
/usr/swap0. You can use any name you
want, of course.Creating a SwapfileBe certain that your kernel configuration includes
the vnode driver. It is not in recent versions of
GENERIC.pseudo-device vn 1 #Vnode driver (turns a file into a device)create a vn-device:&prompt.root; cd /dev
&prompt.root; sh MAKEDEV vn0create a swapfile (/usr/swap0):&prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64set proper permissions on (/usr/swap0):&prompt.root; chmod 0600 /usr/swap0enable the swap file in /etc/rc.conf:swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired.Reboot the machine or to enable the swap file immediately,
type:&prompt.root; vnconfig -e /dev/vn0b /usr/swap0 swap
diff --git a/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml b/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml
index 9c83ea994b..a7b07c2eef 100644
--- a/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml
@@ -1,905 +1,905 @@
JimMockRestructured, reorganized, and parts
rewritten by IntroductionSynopsisThank you for your interest in FreeBSD! The following chapter
covers various items about the FreeBSD Project, such as its history,
goals, development model, and so on.After reading this chapter, you will know:How FreeBSD relates to other computer operating systems.The history of the FreeBSD Project.The goals of the FreeBSD Project.The basics of the FreeBSD open-source development model.And of course: where the name FreeBSD comes from.Welcome to FreeBSD!4.4BSD-LiteFreeBSD is a 4.4BSD-Lite based operating system for the Intel
architecture (x86) and DEC Alpha based systems. Ports to other
architectures are also underway. For a brief overview of FreeBSD,
see the next section. You can also
read about the history of FreeBSD,
or the current release. If you
are interested in contributing something to the Project (code,
hardware, unmarked bills), see the Contributing to FreeBSD article.What Can FreeBSD Do?FreeBSD has many noteworthy features. Some of these
are:preemptive multitaskingPreemptive multitasking with
dynamic priority adjustment to ensure smooth and fair
sharing of the computer between applications and users, even
under the heaviest of loads.multi-user facilitiesMulti-user facilities which allow many
people to use a FreeBSD system simultaneously for a variety
of things. This means, for example, that system peripherals
such as printers and tape drives are properly shared between
all users on the system or the network and that individual
resource limits can be placed on users or groups of users,
protecting critical system resources from over-use.TCP/IP networkingStrong TCP/IP networking with
support for industry standards such as SLIP, PPP, NFS, DHCP,
and NIS. This means that your FreeBSD machine can
interoperate easily with other systems as well as act as an
enterprise server, providing vital functions such as NFS
(remote file access) and email services or putting your
organization on the Internet with WWW, FTP, routing and
firewall (security) services.memory protectionMemory protection ensures that
applications (or users) cannot interfere with each other. One
application crashing will not affect others in any way.FreeBSD is a 32-bit operating
system (64-bit on the Alpha) and was
designed as such from the ground up.X Window SystemXFree86The industry standard X Window System
(X11R6) provides a graphical user interface (GUI) for the cost
of a common VGA card and monitor and comes with full
sources.binary compatibilityLinuxbinary compatibilitySCObinary compatibilitySVR4binary compatibilityBSD/OSbinary compatibilityNetBSDBinary compatibility with many
programs built for Linux, SCO, SVR4, BSDI and NetBSD.Thousands of ready-to-run
applications are available from the FreeBSD
ports and packages
collection. Why search the net when you can find it all right
here?Thousands of additional and
easy-to-port applications are available
on the Internet. FreeBSD is source code compatible with most
popular commercial Unix systems and thus most applications
require few, if any, changes to compile.virtual memoryDemand paged virtual memory and
merged VM/buffer cache design efficiently
satisfies applications with large appetites for memory while
still maintaining interactive response to other users.Symetric Multi-Processing (SMP)SMP support for machines with
multiple CPUs.compilersCcompilersC++compilersFortranA full complement of C,
C++, Fortran, and
Perl development tools.
Many additional languages for advanced research
and development are also available in the ports and packages
collection.source codeSource code for the entire system
means you have the greatest degree of control over your
environment. Why be locked into a proprietary solution
at the mercy of your vendor when you can have a truly open
system?Extensive online
documentation.And many more!4.4BSD-LiteComputer Systems Research Group (CSRG)U.C. BerkeleyFreeBSD is based on the 4.4BSD-Lite release from Computer
Systems Research Group (CSRG) at the University of California at
Berkeley, and carries on the distinguished tradition of BSD
systems development. In addition to the fine work provided by
CSRG, the FreeBSD Project has put in many thousands of hours in
fine tuning the system for maximum performance and reliability in
real-life load situations. As many of the commercial giants
struggle to field PC operating systems with such features,
performance and reliability, FreeBSD can offer them
now!The applications to which FreeBSD can be put are truly
limited only by your own imagination. From software development
to factory automation, inventory control to azimuth correction of
remote satellite antennae; if it can be done with a commercial
Unix product then it is more than likely that you can do it with
FreeBSD too! FreeBSD also benefits significantly from the
literally thousands of high quality applications developed by
research centers and universities around the world, often
available at little to no cost. Commercial applications are also
available and appearing in greater numbers every day.Because the source code for FreeBSD itself is generally
available, the system can also be customized to an almost unheard
of degree for special applications or projects, and in ways not
generally possible with operating systems from most major
commercial vendors. Here is just a sampling of some of the
applications in which people are currently using FreeBSD:Internet Services: The robust TCP/IP
networking built into FreeBSD makes it an ideal platform for a
variety of Internet services such as:FTP serversFTP serversweb serversWorld Wide Web servers (standard or secure
[SSL])firewallIP masqueradingFirewalls and NAT (IP masquerading)
gatewayselectronic mailElectronic Mail serversUSENETUSENET News or Bulletin Board SystemsAnd more...With FreeBSD, you can easily start out small with an
inexpensive 386 class PC and upgrade all the way up to a
quad-processor Xeon with RAID storage as your enterprise
grows.Education: Are you a student of
computer science or a related engineering field? There is no
better way of learning about operating systems, computer
architecture and networking than the hands on, under the hood
experience that FreeBSD can provide. A number of freely
available CAD, mathematical and graphic design packages also
make it highly useful to those whose primary interest in a
computer is to get other work
done!Research: With source code for the
entire system available, FreeBSD is an excellent platform for
research in operating systems as well as other branches of
computer science. FreeBSD's freely available nature also makes
it possible for remote groups to collaborate on ideas or
shared development without having to worry about special
licensing agreements or limitations on what may be discussed
in open forums.routerDNS ServerNetworking: Need a new router? A
name server (DNS)? A firewall to keep people out of your
internal network? FreeBSD can easily turn that unused 386 or
486 PC sitting in the corner into an advanced router with
sophisticated packet-filtering capabilities.X Window SystemXFree86X Window SystemAccellerated-XX Window workstation: FreeBSD is a
fine choice for an inexpensive X terminal solution, either
using the freely available XFree86 server or one of the
excellent commercial servers provided by X Inside. Unlike an
X terminal, FreeBSD allows many applications to be run
locally, if desired, thus relieving the burden on a central
server. FreeBSD can even boot diskless, making
individual workstations even cheaper and easier to
administer.GNU Compiler CollectionSoftware Development: The basic
FreeBSD system comes with a full complement of development
tools including the renowned GNU C/C++ compiler and
debugger.FreeBSD is available in both source and binary form on CDROM
and via anonymous FTP. Please see
for more information about obtaining FreeBSD.Who uses FreeBSD?UsersLarge sites running FreeBSDFreeBSD is used to power some of the biggest sites on the
Internet, including:Yahoo!Yahoo!ApacheApacheBe, Inc.Be, Inc.Blue Mountain ArtsBlue Mountain
ArtsPair NetworksPair
NetworksWhistle CommunicationsWhistle
CommunicationsMicrosoftMicrosoftHotmailHotmailSony JapanSony
Japanand many more.About the FreeBSD ProjectThe following section provides some background information on
the project, including a brief history, project goals, and the
development model of the project.JordanHubbardContributed by A Brief History of FreeBSD386BSD PatchkitHubbard, JordanWilliams, NateGrimes, RodFreeBSD ProjectHistoryThe FreeBSD project had its genesis in the early part of 1993,
partially as an outgrowth of the Unofficial 386BSD
Patchkit by the patchkit's last 3 coordinators: Nate
Williams, Rod Grimes and myself.386BSDOur original goal was to produce an intermediate snapshot of
386BSD in order to fix a number of problems with it that the
patchkit mechanism just was not capable of solving. Some of you
may remember the early working title for the project being
386BSD 0.5 or 386BSD Interim in
reference to that fact.Jolitz, Bill386BSD was Bill Jolitz's operating system, which had been up
to that point suffering rather severely from almost a year's worth
of neglect. As the patchkit swelled ever more uncomfortably with
each passing day, we were in unanimous agreement that something
had to be done and decided to assist Bill by providing
this interim cleanup snapshot. Those plans came to
a rude halt when Bill Jolitz suddenly decided to withdraw his
sanction from the project without any clear indication of what
would be done instead.Greenman, DavidWalnut Creek CDROMIt did not take us long to decide that the goal remained
worthwhile, even without Bill's support, and so we adopted the
name FreeBSD, coined by David Greenman. Our initial
objectives were set after consulting with the system's current
users and, once it became clear that the project was on the road
to perhaps even becoming a reality, I contacted Walnut Creek CDROM
with an eye towards improving FreeBSD's distribution channels for
those many unfortunates without easy access to the Internet.
Walnut Creek CDROM not only supported the idea of distributing
FreeBSD on CD but also went so far as to provide the project with a
machine to work on and a fast Internet connection. Without Walnut
Creek CDROM's almost unprecedented degree of faith in what was, at
the time, a completely unknown project, it is quite unlikely that
FreeBSD would have gotten as far, as fast, as it has today.4.3BSD-LiteNet/2U.C. Berkeley386BSDFree Software FoundationThe first CDROM (and general net-wide) distribution was
- FreeBSD 1.0, released in December of 1993. This was based on the
+ FreeBSD 1.0, released in December of 1993. This was based on the
4.3BSD-Lite (Net/2) tape from U.C. Berkeley, with
many components also provided by 386BSD and the Free Software
Foundation. It was a fairly reasonable success for a first
offering, and we followed it with the highly successful FreeBSD
1.1 release in May of 1994.NovellU.C. BerkeleyNet/2AT&TAround this time, some rather unexpected storm clouds formed
on the horizon as Novell and U.C. Berkeley settled their
long-running lawsuit over the legal status of the Berkeley Net/2
tape. A condition of that settlement was U.C. Berkeley's
concession that large parts of Net/2 were encumbered
code and the property of Novell, who had in turn acquired it from
AT&T some time previously. What Berkeley got in return was
Novell's blessing that the 4.4BSD-Lite release, when
it was finally released, would be declared unencumbered and all
existing Net/2 users would be strongly encouraged to switch. This
included FreeBSD, and the project was given until the end of July
1994 to stop shipping its own Net/2 based product. Under the
terms of that agreement, the project was allowed one last release
- before the deadline, that release being FreeBSD 1.1.5.1.
+ before the deadline, that release being FreeBSD 1.1.5.1.
FreeBSD then set about the arduous task of literally
re-inventing itself from a completely new and rather incomplete
set of 4.4BSD-Lite bits. The Lite releases were
light in part because Berkeley's CSRG had removed large chunks of
code required for actually constructing a bootable running system
(due to various legal requirements) and the fact that the Intel
port of 4.4 was highly incomplete. It took the project until
November of 1994 to make this transition, at which point it
- released FreeBSD 2.0 to the net and on CDROM (in late December).
+ released FreeBSD 2.0 to the net and on CDROM (in late December).
Despite being still more than a little rough around the edges,
the release was a significant success and was followed by the
- more robust and easier to install FreeBSD 2.0.5 release in June of
+ more robust and easier to install FreeBSD 2.0.5 release in June of
1995.
- We released FreeBSD 2.1.5 in August of 1996, and it appeared
+ We released FreeBSD 2.1.5 in August of 1996, and it appeared
to be popular enough among the ISP and commercial communities that
another release along the 2.1-STABLE branch was merited. This was
- FreeBSD 2.1.7.1, released in February 1997 and capping the end of
+ FreeBSD 2.1.7.1, released in February 1997 and capping the end of
mainstream development on 2.1-STABLE. Now in maintenance mode,
only security enhancements and other critical bug fixes will be
done on this branch (RELENG_2_1_0).
- FreeBSD 2.2 was branched from the development mainline
+ FreeBSD 2.2 was branched from the development mainline
(-CURRENT) in November 1996 as the RELENG_2_2
branch, and the first full release (2.2.1) was released in April
1997. Further releases along the 2.2 branch were done in the
summer and fall of '97, the last of which (2.2.8) appeared in
November 1998. The first official 3.0 release appeared in
October 1998 and spelled the beginning of the end for the 2.2
branch.The tree branched again on Jan 20, 1999, leading to the
4.0-CURRENT and 3.X-STABLE branches. From 3.X-STABLE, 3.1 was
released on February 15, 1999, 3.2 on May 15, 1999, 3.3 on
September 16, 1999, 3.4 on December 20, 1999, and 3.5 on
June 24, 2000, which was followed a few days later by a minor
point release update to 3.5.1, to incorporate some last-minute
security fixes to Kerberos. This will be the final release in the
3.X branch.There was another branch on March 13, 2000, which saw the
emergence of the 4.X-STABLE branch, now considered to be the
"current -stable branch". There have been several releases
from it so far: 4.0-RELEASE came out in March 2000, 4.1 was
released in July 2000, 4.2 in November 2000, 4.3 in April
2001, and 4.4 in September 2001. There will be more releases
along the 4.X-stable (RELENG_4) branch well into 2002.Long-term development projects continue to take place in the
5.0-CURRENT (trunk) branch, and SNAPshot releases of 5.0 on
CDROM (and, of course, on the net) are continually made available
from
the snapshot server as work progresses.JordanHubbardContributed by FreeBSD Project GoalsFreeBSD ProjectGoalsThe goals of the FreeBSD Project are 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 are definitely not prepared to 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, I believe, one of the most fundamental
goals of Free Software and one that we enthusiastically
support.GNU General Public License (GPL)GNU Lesser General Public License (LGPL)BSD CopyrightThat code in our source tree which falls under the GNU
General Public License (GPL) or 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, prefer
software submitted under the more relaxed BSD copyright when
it is a reasonable option to do so.SatoshiAsamiContributed by The FreeBSD Development ModelFreeBSD ProjectDevelopment ModelThe development of FreeBSD is a very open and flexible
process, FreeBSD being literally built from the contributions
of hundreds of people around the world, as can be seen from
our list of
contributors. We are constantly on the lookout for
new developers and ideas, and those interested in becoming
more closely involved with the project need simply contact us
at the &a.hackers;. The &a.announce; is also available to
those wishing to make other FreeBSD users aware of major areas
of work.Useful things to know about the FreeBSD project and its
development process, whether working independently or in close
cooperation:The CVS repositoryCVSrepositoryConcurrent Versions SystemCVSThe central source tree for FreeBSD is maintained by
CVS
(Concurrent Versions System), a freely available source code
control tool that comes bundled with FreeBSD. The primary
CVS
repository resides on a machine in Santa Clara CA, USA
from where it is replicated to numerous mirror machines
throughout the world. The CVS tree, as well as the -CURRENT and -STABLE trees which are checked out
of it, can be easily replicated to your own machine as well.
Please refer to the Synchronizing
your source tree section for more information on
doing this.The committers listcommittersThe committers
are the people who have write access to
the CVS tree, and are thus authorized to make modifications
to the FreeBSD source (the term committer
comes from the &man.cvs.1; commit
command, which is used to bring new changes into the CVS
repository). The best way of making submissions for review
by the committers list is to use the &man.send-pr.1;
command, though if something appears to be jammed in the
system then you may also reach them by sending mail to
the &a.committers;.The FreeBSD core teamcore teamThe FreeBSD core team
would be equivalent to the board of directors if the FreeBSD
Project were a company. The primary task of the core team
is to make sure the project, as a whole, is in good shape
and is heading in the right directions. Inviting dedicated
and responsible developers to join our group of committers
is one of the functions of the core team, as is the
recruitment of new core team members as others move on.
The current core team was elected from a pool of committer
candidates in October 2000. Elections are held every 2 years.
Some core team members also have specific areas of
responsibility, meaning that they are committed to
ensuring that some large portion of the system works as
advertised. For a complete list of FreeBSD developers
and their areas of responsibility, please see the Contributors
ListMost members of the core team are volunteers when it
comes to FreeBSD development and do not benefit from the
project financially, so commitment should
also not be misconstrued as meaning guaranteed
support. The board of directors
analogy above is not actually very accurate, and it may be
more suitable to say that these are the people who gave up
their lives in favor of FreeBSD against their better
judgment!Outside contributorscontributorsLast, but definitely not least, the largest group of
developers are the users themselves who provide feedback and
bug fixes to us on an almost constant basis. The primary
way of keeping in touch with FreeBSD's more non-centralized
development is to subscribe to the &a.hackers; (see mailing list info) where
such things are discussed.The
FreeBSD Contributors List is a long
and growing one, so why not join it by contributing
something back to FreeBSD today?Providing code is not the only way of contributing to
the project; for a more complete list of things that need
doing, please refer to the FreeBSD Project web
site.In summary, our development model is organized as a loose set
of concentric circles. The centralized model is designed for the
convenience of the users of FreeBSD, who are
thereby provided with an easy way of tracking one central code
base, not to keep potential contributors out! Our desire is to
present a stable operating system with a large set of coherent
application programs that the users
can easily install and use, and this model works very well in
accomplishing that.All we ask of those who would join us as FreeBSD developers is
some of the same dedication its current people have to its
continued success!The Current FreeBSD ReleaseNetBSDOpenBSD386BSDFree Software FoundationU.C. BerkeleyComputer Systems Research Group (CSRG)FreeBSD is a freely available, full source 4.4BSD-Lite based
release for Intel i386, i486, Pentium, Pentium Pro, Celeron,
- Pentium II, Pentium III (or compatible) and DEC Alpha based computer
+ Pentium II, Pentium III (or compatible) and DEC Alpha based computer
systems. It is based primarily on software from U.C. Berkeley's
CSRG group, with some enhancements from NetBSD, OpenBSD, 386BSD, and
the Free Software Foundation.
- Since our release of FreeBSD 2.0 in late 94, the performance,
+ Since our release of FreeBSD 2.0 in late 94, the performance,
feature set, and stability of FreeBSD has improved dramatically.
The largest change is a revamped virtual memory system with a merged
VM/file buffer cache that not only increases performance, but also
- reduces FreeBSD's memory footprint, making a 5MB configuration a
+ reduces FreeBSD's memory footprint, making a 5 MB configuration a
more acceptable minimum. Other enhancements include full NIS client
and server support, transaction TCP support, dial-on-demand PPP,
integrated DHCP support, an improved SCSI subsystem, ISDN support,
- support for ATM, FDDI, Fast and Gigabit Ethernet (1000Mbit)
+ support for ATM, FDDI, Fast and Gigabit Ethernet (1000 Mbit)
adapters, improved support for the latest Adaptec controllers, and
many hundreds of bug fixes.We have also taken the comments and suggestions of many of our
users to heart and have attempted to provide what we hope is a more
sane and easily understood installation process. Your feedback on
this (constantly evolving) process is especially welcome!In addition to the base distributions, FreeBSD offers a
ported software collection with thousands of commonly
sought-after programs. At the time of this printing, there
were over &os.numports; ports! The list of ports ranges from
http (WWW) servers, to games, languages, editors, and almost
everything in between. The entire ports collection requires
- approximately 100MB of storage, all ports being expressed as
+ approximately 100 MB of storage, all ports being expressed as
deltas to their original sources. This makes
it much easier for us to update ports, and greatly reduces the
disk space demands made by the older 1.0 ports collection. To
compile a port, you simply change to the directory of the
program you wish to install, type make
install, and let the system do the rest. The full
original distribution for each port you build is retrieved
dynamically off the CDROM or a local FTP site, so you need
only enough disk space to build the ports you want. Almost
every port is also provided as a pre-compiled
package, which can be installed with a simple
command (pkg_add) by those who do not wish
to compile their own ports from source.A number of additional documents which you may find very helpful
in the process of installing and using FreeBSD may now also be found
in the /usr/share/doc directory on any machine
- running FreeBSD 2.1 or later. You may view the locally installed
+ running FreeBSD 2.1 or later. You may view the locally installed
manuals with any HTML capable browser using the following
URLs:The FreeBSD Handbook/usr/share/doc/handbook/index.htmlThe FreeBSD FAQ/usr/share/doc/faq/index.htmlYou can also view the master (and most frequently updated)
copies at http://www.FreeBSD.org/.