In the Beginning...Was the Command Line (7 page)

BOOK: In the Beginning...Was the Command Line
9.84Mb size Format: txt, pdf, ePub
ads

Unix has always lurked provocatively in the background of the operating system wars, like the Russian Army. Most people know it only by reputation, and its reputation, as the
Dilbert
cartoon suggests, is mixed. But everyone seems to agree that if it could only get its act together and stop surrendering vast tracts of rich agricultural land and hundreds of thousands of prisoners of war to the onrushing invaders, it could stomp them (and all other opposition) flat.

It is difficult to explain how Unix has earned this respect without going into mind-smashing technical detail. Perhaps the gist of it can be explained by telling a story about drills.

The Hole Hawg is a drill made by the Milwaukee Tool Company. If you look in a typical hardware store you may find smaller Milwaukee drills, but not the Hole Hawg, which is too powerful and too expensive for homeowners. The Hole Hawg does not have the pistol-
like design of a cheap homeowner’s drill. It is a cube of solid metal with a handle sticking out of one face and a chuck mounted in another. The cube contains a disconcertingly potent electric motor. You can hold the handle and operate the trigger with your index finger, but unless you are exceptionally strong, you cannot control the weight of the Hole Hawg with one hand; it is a two-hander all the way. In order to fight off the counter-torque of the Hole Hawg, you use a separate handle (provided), which you screw into one side of the iron cube or the other depending on whether you are using your left or right hand to operate the trigger. This handle is not a sleek, ergonomically designed item as it would be in a homeowner’s drill. It is simply a foot-long chunk of regular galvanized pipe, threaded on one end, with a black rubber handle on the other. If you lose it, you just go to the local plumbing supply store and buy another chunk of pipe.

During the eighties I did some construction work. One day, another worker leaned a ladder against the outside of the building that we were putting up, climbed up to the second-story level, and used the Hole Hawg to drill a hole through the exterior wall. At some point, the drill bit caught in the wall. The Hole Hawg, following its one and only imperative, kept going. It spun the worker’s body around like a rag doll, causing him to knock his own ladder down. Fortunately he kept his grip on the Hole Hawg, which remained lodged in the wall, and he simply dangled from it and shouted for help until someone came along and reinstated the ladder.

I myself used a Hole Hawg to drill many holes through studs, which it did as a blender chops cabbage. I also used it to cut a few six-inch-diameter holes through an old lath-and-plaster ceiling. I chucked in a new hole saw, went up to the second story, reached down between the newly installed floor joists, and began to cut through the first-floor ceiling below. Where my homeowner’s drill had labored and whined to spin the huge bit around, and had stalled at the slightest obstruction, the Hole Hawg rotated with the stupid consistency of a spinning planet. When the hole saw seized up, the Hole Hawg spun itself and me around, and crushed one of my hands between the steel pipe handle and a joist, producing a few lacerations, each surrounded by a wide corona of deeply bruised flesh. It also bent the hole saw itself, though not so badly that I couldn’t use it. After a few such run-ins, when I got ready to use the Hole Hawg, my heart actually began to pound with atavistic terror.

But I never blamed the Hole Hawg; I blamed myself. The Hole Hawg is dangerous because it does exactly what you tell it to. It is not bound by the physical limitations that are inherent in a cheap drill, and neither is it limited by safety interlocks that might be built into a homeowner’s product by a liability-conscious manufacturer. The danger lies not in the machine itself but in the user’s failure to envision the full consequences of the instructions he gives to it.

A smaller tool is dangerous too, but for a completely different reason: it tries to do what you tell it to, and fails in some way that is unpredictable and almost always
undesirable. But the Hole Hawg is like the genie of the ancient fairy tales, who carries out his master’s instructions literally and precisely and with unlimited power, often with disastrous, unforeseen consequences.

