Chapter 10: Making Your System Useful

Overview

Unlike operating systems such as Microsoft Windows and Red Hat Linux, which tend to throw absolutely anything you might need into the base install, BSD systems are sparse—and that's a good thing.

For example, a Windows 2000 Professional system I'm using at a client site, with a "minimal" setup, has 1,768 items in its main system directory (C:/WINNT/system32), and just about every shared library (aka DLL, or dynamic−link library) ever. Whenever I boot the system, these DLLs are all loaded into the system memory. I don't know what each DLL is for, but I guarantee that I will never use many of them—the only software I use on that machine is SSH and Mozilla. All they do for me is soak up RAM.

This is, of course, Microsoft's approach to operating systems—give ’em everything you've got, and I mean everything. In contrast, Red Hat Linux installs a similar amount of stuff, but much of it is actual programs. You might never use most of those programs, but at least all those files aren't automatically loaded into the system memory at boottime.

A basic BSD install, however, gives you exactly enough to make the system run, plus a few extra bits that have been traditionally included with UNIX systems. You get to choose during setup whether to install additional programs or source code. However, even a complete, running BSD install takes far less disk space than the Windows 2000 system32 directory mentioned previously—the complete FreeBSD install includes far less than Windows. A Windows install that only supported SSH and Mozilla would be much smaller and simpler—in fact, it would look a lot more like a FreeBSD install.

The advantage to this sparseness is that it gives you only what you need for your system. This makes debugging a problem much simpler and helps to ensure that some shared library you've never even heard of, and would never use, won't break your system. The downside is that you may need to do a bit of thinking to determine what it is that you do need, and you'll have to install those extra, but necessary, programs. FreeBSD solves that problem by making software installation as simple as possible.

Making Software

Building software is complicated because source code must be treated in a very specific manner to create a workable, running binary—let alone an optimized one!

While programmers could include installation instructions with each program, full of lines like "Now type cc CPUTYPE=i686 −ohttpd −I/usr/src/crypto/kerberosIV/include −lcrypto −lkrb," they don't. Programmers don't put up with this sort of garbage for long. If it can be automated, it will be, which is a good thing for those of us who need to install programs.

The main tool for building software is make(1). Make looks for a file called Makefile in the current directory, which is full of instructions much like that horrid example in the previous paragraph. When it finds the Makefile, make reads the instructions and carries them out. Makefiles are long and complicated creatures, and you don't really have to know their internals, so we're not going to dissect one here.

223

Each Makefile includes various targets, or types of instructions to carry out. For example, make install tells make to check the Makefile for a procedure called "install". If make finds such a procedure, it will execute it. Each target contains one basic step in building, installing, or configuring the software. We'll discuss various common make targets in this chapter, and when to use them.

Make can handle a huge variety of functions, some of which far outstrip the original intentions of the creators. But that's what UNIX is for, isn't it?

Note Be sure that you're in the same directory as the Makefile when you run make. While this isn't strictly necessary, it will make your life simpler.

The Pain and Pleasure of Source Code

Source code is the human−readable instructions for building the actual machine code that makes up a program. You might have already been exposed to source code in some form. If you've never seen source code, take a look at the various files under /usr/src.

While you don't have to be able to read source code, you should be able to recognize it two out of three times. Here's a snippet of source code from FreeBSD's network stack:

...............................................................................................

/* While we overlap succeeding segments trim them or, * if they are completely covered, dequeue them.

*/

while (q) {

register int i = (th−>th_seq + *tlenp) − q−>tqe_th−>th_seq; if (i <= 0)

break; if (i < q−>tqe_len) {

q−>tqe_th−>th_seq += i; q−>tqe_len −= i; m_adj(q−>tqe_m, i); break;

}

...............................................................................................

Once you have the source code for a program, installing it is pretty straightforward. You build (or compile) the program on the system you want to run it on.[1] If the program was written for an

operating system that is sufficiently similar to the platform you're building it on, it should work. If your platform is too different from the original, it will fail. Once you've built the software successfully on your platform, you can copy the resulting program (or binary) to other identical platforms, and it should run.

Some programs are written well enough that they can be compiled on many different platforms. A few programs specifically include support for widely divergent platforms; for example, the Apache Web server can be compiled on both Windows and UNIX just by typing make install. This is quite uncommon, however, and represents a truly heroic effort by the software authors.

Note While you can copy a compiled program to a foreign system and try to run it, this is generally doomed to fail. In most cases, one operating system cannot out−of−the−box run programs for another operating system. (FreeBSD can, with some configuration; see Chapter 11.)

224