I.2 Open Source Software

First, what is Open Source? What does that mean? Open Source means that, unlike most of the software you might buy shrink-wrapped down at Joe Bob's Computer Hut, you have access to the raw source code ”the human-readable C, C++, Perl, etc. ”files that get compiled down into the binary that is executed by the computer. This executable binary ”.exe ”is all you get from closed-source proprietary sources. Should you so desire , you can view the source files to see why that darn error message keeps popping up, or how to make that widget default to a different directory, or how to add a cool new function. Once you start looking at the source, you've started down the path of becoming an Open Source programmer. That's the beauty of Open Source.

You can make changes and submit them for others to look at. You can design a new widget to emulate a feature or a program that you liked on a different system, or to do something entirely new because you, using the available Open Source software, can look at the code that drives Linux , or Apache , or the Gimp , or Open Office , or Mozilla . You can write code to use it, to improve it, to hook to it, and/or to make it do almost anything else. Then changes can be shared with others as they did with you; with Open Source it's not only OK to copy, to improve, to use, and to return the source code to the community of users, but it is expected.

You may never do this; you may use Linux and Apache and Perl and never look at a line of code, never change a default in a configuration file. But, you could if you wanted to ”you don't have to live with what someone else decided is best.

The philosophy of Open Source software, among other things, is that many hands and eyes make for good software, unlike too many cooks spoiling the broth. Bugs are more likely to be caught, and more important, fixed, if everyone has access to the source. As in cryptography, closed systems cannot be proved to be free of flaws or errors. While it's no guarantee that no bugs exist, open systems can be examined for flaws; closed systems can only be tested against known bugs (security through obscurity). It's the unknown unknowns that can bite you. ^[4]

^[4] Unknown unknowns are the problems that you don't even know about. When you start something new, you know that some things are going to be a problem and can anticipate other things that could be a problem. But then there are the "unknown unknowns" ”the problems you aren't even aware of until they jump up and bite you, usually with customers standing in the room during a demo. One of the best engineers we ever knew, Duane Sanner, called them "unk-unks."

As anyone who's ever participated in design or code review knows , only by getting other people to look at your system or code have you any hope of finding the bugs ”everyone has blind spots. The more eyes that look at the source, the better. With Open Source, it isn't just a few people in a suburb east of Seattle who eyeball the code, but hundreds if not thousands of people all over the world. When, not if, a bug is discovered , anyone can fix it without depending on a software company to do a cost analysis of whether to issue a new free service pack or to include the update in the next dot revision and charge $99.95 for it.

Another tenet of the Open Source philosophy is giving back to the community. Most Open Source software falls under some form of a license. The various Open Source licenses are listed at www.opensource.org. Among others, the GPL (www.gnu.org/copyleft/gpl.html), LGPL (www.gnu.org/ copyleft /lesser.html), or one of the BSD licenses (www.opensource.org/licenses/bsd-license.html). ^[5] Most of these require that, if you redistribute the code, any Open Source software changes be committed back to the community; some are stricter than others. This isn't to say that you can't make money using your Open Source code, but simply that it's only good manners if you take advantage of all the work others have freely given you to build on that you freely return your changes and improvements to the community. Of course, if you keep it for just personal use, you can make any changes you want to any Open Source code. If you want to redistribute your changes, however, the revisions should be Open Source. This is mandatory with the GPL, and good manners with most others.

^[5] For a comparison of the various licenses, see zooko.com/license_quick_ref.html.

I.2.1 It's All Based on Open Source

Many of the programs on which the Internet was built are Open Source: Sendmail, Apache, BIND. Before anyone espoused Open Source as a concept, the programmers who built the Internet wrote cool software to do useful stuff ”e-mail, TCP/IP, the Web ”and shared the source code freely with others to maintain, to improve, and to impress their peers with the coolness of their hacks.

We mean hack in the original sense of the word, exemplified by the HAKMEM (www. tuxedo .org/~esr/jargon/html/entry/HAKMEM.html), that hacking is what good programmers do when solving problems on their own systems, and cracking is what people with less-than -pure motives do to other people's computers without regard for the consequences to anyone other than themselves . This is an important distinction, which has unfortunately been blurred by sensationalism and ignorance, but one that we'll maintain in this book.

I.2.2 There's a Disclaimer

