You've installed FreeBSD, and it works fine, of course. If you are as seriously committed to using it as your desktop as I am, you'll want to get the most out it. Let's go hardcore! The key with FreeBSD is optimization -- tweaking the compile process so the resulting binary code runs as efficiently as possible.
So you've got some decent hardware. Optimization has always been fairly easy with FreeBSD, but recent changes in version 6.x have made it even better. Here's the concept: You use FreeBSD on the desktop or laptop. Set aside the time upfront to invest in the system, and the return over the next year or so will likely make you glad you did. Starting with around 500Mhz CPUs, the difference is noticeable. For CPUs above 1Ghz, the difference is often quite surprising.
This article assumes you have some sort of broadband access. Otherwise, this procedure would require about two weeks, even if you have the time to nurse the system through the inevitable dropped connections. As it is, this can take up to three days with a fast connection. Also, you'll need to note much of this depends on having at least 1Ghz of CPU speed, and a half-gig of RAM. Lesser machines take much longer. More robust machines take less, and a large CPU cache makes a major difference. Finally, unless you have tons of work files, 20GB of harddrive is plenty, and a 40GB will be huge. However, a faster harddrive will make the system faster, for obvious reasons.
Having installed FreeBSD at least two-dozen times, I tend to glance only rarely at my notes on the walkthrough. The steps haven't changed much since the 4.x release series. Given the primary goal of optimization, this will be rather different. We will install only the core system, rebuild and optimize that, then add the other userland packages from the latest sources. When we are through, the entire OS and all binaries will be optimized.
Again, get it set in your mind this takes awhile. Once you begin adding the userland packages, there will be frequent occasions when you'll need to select options for a given item. This cannot be done unattended.
Up through the point of partitioning the disk and creating the file system, there's nothing new. However, when the prompt comes up asking you to select a "distribution" (pre-selected package collection), only take the bare minimum for building the core system. You want #4, "Developer" without X. Since I was working from the installation CD, I chose that as the installation source. After the congratulation message, configure your Internet connection. You'll need this very soon.
When the message asks about ethernet or slip/ppp, choose
"yes." The next window lists the various interfaces the
installer thinks it can address. If you have an ethernet controller,
much depends on the chipset and how it connects to your hardware. There
are several dozen drivers already included in the FreeBSD kernel. Mine
offered to use the interface vr0 (that's VR-zero), because
my system has an onboard VIA VT6102 Rhine II chipset. If you don't see
an option that describes the chipset for yours, you'll need to spend
some time with Google, and I recommend you use keywords which include
freebsd and the brand and model of your ethernet chipset.
It is possible you can load the driver manually later, or you may need
to compile in a special driver. While this is relatively painless for
most things, it's beyond the scope of this article. I highly recommend
you join a forum where there are plenty of experience BSD users.
You'll need to know what your ISP requires from you to connect. At a minimum you'll need to know whether to engage DHCP. For something like SBC/Yahoo DSL, that's about all you'll need. When the form pops up for the host information, most of it will be filled in correctly under DHCP. You'll need to give your machine a name. I suggest a simple four or five letter nickname in this pattern:
name.local.bsd
If you have a fixed IP address and a legitimate host name, use that
instead. For the next few questions, I said "yes" only to the
use of SSH. This makes it easier to transfer files between machines on
the same local network (hint: man scp). Most everything
else should be "no." Eventually you'll work your way to the
option of adding pre-built packages from the CD. We need only one:
bash. I won't apologize for choosing the most
user-friendly shell. If you become curious, read up on the others and
try them out. Most desktop users prefer bash.
Tell the installer you are finished and be ready to swap disks
around should you select a package not on the first CD. If you find you
are missing disk 2, or it is unreadable, you can come back to this
later. In fact, once you've done your first reboot, you can do it
anytime using the command /usr/sbin/sysinstall, then
changing your install source to FTP, as long as you know the exact FTP
address you want to use. Once you have sysinstall running,
take time to read the listed options, and you should be able to find
that option, plus the option for adding packages.
The only thing left is adding your user account and setting the root
password. Once you've done that, the installer asks if you wish to
revisit any last install options. Select "yes" and you'll be
back at the sysinstall main window. On one occasion I
needed to download something. When I changed to FTP install source, in
the blank line for FTP directory, I decided to use:
ftp.freebsd.org
because for a single package, it shouldn't make too much difference
whether you use a mirror close to you. Pay attention to the prompts, and
realize you can always go back to the main sysinstall
window and keep trying it over until you get it right. You can find more
details here.
Your first boot should stop at the point of starting the SSH daemon,
if you enabled it as I did, by asking you to type random characters on
the screen. Be sure you don't hit the key sequence CTRL-C
nor the Scroll Lock in the process, as they can ruin the
whole thing. Just use the main letter and number keys and hit
ENTER when you have at least one line of random junk. The
system will then create your SSH keys and come back to the login
prompt.
Login as root. First, run this command:
/usr/libexec/locate.updatedb
You'll need an updated locate database to find things.
Keep in mind, at this stage we do everything from the console. First,
let's configure make.conf. We'll copy the generic system
default and modify it. We'll be using the bundled Easy Editor
(ee). It has most commands displayed in a portion of the
screen at the top. The only command you won't find there is how to
close. When you're done, simply hit ESC and wait for a
menu to popup on the screen. It should be obvious from there.
cp /usr/share/examples/etc/make.conf /etc/
ee /etc/make.conf
The editor will allow us to add compile-time options for the system
in general. The basic standard C and C++ libraries allow for CPU
optimizations. With each new generation, the processor manufacturer
adds new command sets to make the processor more efficient and
powerful. You'll notice in the top of the make.conf file,
we have a list of processors for which there are command-set
optimizations in the libraries. Mine is a Sempron-64, running in
32-bit mode, so I set the first CPU line like this:
CPUTYPE=k8. It would be athlon64 if I were
running in 64-bit mode. If the list of choices offered confuse you,
consider choosing simply i686 (unless you have an ancient
586 or AMD K5). Bench testing indicates the greatest improvement begins
there, and anything fancier is only a small increment faster. However,
if you know what you've got for sure, there's no harm taking it to the
max. Also note, things in FreeBSD have advanced to the point where the
general prohibition against optimization level 2 in the
CFLAGS is no longer applicable. So I made that one like
this: CFLAGS= -O2 -pipe. There are other possibilities,
but you'll need more expert guidance for your purposes.
Now we need to update our source and ports tree. This is adequately covered elsewhere. Just run:
csup stable-supfile
ports-supfile.
You should see displayed on the console a minimal report of what is
being dowloaded. When finished, you'll see a Finished
successfully, and the command prompt will return. Next, you'll
need to navigate to the kernel configuration file and make some
changes. This is not covered in the system update tutorial.
Make sure you don't get too zealous in deleting options in the kernel
configuration to trim things down. I once removed the da
driver and couldn't mount any USB storage devices. You can find details
here.
I note here one of the advantages Linux had for a long time was the console framebuffer, with extensive control over the font sizing and such, along with the possibility of getting console applications to receive mouse-clicks. While FreeBSD's method for mouse-clicks on the console is obscure and very difficult to implement, it has the slight advantage of a graphical pointer. Further, recent changes to the kernel now allow a full range of VESA modes (not working in AMD64 branch). We'll build this capability into the kernel and see how it works later.
When you customize your kernel configuration file, you are supposed to give it different name. First, find the generic kernel config:
locate GENERIC
You'll get back a list of all the GENERIC kernels on the system,
among other things. As we are building here from the i386
branch, we focus on
/usr/src/sys/i386/conf/GENERIC
We'll make a couple of copies, then rename one and edit. Decide now
what you want to name your custom kernel. It may be the same as your
machine name, or something describing what makes it different. I
typically use the former, which means naming it CRATER.
It's tradition to name active kernel config files in all caps.
cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/generic
cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/CRATER
The first copy we can use later when updating the system. Running
csup will always overwrite the original
GENERIC but leave the others. The lower case version of
the original can be compared with the new GENERIC to see
if anything has changed:
diff /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/generic
If the prompt comes back with no response, it's the same. That means you can then re-use your custom config (so long as it worked the first time). Edit your custom file with Easy Editor:
ee /usr/src/sys/i386/conf/CRATER
At the top, I comment out the cpu lines which don't
apply:
machine i386
#cpu I486_CPU
#cpu I586_CPU
cpu I686_CPU
ident CRATER
I typically comment out the lines regarding MD_ROOT and
the NFS stuff. Below that, you can also judiciously
comment out hardware you know you'll never use, especially some of the
SCSI, RAID and ethernet drivers. Down where we find the
vga line, I add two items:
device vga # VGA video card driver
options VESA
options SC_PIXEL_MODE
This allows us to use VESA modes on the console. Down at the bottom, if you have a soundcard, you can add:
device sound
which loads the basic sound service by default. Save the file, close it, and make sure you're in the right place for what follows. Always leave one blank line at the bottom of a Unix configuration file.
I'll only outline here the steps to rebuilding the core system:
cd /usr/src
make buildworld
make buildkernel KERNCONF=CRATER
make installkernel KERNCONF=CRATER
reboot
shutdown now
cd /usr/src
make installworld
mergemaster
reboot
Upon rebooting, everything you have so far will be optimized. Let's put that VESA display to work. Once you've logged back in on the console as root, run this command:
vidcontrol -i mode
The screen should fill with so many lines they run off the screen at the top. That's okay, but it's likely we will use the last dozen or so lines, like this:
282 (0x142) 0x0000000f G 1280x1024x16 1 8x16 0xa0000 64k 64k 0x98000000
65472k
What we need to see is the initial 3-digit mode number
(282 in this case), and the screen resolution which
follows the letter "G" -- 1280x1024x16. That is
a 1280x1024 at 16-bit color, which is plenty good for a 19"
monitor. Now we test to see if it can actually do that:
vidcontrol MODE_282
If the screen changes to a much smaller font, but retains the sharp
graphical font display, you win. To make this a permanent feature on
all virtual terminals, add this line to /etc/rc.conf just
below the lines setting font controls at the top:
allscreens_flags="MODE_282"
Next, we see if FreeBSD can read the sound card chipset. First, turn
on your speakers and the set the volume rather loud. Then, take a look
at your boot messages using the command dmesg but keep it
from running away by piping it through the less
command:
dmesg | less
That thing in the middle is called a "pipe" and you can
find on most keyboards, usually as a straight vertical line with a
break in the middle. Some of the lines in what's displayed should
mention a pcm0 or something similar, followed by such
words as Codec or Multimedia. The line above
that should be similar, with the identity of your chipset. You can
usually match that pretty closely with one of the sound drivers, with
file names starting with snd, and underscore, then the
chipset designation:
locate snd_
Mine is identified in dmesg as VIA VT8237,
so the driver would be snd_via8233. To be sure, you can
simply run the manpage for that driver and it should identify what
chipsets are covered.
If all else fails, simply load all the kernel module sound drivers at once:
kldload sound
Wait a few seconds, then check to see which driver the kernel decided should stick:
kldstat
That command should give you a list of the modules loaded, and one
of them should start with snd_. If not, you'll need some
serious expert help from a forum, search engine, or a FreeBSD user you
know. If you do find out, the moment you load the proper driver, if
your sound system is on, it should make enough noise for your to
determine it's working, such as a click, pop, or something similar. You
can direct the system to load the driver at every boot. Edit the boot
options file, /boot/loader.conf and add lines like
this:
snd_driver_load="YES"
Replace the driver part with the one you chose from the
exercises above. Mine says:
snd_via8233_load="YES"
Finally, don't be afraid to leave all that code in the
/usr/obj/ directory until the next system update. Should
you ever damage or corrupt part of your core system, it's a simple
matter to run make installworld again and fix things.
However, be sure to delete all that stuff before your next system
update.
Because we updated our ports tree, we can be comfortable we are getting the latest and greatest for FreeBSD. You can choose any desktop you want. For this exercise, I chose KDE, which is a common choice for home and small business users. Building KDE from source and optimizing can easily halve the time and resources required during daily use. Because the ports tree handles dependencies for us, we need not worry too much about all the niggling details. The shortest path is this:
cd /usr/ports/x11/kde3
make install
If you watch, you'll notice in the process you'll get some of the X.org packages built automatically as dependencies, and all of it will be optimized. However, to actully have a GUI on your machine, you'll need to add the following manually:
Other packages you might consider, based on your desktop use habits:
Notice many of these will also pull in various dependencies. The last significant item is an office suite, and you may wish to put it off a day or so until you have everything else running properly. Building anything large works best if you log out of the X server and work from the console. While OpenOffice is the standard, it really does take a long time to build, and requires a huge amount of temporary space on the harddrive. OO.org 2.x requires about 9GB; while it requests also 2GB of RAM, I got it done just fine with 1GB. The build process is no longer so prone to errors, so consider it if you need a full office suite. You'll have to jump through some hoops on the Java dependency, but if you read and follow the instructions using the Elinks browser, it should work fine. Note, this is the place to get used to logging onto multiple virtual consoles, and discover using your mouse clipboard will work fine between them. If you prefer GNOME, consider the AbiWord/Gnumeric pair. On much older machines, you may need to look elsewhere, such as using Ted as a word processor, and Oleo or the commandline spreadsheet sc.
Once you've finished building all your chosen packages, you will
have spent some two days most likely, and it's time to run the last
configurations. Setting up the X.org server is covered elsewhere.
However, you can't do any of this from sysinstall any
more. It's simplest, in my opinion, to run /usr/X11R6/bin/xorgcfg
-textmode and follow the instructions on the screen. Also, don't
forget to configure the font paths.
It's simplest to test the configuration while still logged in as
root. First, type cd by itself to return you to root's home
directory. There, create a file that starts KDE automatically:
cd
ee .xinitrc
Type in this line: exec /usr/local/bin/startkde, then
hit ENTER because, again, configuration files in BSD must
have one blank line at the bottom. Save and close. Then try the command
startx and see what happens. If it fails and you have no
idea what to do, see your friends on a BSD forum, or you can contact me
and I might be able to help.
By Ed Hurst
updated 10 January 2007
COPYRIGHT NOTICE: People of honor need no copyright laws; they are only too happy to give credit where credit is due. Others will ignore copyright laws whenever they please. If you are of the latter, please note what Moses said about dishonorable behavior -- "be sure your sin will find you out" (Numbers 32:23)