Pre-Hole Hawg, I used to examine the drill selection in hardware stores with what I thought was a judicious eye, scorning the smaller low-end models and hefting the big expensive ones appreciatively, wishing I could afford one of them babies. Now I view them all with such contempt that I do not even consider them to be real drills—merely scaled-up toys designed to exploit the self-delusional tendencies of soft-handed homeowners who want to believe that they have purchased an actual tool. Their plastic casings, carefully designed and focus-group tested to convey a feeling of solidity and power, seem disgustingly flimsy and cheap to me, and I am ashamed that I was ever bamboozled into buying such knicknacks.

It is not hard to imagine what the world would look like to someone who had been raised by contractors and who had never used any drill other than a Hole Hawg. Such a person, presented with the best and most expensive hardware-store drill, would not even recognize it as such. He might instead misidentify it as a child’s toy, or some kind of motorized screwdriver. If a salesperson or a deluded homeowner referred to it as a drill, he would laugh and tell them that they were mistaken—they simply had their terminology wrong. His interlocutor would go away irritated, probably feeling rather defensive about his basement full of cheap, dangerous, flashy, colorful tools.

Unix is the Hole Hawg of operating systems,
*
and Unix hackers—like Doug Barnes and the guy in the
Dilbert
cartoon and many of the other people who populate Silicon Valley—are like contractors’ sons who grew up using only Hole Hawgs. They might use Apple/Microsoft OSes to write letters, play video games, or balance their checkbooks, but they cannot really bring themselves to take these operating systems seriously.

Unix is hard to learn. The process of learning it is one of multiple small epiphanies. Typically you are just on the verge of inventing some necessary tool or utility when you realize that someone else has already invented it, and built it in, and this explains some odd file or directory or command that you have noticed but never really understood before.

For example, there is a command (a small program, part of the OS) called “whoami,” which enables you to ask the computer who it thinks you are. On a Unix machine, you are always logged in under some name—possibly even your own! What files you may work with, and what software you may use, depends on your identity. When I started out using Linux, I was on a nonnetworked machine in my basement, with only one user account, and so when I became aware of the whoami command it struck me as ludicrous. But once you are logged in as one person, you can temporarily switch over to a pseudonym in order to access different files. If your machine is on the Internet, you can log on to other com
puters, provided you have a user name and a password. At that point the distant machine becomes no different in practice from the one right in front of you. These changes in identity and location can easily become nested inside each other, many layers deep, even if you aren’t doing anything nefarious. Once you have forgotten who and where you are, the whoami command is indispensible. I use it all the time.

The file systems of Unix machines all have the same general structure. On your flimsy operating systems, you can create directories (folders) and give them names like Frodo or My Stuff and put them pretty much anywhere you like. But under Unix the highest level—the root—of the filesystem is always designated with the single character “/” and it always contains the same set of top-level directories:

 

/usr /etc /var /bin /proc /boot /home /root /sbin /dev /lib /tmp

 

Each of these directories typically has its own distinct structure of subdirectories. Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three- or four-letter nubbins, like stones smoothed by a river.

This is not the place to try to explain why each of the above directories exists and what is contained in them. At first it all seems obscure; worse, it seems deliberately
obscure. When I started using Linux, I was accustomed to being able to create directories wherever I wanted and to give them whatever names struck my fancy. Under Unix you are free to do that, of course (you are free to do anything), but as you gain experience with the system you come to understand that the directories listed above were created for the best of reasons and that your life will be much easier if you follow along. (Within /home, by the way, you have pretty much unlimited freedom.)

After this kind of thing has happened several hundred or thousand times, the hacker understands why Unix is the way it is, and agrees that it wouldn’t be the same any other way. It is this sort of acculturation that gives Unix hackers their confidence in the system and the attitude of calm, unshakable, annoying superiority captured in the
Dilbert
cartoon. Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product’ as it is a painstakingly compiled oral history of the hacker subculture. It is our
Gilgamesh
epic.

