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. Without,
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.
Also, 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. You may need a more thorough review. However, given
the 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.
Preliminary Steps
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 source. After the congratulation message, you'll need to
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 rl0 (that's RL-zero), because my system has an
onboard RealTek 8100 series 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
AT&T Yahoo DSL, that may be all you need (although FreeBSD does support PPPoE if your modem does not handle the authentication process for you.). 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 three:
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.
cvsup-without-gui: This will allow you to download core
system update code and update your ports tree.
pico: This is one of the simplest editors on the
commandline, far simpler than anything else easily available in this
situation.
Tell the installer you are finished and be ready to swap disks
around. 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 /stand/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. In my case, the
installer couldn't read the cvsup-without-gui package.
You'll see how I got it later.
In fact, 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. 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.
Optimizing and Building the Core
Your first boot should stop at the point of starting the SSH daemon
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. 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.
The pico 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
Pentium4, so I set the first CPU line like this:
CPUTYPE=pentium4. 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. The
only difference is, since we have no GUI, we use the cvsup command
provided in the cvsup files:
cvsup -g -L 2 stable-supfile
for the system core, and similar for the ports-supfile.
You should see displayed on the console a detailed 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.
That is also covered in the system
update tutorial. Make sure you don't get too zealous in deleting
options in the kernel configuration. I once removed the da
driver and couldn't mount any USB storage devices. You can find details
here.
I'll only outline here the steps to rebuilding the core system:
cd /usr/src
make buildworld
make buildkernel
make installkernel
reboot
shutdown now
cd /usr/src
make installworld
mergemaster
reboot
Upon rebooting, everything you have so far will be optimized. Next,
we add uesrland stuff.
Don't be afraid to keep 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 simply matter to run make
installworld again and fix things. However, be sure to delete all
that stuff before your next system update.
Adding the Desktop
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 && make clean
However, that adds components I won't use. The path I chose is
probably not the shortest, but the one with which I'm most
comfortable. I went through the ports tree and ran the build and install
scripts for the following:
qt3.3
kdebase3
kdeadmin3
kdeutils3
kdenetwork3
kdepim3
kdegraphics3
kdeartwork3
kdemultimedia3
kdegames3
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:
xorg-fonts-type1
xorg-fonts-75dpi
xorg-fonts-100dpi
xorg-fonts-miscbitmaps
xorg-server
xorg-clients
dri (if your graphics chipset is capable of 3D rendering)
urwfonts-ttf
webfonts
Other packages you might consider, based on your desktop use
habits:
seamonkey
mplayer
mplayer-plugin
mplayer-skins
kmplayer
nedit
elinks
joe
elinks
mc
Notice many of these will also pull in various dependencies. The last
significant item is an office suite. 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. With the 1.x series it was 4GB; 2.x
requires about 9GB. The build process is also prone to errors, so only
try it if you really need it. Note it was just recently ported fully to
the AMD64 architecture. Given my choice of the KDE environment, my own
preference is KOffice. The latest version is quite useful. Once you have
your templates made, it's quite easy and will open most files made with
OpenOffice 2. 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 at least 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 fonts.
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
pico .xinitrc
Type in this line: exec /usr/local/bin/startkde, then
hit ENTER because 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.
Ed Hurst is Associate Editor of Open for Business. Ed operates a computer ministry in Oklahoma City. He loves computers, runs FreeBSD and GNU/Linux and reads all sorts of things. You can reach Ed at ehurst@ofb.biz.
I was hoping to find more insider info like tuning kernel variables via sysctl or source. Instead the author turns some basic knobs and dumps KDE on top of it (which is also should undergo some optimization).
Sorry, Maznio, you came to wrong place for that. I use the term “optimized” as in code and complie optimizations, not tuning and tweaking. You might try BSDForums.org or ScreamingElectron.org.
The same optimization procedure was adopted by gentoo linux.
However, -march=pentiu4 some times for some user-land
applications may leed to system instabilities and
segmentation faults. The same thing happens to FreeBSD as
well. I have experienced instabilities to some applications
when I compiled them with -O2 -march=pentium4.
Now as for the whole performance gain from simple -O2 to
-march=pentium4 -O2 I really doubt. Scientific Computing applications compiled with -O2 run as fast as those with
-O2 -march=pentium4. Hardly you may find some which will
benefit from -march=pentium4. So I guess that the whole
issue of optimizing OS like Linux(gentoo) or FreeBSD
doesn’t worth trying.
Ed Hurst, if you can assemble benchmark results to some
popular userspace applications or some frequent kernel
tasks then if those look encouraging we might discuss it again.
set ccache temp size to 512MB (default 1GB)
if ( -x /usr/local/bin/ccache ) then
/usr/local/bin/ccache -M 512m > /dev/null
endif
3. set base system knobs, disable the thing that you do not use:
—< base system knobs :: BEGIN >—
NO_ATM=yes # do not build ATM related programs and libraries
NO_BIND=yes # do not build bind and related programs
NO_BLUETOOTH=yes # do not build Bluetooth related stuff
NO_CVS=yes # do not build CVS
NO_FORTRAN= yes # do not build g77 and related libraries
NO_GDB= yes # do not build GDB
NO_I4B=yes # do not build isdn4bsd package
NO_INET6= yes # do not build IPv6 related programs and libraries
NO_INFO= yes # do not make or install info files
NO_IPFILTER= yes # do not build IP Filter package
NO_KERBEROS= yes # do not build and install Kerberos 5 (KTH Heimdal)
NO_LPR= yes # do not build lpr and related programs
NO_MAILWRAPPER= yes # do not build the mailwrapper(8) MTA selector
NO_NETCAT= yes # do not build netcat
NO_PF= yes # do not build PF firewall package
NO_PROFILE= yes # Avoid compiling profiled libraries
NO_RCMDS= yes # do not build or install BSD r* commands (rsh, etc)
NO_SENDMAIL= yes # do not build sendmail and related programs
5. disable unused terminals in /etc/ttys (4 is more then enought):
when going to single-user mode.
console none unknown off insecure
#
ttyv0 “/usr/libexec/getty Pc” cons25 on secure
ttyv1 “/usr/libexec/getty Pc” cons25 on secure
ttyv2 “/usr/libexec/getty Pc” cons25 on secure
ttyv3 “/usr/libexec/getty Pc” cons25 on secure
#ttyv4 “/usr/libexec/getty Pc” cons25 on secure
#ttyv5 “/usr/libexec/getty Pc” cons25 on secure
#ttyv6 “/usr/libexec/getty Pc” cons25 on secure
#ttyv7 “/usr/libexec/getty Pc” cons25 on secure
#ttyv8 “/usr/X11R6/bin/xdm -nodaemon” xterm off secure
6. XFce is the biggest thing you want to use, maybe gnome, but most FreeBSD users go for fast and efficent small window manager like fluxbox fvwm openbox pekwm …
7. X11 optimising, do not load unneded modules in /etc/X11/xorg.conf:
Well, this is decent for a slacker version of optimizing…
I’ve been in the process of doing this process, well, a similar process, for an AOpen AX4GE-Tube motherboard (yes, the one with the vacuum tube audio preamp on the mootherboard), and I would like to detail a few differences here…
1). choose “Custom”, select all that you want (it will all be rebuilt anyway in the buildworld), except X. Select all appropriate sources in the source code section of the “Custom” setup screen.
2). unless you are a masochist, NEVER use pico for editing configuration files. If a configuration line is too long, pico will chop single lines into one or more lines depending on length once you save a file, by default. Use the built-inee or vi (or, if you are a Real Man, use ed(1), at least until you get around to compiling a real editor like emacs.
the Kernel will refuse to build with the sse and sse math options.
Also add a commented:
CFLAGS= -O2 -march=pentium4 -mtune=pentium4 -pipe
as, some ports also puke with the sse and sse math options, and all you have to do is swap the comment char between the two lines long enough to start a build (but be sure to uncomment the line with the sse options again after you start make, as if you have multiple builds going, you don’t want something to miss the faster options).
4). for a truely optimized system, you might also want to build cvsup-without-gui from scratch as well, although the ezm compile can take a while. At least this way, it will be optimized as well. For that matter, if you MUST use bash(1) over csh(1) or tcsh(1), then compile it from scratch too. The time diff involved is only ten minutes tops in the install process.
5). why bother with the command line version of cvsup? enable source updating while you are in make.conf, and simply:
cd /usr/src
make update
and that takes care of src, ports, and docs without any further interaction (unless you want to tweak the retry mechanism, because it will rarely connect on the first attempt, and five minute backoff can take up to days to update stuff, if you are unlucky).
6). for configuring x.org, it’s far easier, and far more accurate, to skip the xorgcfg program altogether, and use:
cd /etc/X11
Xorg -configure
which, according to the manual page:
When this option is specified, the Xorg server loads all video
driver modules, probes for available hardware, and writes out
an initial xorg.conf(5) file based on what was detected. This
option currently has some problems on some platforms, but in
most cases it is a good way to bootstrap the configuration
process. This option is only available when the server is run
as root (i.e, with real-uid 0).
7). enjoy having a targeted, optimized OS when it’s all said and done.
Although Ed made a few optimization mistakes, or at the least a few shortcuts, the article is a sound article, and of course gives good advice, or at least advice in the correct direction.
Don’t take my criticism personally, Ed, and always remember, collaboration is how we got this far to begin with.
1st: you dont need cvsup-without-gui anymore in recent freebsd version. it needs ezm3 because its not written in c but modula3. the base system now comes with a replacement csup, written in c, it takes the same options, one option is dropped, ready. i dunno for sure, but i guess recent make.conf has csup by default? if not, just replace cvsup with cvup there.
2nd: when installing the core to your hard drive, select base, kernel and src/base, src/tools, this is the minimum, i dunno if option #4 development system is the same, but this is definately the minimum.
3rd: if u dont debug u should add -fomit-frame-pointer to CFLAGS. its the only option besides -O2 wchich is safe… though in the past the base system didnt build then, u had to set -fno-strict-aliasing too, but i think now u just add -fomit-frame-pointer and it should work. try it. this free extra register gives some speed… other options like -ftracer are nice, but unsafe as most other gcc options… they break here and there…
4th and yes, next thing to do is read /usr/src/Makefile to update and then dont forget to copy the kernel config GENERIC and tune it! its worth it i guess, and u dont need kernel modules usualy, select to not build these in make.conf and compile what u need and only that into your kernel.
5th, to buy a recent hard drive is a nice idea, coze its the todays system bottleneck in speed… if u have more than one hdd, set some swap to every drive instead of one, and split the partitions over the discs… though, if u have enough ram, most things loaded will remain there buffered…
While I don’t really think the article is that good for optimizing FreeBSD for performance, I think that some of the comments after the article do help it a lot. I think that just getting a bunch of the junk out of the kernel that isn’t used helps significantly, along with not running KDE, at least in my experiences.
There is a number of reasons why I decided to write an article about how to setup a FreeBSD desktop. One of the reasons is the article on “Open For Business” called “Desktop FreeBSD: Fully Optimized 6.x Installation”. While I agree with the author on s…
Trackback from Igor’s blog - Oct 24, 2006 | 16:39:45
vermaden, I think he is trying to say, Gentoo is the OS that gets that kind of optimization hype. FreeBSD is more often just run with the defaults. I have never optimized any FreeBSD compile. It always works good and fast.
Yes but this is WHOLE ARTICLE about FreeBSD Optimization, so author should list ANY optimizations IF they are avialable. I do not care what people use in their FreeBSD setups, I just mentioned what author does not and should mention.
Both the original article and the comments are most useful! I doubt whether further-going optimizations or ‘leave-outs’ will provide noticeable difference in performance. On the other hand, optimizing that way, you may be confronted with problems due to missing components later.
With respect to the ‘Firefox versus Opera’ dispute, there can be no doubt that Opera is as free as Firefox (though not Open Source, but let’s be honest, very few of us really take advantage of that!) and also faster, safer and smaller than Firefox (especially if you take all those often otherwise unneeded depencies into account!). So, on an ‘optimized’ system, Opera certainly deserves its place.
(I have both installed on my FreeBSD 6.1 system, because Firefox used to be somewhat better in dealing with MS/IE deviations from the standards.)
Something similar applies for the standard ‘Office’ applications: if you want a really fast and small package, install Textmaker/Planmaker (from Softmaker.com) instead of Openoffice.org. You have to pay for it, although not too much, but you get applications that surpass Openoffice.org in features, speed of operation, size and MS Office compatibility.
Why not take DesktopBSD or PC-BSD? Don’t understand this article.
>though not Open Source, but let’s be honest, very few of us really take advantage of that!
Let’s be honest, this attitude isn’t true in *BSD. The majority of *BSD users participates in open source in many ways.
>Something similar applies for the standard ‘Office’ applications:
Abiword is an alternative too, some people actually write their thesis for university with it
If a Ph.D. student in history is able to cope with LaTex, well something is really wrong with this so-called "ready for desktop". Don't read a howto, test it yourself and you'll see what's your desktop
Why not take DesktopBSD or PC-BSD? Don’t understand this article.
>though not Open Source, but let’s be honest, very few of us really take advantage of that!
Let’s be honest, this attitude isn’t true in *BSD. The majority of *BSD users participates in open source in many ways.
>Something similar applies for the standard ‘Office’ applications:
Abiword is an alternative too, some people actually write their thesis for university with it
If a Ph.D. student in history is able to cope with LaTex, well something is really wrong with this so-called "ready for desktop". Don't read a howto, test it yourself and you'll see what's your desktop
Here is a story. The leaders of a church have a personal agenda against someone and
want to quiet him, exact revenge or what have you. They not only come at him
within their church, they continue by following him outside of that church to any
other church he seeks refuge at and any place he works, making a wreck of his life in
the process. That is the sort of thing that only happened in the past, in dusty tales of
witch-hunts in Salem or the Inquisition in Spain, right? Wrong: it is happening today,
perhaps at a seemingly normal church near you.
Open for Business strives to serve up the most interesting, relevant content possible; however,
we can only do so with your help. Please take a few moments to fill out our
online survey
so that we can learn more about the interests of our readers, readers such as you.
Tap the Power of Snow Leopard
Looking to get acquainted with Apple's latest operating system?
Mac OS X Snow Leopard Bible,
the definitive Mac OS X reference, features OFB's
own Timothy R. Butler alongside Galen Gruman and Mark Hattersley.