Of course, no rose is without its thorns, and the Open Source model is not without its drawbacks. There may or may not be support for the software you wish to use. The only documentation might be the source. Your platform or hardware may or may not be supported. This gets better every day, but it means you have to do research. That said, not every device is supported by Apple or Microsoft either, so you still have to do research. Caveat emptor .

Some Open Source companies provide technical support for a fee, but with many programs and distributions, it's up to the administrator (you) to check for updates; be aware of security bugs by following Bugtraq (www.securityfocus.com), or the program's web site, or Slashdot (www.slashdot.org); and upgrading when necessary. Then again, some people might consider being vigilant about maintaining their computer a good thing, no matter what the operating system.

At the basic level, you are your own sysadmin and webmaster ”you are responsible for watching logs, maintenance, dealing with problems. You may have to roll your own software; configure it for your system, which may not be the same as the default; and actually have to RTFM. ^[6] The documentation that you get may be out of date or inaccurate; but, then, all these drawbacks are also inherent in closed-source software ”you can't just turn your computer on and ignore security updates, patches, and upgrades. The nicely formatted and printed documentation is often wrong and/or out of date. Generally , the patches and upgrades come at a price, either dollars or time.

^[6] If you don't know what RTFM means, then RTFM (www.tuxedo.org/~esr/jargon/html/entry/RTFM.html). Use this site to figure out what RTFM means. There's lots of other great stuff in the Jargon files. This is a great place to go to learn computer history a little bit at a time.

You may not be able to run all of the applications that you can use on your Windows or Mac system, although we've found that there are translators, emulators, or equivalents for most things. ^[7] For us, this has not been a limitation in Linux, even though sometimes it is a timesink. It is not a limitation that closed-source systems are immune to however. One of this book's authors spent hours while writing this trying to convince one Mac program to read in data from another, and more hours installing an FTP server on a Windows NT box so that he could copy large amounts of data without transferring it to an intermediate medium ”no FTP server installed by default!? And, there's no native secure copy at all.

^[7] We have a special fondness for VMware (www.vmware.com) and Mac-on-Linux (www.maconlinux.org); we were much fonder of the former when they had a personal use price of $75 instead of $400, and OS X has largely obviated the need for the latter. The WINE project (www.winehq.com) is another attempt to be able to run Windows programs on Linux, but it isn't there yet even though the price is right.

It's also the norm in Linux to install and to upgrade software without having to reboot, and for systems to be inherently stable ”no blue screen of death, no bombs , no control-alt-delete three-fingered Vulcan mind grips. Linux uptimes typically run in months, and the limiting factor is quite possibly your connection to the wall (in California, due to rolling blackouts; in Illinois, due to three kids playing around the server). Not to say you won't ever have to reboot or that your machine won't lock up, but, in our experience, it's much rarer. ^[8] Mostly, we have to reboot our machines only when we feel like trying out a new kernel.

^[8] Windows 2000 and XP have much better track records in this regard than previous versions, although we still find them less stable than Linux or OS X.

You may also have to deal with some bias. If you have to answer to an IT manager, or your nontechnical spouse, you may have some explaining to do if you want to run Linux and everyone else is running Windows. But that isn't a bad thing. You should have good reasons for going Open Source, or at least reasons.

I.2.3 It's Not Just for Linux

Although the focus here is on Linux and how LAMP programs interact with Linux, much of this is directly applicable to many operating systems, especially Unix variants ( * nix). For the most part, the configurations are independent of the platform, and this software runs on many platforms. If you run Solaris on Sun, or YDL on PPC, or OS X on a Mac, or any version of BSD, many of the things we talk about here are generally applicable to your system. The information here should be useful not only to the Linux user but also for most * nix users. In fact, this book was written on Apple PowerBook G4 laptops using BSD Unix-based OS X, an Apple G4 running LinuxPPC, and several different x86s running Red Hat 7.

This book was written entirely with Open Source software: emacs, vi, LaTeX, CVS, Ghostview, xdvi, ps2pdf, xpdf, and dvipdf on Linux and OS X. Frankly we couldn't imagine writing something of this length and complexity in Word. Shudder!

The HTML files and programs located at www.opensourcewebbook.com were developed concurrently on an x86 laptop running Red Hat 7.2 and a dual Pentium 450MHz server running Red Hat 7.2 using vi, SSH, and all the technologies we discuss in this book. That's another beauty of Open Source ”given most any * nix system, one can use CVS, SSH, emacs, vi, and LaTeX to work on a huge document anywhere .