What made old epics like
Gilgamesh
so powerful and so long-lived was that they were living bodies of narrative that many people knew by heart, and told over and over again—making their own personal embellishments whenever it struck their fancy. The bad embellishments were shouted down, the good ones picked up by others, polished, improved and, over time, incorporated into the story. Likewise, Unix is known, loved, and understood by so many hackers that it can be re-created from scratch whenever someone needs it. This is very difficult to un
derstand for people who are accustomed to thinking of OSes as things that absolutely have to be created by a company and bought.

Many hackers have launched more or less successful reimplementations of the Unix ideal. Each one brings in new embellishments. Some of them die out quickly, some are merged with similar, parallel innovations created by different hackers attacking the same problem, others still are embraced and adopted into the epic. Thus Unix has slowly accreted around a simple kernel and acquired a kind of complexity and asymmetry that is organic, like the roots of a tree, or the branchings of a coronary artery. Understanding it is more like anatomy than physics.

For at least a year, prior to my adoption of Linux, I had been hearing about it. Credible, well-informed people kept telling me that a bunch of hackers had got together an implentation of Unix that could be downloaded, free of charge, from the Internet. For a long time I could not bring myself to take the notion seriously. It was like hearing rumors that a group of model-rocket enthusiasts had created a completely functional Saturn V by exchanging blueprints on the Net and mailing valves and flanges to each other.

But it’s true. Credit for Linux generally goes to its human namesake, one Linus Torvalds, a Finn who got the whole thing rolling in 1991 when he used some of the GNU tools to write the beginnings of a Unix kernel that could run on PC-compatible hardware. And indeed Torvalds deserves all the credit he has ever gotten, and a whole lot more. But he could not have made it happen
by himself, any more than Richard Stallman could have. To write code at all, Torvalds had to have cheap but powerful development tools, and these he got from Stallman’s GNU project.

And he had to have cheap hardware on which to write that code. Cheap hardware is a much harder thing to arrange than cheap software. A single person (Stallman) can write software and put it up on the Net for free, but in order to make hardware it’s necessary to have a whole industrial infrastructure, which is not cheap by any stretch of the imagination. Really the only way to make hardware cheap is to punch out an incredible number of copies of it, so that the unit cost eventually drops. For reasons already explained, Apple had no desire to see the cost of hardware drop. The only reason Torvalds had cheap hardware was Microsoft.

Microsoft refused to go into the hardware business, insisted on making its software run on hardware that anyone could build, and thereby created the market conditions that allowed hardware prices to plummet. In trying to understand the Linux phenomenon, then, we have to look not to a single innovator but to a sort of bizarre Trinity: Linus Torvalds, Richard Stallman, and Bill Gates. Take away any of these three and Linux would not exist.

Young Americans who leave their great big homogeneous country and visit some other part of the world typically go through several stages of culture shock: first, dumb wide-eyed astonishment. Then, a tentative engagement with the new country’s manners, cuisine, public transit systems, and toilets, leading to a brief period of fatuous confidence that they are instant experts on the new country. As the visit wears on, homesickness begins to set in, and the traveler begins to appreciate, for the first time, how much he or she took for granted at home. At the same time it begins to seem obvious that many of one’s own cultures and traditions are essentially arbitrary and could have been different; driving on the right side of the road, for example. When the traveler returns home and takes stock of the experience, he or she may have learned a good deal more about America than about the country they went to visit.

For the same reasons, Linux is worth trying. It is a strange country indeed, but you don’t have to live there; a brief sojourn suffices to give some flavor of the place
and—more importantly—to lay bare everything that is taken for granted, and all that could have been done differently, under Windows or MacOS.

You can’t try it unless you install it. With any other OS, installing it would be a straightforward transaction: in exchange for money, some company would give you a CD-ROM, and you would be on your way. But a lot is subsumed in that kind of transaction, and it has to be gone through and picked apart.

