Therefore just about any software can be used to create, edit, and read source code files. Object code files, then, are created from these source files by a piece of software called a compiler, and forged into a working application by another piece of software called a linker.
The triad of editor, compiler, and linker, taken together, form the core of a software development system. Now, it is possible to spend a lot of money on shrink-wrapped development systems with lovely graphical user interfaces and various ergonomic enhancements. In some cases it might even be a good and reasonable way to spend money. But on this side of the road, as it were, the very best software is usually the free stuff. Editor, compiler, and linker are to hackers what ponies, stirrups, and archery sets were to the Mongols. Hackers live in the saddle and hack on their own tools, even while they are using them, to create new applications. It is quite inconceivable that superior hacking tools could have been created from a blank sheet of paper by product engineers. Even if they are the brightest engineers in the world, they are simply outnumbered.
In the GNU/Linux world, there are two major text-editing programs: the minimalist vi (known in some implementations as elvis) and the maximalist emacs. I use emacs, which might be thought of as a thermonuclear word processor. It was created by Richard Stallman; enough said. It is written in Lisp, which is the only computer language that is beautiful. It is colossal, and yet it only edits straight ASCII text files, which is to say, no fonts, no boldface, no underlining. In other words, the engineer-hours that, in the case of Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text. If you are a professional writer—i.e., if someone else is getting paid to worry about how your words are formatted and printed—emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. For page layout and printing you can use TeX: a vast corpus of typesetting lore written in C and also available on the Net for free.
I could say a lot about emacs and TeX, but right now I am trying to tell a story about how to actually install Linux on your machine. The hard-core survivalist approach would be to download an editor like emacs, and the GNU Tools—the compiler and linker—which are polished and excellent to the same degree as emacs. Equipped with these, one would be able to start downloading ASCII source code files (/src) and compiling them into binary object code files (/bin) that would run on the machine. But in order to even arrive at this point—to get emacs running, for example—you have to have Linux actually up and running on your machine. And even a minimal Linux operating system requires thousands of binary files all acting in concert, and arranged and linked together just so.
Several entities have therefore taken it upon themselves to create “distributions” of Linux. If I may extend the Egypt analogy slightly, these entities are a bit like tour guides who meet you at the airport, who speak your language, and who help guide you through the initial culture shock. If you are an Egyptian, of course, you see it the other way; tour guides exist to keep brutish outlanders from traipsing through your mosques and asking you the same questions over and over and over again.*
Some of these tour guides are commercial organizations, such as Red Hat Software, which makes a Linux distribution called Red Hat that has a relatively commercial sheen to it. In most cases you put a Red Hat CD-ROM into your PC and reboot and it handles the rest. Just as a tour guide in Egypt will expect some sort of compensation for his services, commercial distributions need to be paid for. In most cases, they cost almost nothing and are well worth it.
I use a distribution called Debian† . (the word is a contraction of “Deborah” and “Ian”) which is noncommercial. It is organized (or perhaps I should say “it has organized itself”) along the same lines as Linux in general, which is to say that it consists of volunteers who collaborate over the Net, each responsible for looking after a different chunk of the system. These people have broken Linux down into a number of packages, which are compressed files that can be downloaded to an already functioning Debian Linux system, then opened up and unpacked using a free installer application. Of course, as such, Debian has no commercial arm—no distribution mechanism. You can download all Debian packages over the Net, but most people will want to have them on a CD-ROM. Several different companies have taken it upon themselves to decoct all of the current Debian packages onto CD-ROMs and then sell them. I buy mine from Linux Systems Labs. The cost for a three-disk set, containing Debian in its entirety, is less than three dollars. But (and this is an important distinction) not a single penny of that three dollars is going to any of the coders who created Linux, nor to the Debian packagers. It goes to Linux Systems Labs and it pays not for the software or the packages but for the cost of stamping out the CD-ROMs.
Every Linux distribution embodies some more or less clever hack for circumventing the normal boot process and causing your computer, when it is turned on, to organize itself not as a PC running Windows but as a “host” running Unix. This is slightly alarming the first time you see it, but completely harmless. When a PC boots up, it goes through a little self-test routine, taking an inventory of available disks and memory, and then begins looking around for a disk to boot up from. In any normal Windows computer that disk will be a hard drive. But if you have your system configured right, it will look first for a floppy or CD-ROM disk, and boot from that if one is available.
Linux exploits this chink in the defenses. Your computer notices a bootable disk in the floppy or CD-ROM drive, loads in some object code from that disk, and blindly begins to execute it. But this is not Microsoft or Apple code, this is Linux code, and so at this point your computer begins to behave very differently from what you are accustomed to. Cryptic messages began to scroll up the screen. If you had booted a commercial OS, you would, at this point, be seeing a “Welcome to MacOS” cartoon, or a screen filled with clouds in a blue sky and a Windows logo. But under Linux you get a long telegram printed in stark white letters on a black screen. There is no “Welcome!” message. Most of the telegram has the semi-inscrutable menace of graffiti tags.
Dec 14 15:04:15 theRev syslogd 1.3-3#17: restart. Dec 14 15:04:15 theRev kernel: klogd 1.3-3, log source = /proc/kmsg started. Dec 14 15:04:15 theRev kernel: Loaded 3535 symbols from /System.map. Dec 14 15:04:15 theRev kernel: Symbols match kernel version 2.0.30. Dec 14 15:04:15 theRev kernel: No module symbols loaded. Dec 14 15:04:15 theRev kernel: Intel Multiprocessor Specification v1.4 Dec 14 15:04:15 theRev kernel: Virtual Wire compatibility mode. Dec 14 15:04:15 theRev kernel: OEM ID: INTEL Product ID: 440FX APIC at: OxFEE00000 Dec 14 15:04:15 theRev kernel: Processor #0 Pentium(tm) Pro APIC version 17 Dec 14 15:04:15 theRev kernel: Processor #1 Pentium(tm) Pro APIC version 17 Dec 14 15:04:15 theRev kernel: I/O APIC #2 Version 17 at OxFEC00000. Dec 14 15:04:15 theRev kernel: Processors: 2 Dec 14 15:04:15 theRev kernel: Console: 16 point font, 400 scans Dec 14 15:04:15 theRev kernel: Console: colour VGA+ 80x25, 1 virtual console (max 63) Dec 14 15:04:15 theRev kernel: pcibios_init: BIOS32 Service Directory structure at 0x000fdb70 Dec 14 15:04:15 theRev kernel: pcibios init: BIOS32 Service Directory entry at 0xfdb80 Dec 14 15:04:15 theRev kernel: pcibios_init: PCI BIOS revision 2.10 entry at Oxfdbal Dec 14 15:04:15 theRev kernel: Probing PCI hardware. Dec 14 15:04:15 theRev kernel: Warning: Unknown PCI device (10b7:9001). Please read include/linux/pci.h Dec 14 15:04:15 theRev kernel: Calibrating delay loop…Ok-179.40 BogoMIPS Dec 14 15:04:15 theRev kernel: Memory: 64268k/66556k available (700k kernel code, 384k reserved, 1204k data) Dec 14 15:04:15 theRev kernel: Swansea University Computer Society NET3.035 for Linux 2.0 Dec 14 15:04:15 theRev kernel: NET3: Unix domain sockets 0.13 for Linux NET3.035. Dec 14 15:04:15 theRev kernel: Swansea University Computer Society TCP/IP for NET3.034 Dec 14 15:04:15 theRev kernel: IP Protocols: ICMP, UDP, TCP Dec 14 15:04:15
theRev kernel: Checking 386/387 coupling…Ok, fpu using exception 16 error reporting. Dec 14 15:04:15 theRev kernel: Checking ‘hit’ instruction…Ok. Dec 14 15:04:15 theRev kernel: Linux version 2.0.30 (root@theRev) (gcc version 2.7.2.1) #15 Fri Mar 27 16:37:24 PST 1998 Dec 14 15:04:15 theRev kernel: Booting processor 1 stack 00002000: Calibrating delay loop…ok-179.40 BogoMIPS Dec 14 15:04:15 theRev kernel: Total of 2 processors activated (358.81 BogoMIPS). Dec 14 15:04:15 theRev kernel: Serial driver version 4.13 with no serial options enabled Dec 15:04:15 theRev kernel: tty00 at 0x03f8 (irq = 4) is a 16550A Dec 14 15:04:15 theRev kernel: ttyOl at0x02f8 (irq = 3) is a 16550A Dec 14 15:04:15 theRev kernel: Ipl at 0x0378, (polling) Dec 14 15:04:15 theRev kernel: PS/2 auxiliary pointing device detected—driver installed. Dec 14 15:04:15 theRev kernel: Real Time Clock Driver vl .07 Dec 14 15:04:15 theRev kernel: loop: registered device at major 7 Dec 14 15:04:15 theRev kernel: ide: i82371 PIIX (Triton) on PCI bus 0 function 57 Dec 14 15:04:15 theRev kernel: ide0: BM-DMA at 0xffa0-0xffa7 Dec 14 15:04:15 theRev kernel: ide1: BM-DMA at 0xffa8-0xffaf Dec 14 15:04:15 theRev kernel: hda: Conner Peripherals 1275MB-CFS1275A, 1219MB w/64kB Cache, LBA, CHS=619/64/63 Dec 14 15:04:15 theRev kernel: hdb: Maxtor 84320A5, 4119MB w/256kB Cache, LBA, CHS=8928/15/63, DMA Dec 14 15:04:15 theRev kernel: hdc:, ATAPI CDROM drive Dec 15 11:58:06 theRev kernel: ide0 at 0xlf0-0xlf7,0x3f6 on irq 14 Dec 15 11:58:06 theRev kernel: idel at 0x170-0x177,0x376 on irq 15 Dec 11:58:06 theRev kernel: Floppy drive(s): fd0 is 1.44M Dec 15 11:58:06 theRev kernel: Started kswapd v 1.4.2.2 Dec 15 11:58:06 theRev kernel: FDC 0 is a National Semiconductor PC87306 Dec 15 11:58:06 theRev kernel: md driver 0.35 MAX_MD_DEV=4, MAX_REAL=8 Dec 15 11:58:06 theRev kernel: PPP: version 2.2.0 (dynamic channel allocation) Dec 15 11:58:06 theRev kernel: TCP compression code copyright 1989 Regents of the University of California Dec 15 11:58:06 theRev kernel: PPP Dynamic channel allocation code copyright 1995 Caldera, Inc. Dec 15 11:58:06 theRev kernel: PPP line discipline registered. Dec 15 11:58:06 theRev kernel: SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256). Dec 15 11:58:06 theRev kernel: eth0: 3Com 3c900 Boomerang 10Mbps/Combo at 0xef00, 00:60:08:a4:3c:db, IRQ 10 Dec 15 11:58:06 theRev kernel: 8K word-wide RAM 3:5 Rx:Tx split, 10base2 interface. Dec 15 11:58:06 theRev kernel: Enabling bus-master transmits and whole-frame receives. Dec 15 11:58:06 theRev kernel: 3c59x.c:v0.49 1/2/98 Donald Becker http: cesdis.gsfc.nasa.gov/linux/drivers/vortex.html Dec 15 11:58:06 theRev kernel: Partition check: Dec 15 11:58:06 theRev kernel: hda: hda1 hda2 hda3 Dec 15 11:58:06 theRev kernel: hdb: hdb1 hdb2 Dec 15 11:58:06 theRev kernel: VFS: Mounted root (ext2 filesystem) readonly. Dec 15 11:58:06 theRev kernel: Adding Swap: 16124k swap-space (priority-1) Dec 15 11:58:06 theRev kernel: EXT2-fs warning: maximal mount count reached, running e2fsck is recommended Dec 15 11:58:06 theRev kernel: hdc: media changed Dec 15 11:58:06 theRev kernel: ISO9660 Extensions: RRIP_1991A Dec 15 11:58:07 theRev syslogd 1.3-3#l 7: restart. Dec 15 11:58:09 theRev diald[87]: Unable to open options file /etc/diald/diald.options: No such file or directory Dec 15 11:58:09 theRev diald[87]: No device specified. You must have at least one device! Dec 15 11:58:09 theRev diald[87]: You must define a connector script (option ‘connect’). Dec 15 11:58:09 theRev diald[87]: You must define the remote ip address. Dec 15 11:58:09 theRev diald[87]: You must define the local ip address. Dec 15 11:58:09 theRev diald[87]: Terminating due to damaged reconfigure.
The only parts of this that are readable, for normal people, are the error messages and warnings. And yet it’s noteworthy that Linux doesn’t stop, or crash, when it encounters an error; it spits out a pithy complaint, gives up on whatever processes were damaged, and keeps on rolling. This was decidedly not true of the early versions of Apple and Microsoft OSes, for the simple reason that an OS that is not capable of walking and chewing gum at the same time cannot possibly recover from errors. Looking for, and dealing with, errors requires a separate process running in parallel with the one that has erred. A kind of superego, if you will, that keeps an eye on all of the others and jumps in when one goes astray. Now that MacOS and Windows can do more than one thing at a time, they are much better at dealing with errors than they used to be, but they are not even close to Linux or other Unices in this respect, and their greater complexity has made them vulnerable to new types of errors.
FALLIBILITY, ATONEMENT, REDEMPTION, TRUST, AND OTHER ARCANE TECHNICAL CONCEPTS
Linux is not capable of having any centrally organized policies dictating how to write error messages and documentation, and so each programmer writes his own. Usually they are in English, even though tons of Linux programmers are Europeans. Frequently they are funny. Always they are honest. If something bad has happened because the software simply isn’t finished yet, or because the user screwed something up, this will be stated forth-rightly. The command line interface makes it easy for programs to dribble out little comments, warnings, and messages here and there. Even if the application is imploding like a damaged submarine, it can still usually eke out a little S.O.S. message. Sometimes when you finish working with a program and shut it down, you find that it has left behind a series of mild warnings and low-grade error messages in the command line interface window from which you launched it—as if the software were chatting to you about how it was doing the whole time you were working with it.
Documentation, under Linux, comes in the form of man (short for manual) pages. You can access these either through a GUI (xman) or from the command line (man). Here is a sample from the man page for a program called rsh:
Stop signals stop the local rsh process only; this is arguably wrong, but currently hard to fix for reasons too complicated to explain here.
The man pages contain a lot of such material, which reads like the terse mutterings of pilots wrestling with the controls of damaged airplanes. The general feel is of a thousand monumental but obscure struggles seen in the stop-action light of a strobe. Each programmer is dealing with his own obstacles and bugs; he is too busy fixing them, and improving the software, to explain things at great length or to maintain elaborate pretensions.
In practice you hardly ever encounter a serious bug while running Linux. When you do, it is almost always with commercial software (several vendors sell software that runs under Linux, and there is more available each month). The operating system and its fundamental utility programs are too important to contain serious bugs. I have been running Linux every day since late 1995 and have seen many application programs go down in flames, but I have never seen the operating system crash. Never. Not once. There are quite a few Linux systems that have been running continuously and working hard for months or years without needing to be rebooted.
Commercial OSes have to adopt the same official stance toward errors as Communist countries had toward poverty. For doctrinal reasons it was not possible to admit that poverty was a serious problem in Communist countries, because the whole point of Communism was to eradicate poverty. Likewise, commercial OS companies such as Apple and Microsoft can’t go around admitting that their software has bugs and that it crashes all the time, any more than Disney can issue press releases stating that Mickey Mouse is an actor in a suit.
This is a problem, because errors do exist and bugs do happen. Every few months Bill Gates tries to demo a new Microsoft product in front of a large audience only to have it blow up in his face. Commercial OS vendors, as a direct consequence of being commercial, are forced to adopt the grossly disingenuous position that bugs are rare aberrations, usually someone else’s fault, and therefore not really worth talking about in any detail. This posture, which everyone knows to be absurd, is not limited to press releases and ad campaigns. It informs the whole way these companies do business and relate to their customers. If the documentation were properly written, it would mention bugs, errors, and crashes on every single page. If the on-line help systems that come with these OSes reflected the experiences and concerns of their users, they would largely be devoted to instructions on how to cope with crashes and errors.
But this does not happen. Joint stock corporatio
ns are wonderful inventions that have given us many excellent goods and services. They are good at many things. Admitting failure is not one of them. Hell, they can’t even admit minor shortcomings.
Of course, this behavior is not as pathological in a corporation as it would be in a human being. Most people, nowadays, understand that corporate press releases are issued for the benefit of the corporation’s shareholders and not for the enlightenment of the public. Sometimes the results of this institutional dishonesty can be dreadful, as with tobacco and asbestos. In the case of commercial OS vendors it is nothing of the kind, of course; it is merely annoying.
Some might argue that consumer annoyance, over time, builds up into a kind of hardened plaque that can conceal serious decay, and that honesty might therefore be the best policy in the long run; the jury is still out on this in the operating system market. The business is expanding fast enough that it’s still much better to have billions of chronically annoyed customers than millions of happy ones.
Most system administrators I know who work with Windows NT all the time agree that when it hits a snag, it has to be rebooted, and when it gets seriously messed up, the only way to fix it is to reinstall the operating system from scratch. Or at least this is the only way that they know of to fix it, which amounts to the same thing. It is quite possible that the engineers at Microsoft have all sorts of insider knowledge on how to fix the system when it goes awry, but if they do, they do not seem to be getting the message out to any of the actual system administrators I know.