We like plain dealings and straightforward transactions in America. If you go to Egypt and, say, take a taxi somewhere, you become a part of the taxi driver’s life; he refuses to take your money because it would demean your friendship, he follows you around town, and weeps hot tears when you get in some other guy’s taxi. You end up meeting his kids at some point and have to devote all sorts of ingenuity to finding some way to compensate him without insulting his honor. It is exhausting. Sometimes you just want a simple Manhattan-style taxi ride.

But in order to have an American-style setup, where you can just go out and hail a taxi and be on your way, there must exist a whole hidden apparatus of medallions, inspectors, commissions, and so forth—which is fine as long as taxis are cheap and you can always get one. When the system fails to work in some way, it is mysterious and infuriating and turns otherwise reasonable people into conspiracy theorists. But when the Egyptian system breaks down, it breaks down transparently. You can’t get a taxi, but your driver’s nephew will show up, on foot, to explain the problem and apologize.

Microsoft and Apple do things the Manhattan way, with vast complexity hidden behind a wall of interface. Linux does things the Egypt way, with vast complexity strewn about all over the landscape. If you’ve just flown in from Manhattan, your first impulse will be to throw up your hands and say, “For crying out loud! Will you people get a grip on yourselves!?” But this does not make friends in Linux-land any better than it would in Egypt.

You can suck Linux right out of the air, as it were, by downloading the right files and putting them in the right places, but there probably are not more than a few hundred people in the world who could create a functioning Linux system in that way. What you really need is a distribution of Linux, which means a prepackaged set of files. But distributions are a separate thing from Linux per se.

Linux per se is not a specific set of ones and zeroes, but a self-organizing Net subculture. The end result of its collective lucubrations is a vast body of source code, almost all written in C (the dominant computer programming language). “Source code” just means a computer program as typed in and edited by some hacker. If it’s in C, the file name will probably have .c or .cpp on the end of it, depending on which dialect was used; if it’s in some other language, it will have some other suffix. Frequently these sorts of files can be found in a directory with the name /src, which is the hacker’s Hebraic abbreviation of “source.”

Source files are useless to your computer, and of little
interest to most users, but they are of gigantic cultural and political significance, because Microsoft and Apple keep them secret while Linux makes them public. They are the family jewels. They are the sort of thing that in Hollywood thrillers is used as a McGuffin: the plutonium bomb core, the top-secret blueprints, the suitcase of bearer bonds, the reel of microfilm. If the source files for Windows or MacOS were made public on the Net, then those OSes would become free, like Linux—only not as good, because no one would be around to fix bugs and answer questions. Linux is “open source” software, meaning simply, anyone can get copies of its source code files.

Your computer doesn’t want source code any more than you do; it wants object code. Object code files typically have the suffix .o and are unreadable to all but a few, highly strange humans, because they consist of ones and zeroes. Accordingly, this sort of file commonly shows up in a directory with the name /bin, for “binary.”

Source files are simply ASCII text files. ASCII denotes a particular way of encoding letters into bit patterns. In an ASCII file, each character has eight bits all to itself. This creates a potential “alphabet” of 256 distinct characters, in that eight binary digits can form that many unique patterns. In practice, of course, we tend to limit ourselves to the familiar letters and digits. The bit-patterns used to represent those letters and digits are the same ones that were physically punched into the paper tape by my high school teletype, which in turn were the same ones used by the telegraph industry for decades previously. ASCII text files, in other words, are telegrams, and as such they have no
typographical frills. But for the same reason they are eternal, because the code never changes, and universal, because every text-editing and word-processing software ever written knows about this code.

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 contrac
tion 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.

BOOK: In the Beginning...Was the Command Line
9.84Mb size Format: txt, pdf, ePub
ads

Other books

High Energy by Dara Joy
Guarding Me by Slayer, Megan
More Than Friends by Jess Dee
Simply Organic by Jesse Ziff Coole
Captive Secrets by Fern Michaels
The Dark Affair by Máire Claremont
Chewing Rocks by Alan Black
Bye Bye Blondie by Virginie Despentes