[Seven factors that have historically led to the commission of war crimes:] (1) high friendly losses; (2) high turnover rate in the chain of command; (3) dehumanization of the adversary; (4) poorly trained or inexperienced troops; (5) the lack of a clearly defined adversary; (6) unclear orders; and (7) high frustration level among the troops.

Unlike Tommy Franks, the general whom Rumsfeld befriended and who won the war and left a disastrous peace behind as he went home to retire, Abizaid looks like someone who should be in charge. Happily, he is. Sort of.

A computer program is a set of explicit instructions for producing outgoing data as a result of incoming data. A computer can be a machine or a living thing. A small child rigorously indoctrinated by nuns in the basics of arithmatic could be a computer: the child can take as input a sequence of addition and subtraction programs and produce as output answers. However, the process of programming the child is inefficient and the program is generally not extractable from the child, so we would not think of children as useful programmable computers. Instead, a useful programmable computer can accept and execute a variety of different programs.

An executable computer program is a set of instructions that can be used in its current format by an actual computer. A book of arithmatic written in Basque is not an executable computer program for a typical child from Australia. Nor is a stack of IBM punch cards an executable program for a modern IBM Thinkpad laptop computer. Because most modern computers are binary digital computers, executable programs are typically sequences of binary data.

To be digital means to input and output and use internally digits, specific and invariant values. If the value of an input is continuously variable then the signal is analog. For example, if a signal is transmitted as a blow to the head, and the value of the signal is the amount of pain that it causes, then the signal is analog. The Second Law of Thermodynamics, the one about entropy, dictates that analog signals cannot be transmitted perfectly. For example, if you receive a blow to the head you cannot pass on the exact value of that signal - you cannot strike someone else, or even yourself, with exactly the same amount of force nor cause exactly the same amount of pain.

The magic of digital computing is that we can use analog devices to create a digital system. To do this, we define several values along a continuum, and round the analog input to the nearest value. If the typical variation is much less than the space between the intervals, the digital information is reliably transmitted. For example, we can define two signals in our system of blows to the head - painless and incapacitating. If each transmitter strikes with either as much or as little force as possible, but not at any force level inbetween, then it is easy to determine the value of the system at any point simply by examining the condition of the next recipient and rounding up or down. Because there are two possible values, the system is binary. And even though each transmission, each blow to the head, is an analog event, the system is digital because the digit is always one of two values, either unhurt or lying on the floor bleeding. All that is required for the system to be reliable is that no transmitter ever strike merely a glancing blow.

This system of course presents certain physical and ethical complications, and so modern computers instead use levels of voltage in a wire as their digits. In a five-volt system, a level close to zero volts is a value of zero and a level close to five volts is a one. A system with values of two or three volts is defective and should be returned with the receipt for a refund. (Aside: The clock cycle on a modern computer - for example, 1.5 Ghz, is the frequency with which this value can change and still be accurately detected. A 1.5 Ghz - gigahertz - computer changes the values in its wires 1,500,000,000 times per second, and so can do 1.5 billion calculations each second. Or rather, can pass values around 1.5 billion times per second. A value may need to pass through several or even dozens of logic gates to complete a calculation.)

The advantage of a digital system over an analog system is that it is precisely reproducible. This means that perfect copies - of data or of programs - can be made even though no single part of the system is perfect. While errors are always possible in any system with a basis in physical reality, the possibility of an error can be made arbitrarily close to zero through redundancy. If three digital copies are compared, at least two copies will always agree for any given digit, and the chance that two of three digital copies are wrong is much smaller than the chance that a single copy is wrong. But if three analog copies are compared, such as three phonograph records, at any given point there will always be three different values. So combining digital copies produces dramatic improvements in reliability whereas multiple analog copies produce much smaller benefits.

Modern electronic computers use binary digits, though more for historical reasons than laws of nature. We can easily imagine a digit with three values - a trinary system. In our blow-to-the-head system, for example, a value could be painless, incapacitating, or lethal. In our counting system, each digit has ten different values. Our genes are encoded with a quaternary system - each DNA digit consists of one of four different basepairs. While individual DNA strands decompose more or less continuously, systems of self-repair work fairly well - our bodies contain digital sequences that are precisely identical to sequences in organisms that diverged genetically from us millions and even hundreds of millions of years ago - strong evidence of both the copyability of digital information and the power of biology.

In order for a binary computer to execute a program, the program must be presented to the computer as a sequence of binary values. Early programmers did indeed write programs as sequences of ones and zeros - computers were programmed by flipping toggle switches up and down. Sequences of ones and zeros, when properly manipulated by computers, can be construed as instructions. This occurs through means that I won't detail here in large part because I don't remember or haven't learned them, though you can look up a dead British gentleman for proof. An instruction might be, "take two input digits, and if both are 1, output one. If both are 0, output zero. If one is 1 and the other is 0, output 0." This is called an AND, because it outputs 1 only if its first AND second output are 1. A startlingly small collection of these needlessly capitalized functions, such as OR and XOR, are in fact adequate building blocks for a staggeringly large set of computations, including everything that happens on your computer today. The majority of computers today are Turing computers, because their functions can be mathematically decomposed to a Turing State Machine, essentially the simplest possible binary computer.

Despite the popularity of the toggle method of programming, the majority of programming is done with abstractions called High-Level Languages. Instead of describing a sequence of binary operations to combine two numbers, including all of the logic necessary to convert numbers from human-input decimals to computer-readable binary values, and to handle values larger than 0 and 1, and to handle the possibility of negative numbers, and to handle the possibility of receiving as input something intended to be interpreted as a Japanese word for fruit instead of a number, a programmer writes something like "a = x + y".

While programmers write in high-level languages, this code must ultimately be converted into binary instructions so that they can be processed by the computer. This conversion is naturally performed by other programs. ANDs and ORs, although technically programs, are generally realized as transistors or combinations of several transistors. They are thus hardware programs - programs that are physically, permanently encoded into electronic computers. Computers have at least one more level of abstraction, called microcode. This consists of a few hundred more sophisticated instructions built from the logical functions. A typical microcode instruction might be, "Remember this number x until someone asks for it again, then forget it".

The collection of microcode instructions, called an "instruction set," is what defines a processor platform. In a typical situation, a programmer will then write a program, that is, a precise sequence of instructions for converting input values into output values, using this instruction set as a sort of alphabet. If the input is connected to, for example, an electric sensor, and the output to a motor or loudspeaker, the computer is now a kind of robot, perhaps an automatic door or a CD player. Once the program for this kind of computer is finalized and tested, it is permanently etched into a computer chip (a process that is much cheaper in bulk). This is called an embedded computer. Embedded computers make up the overwhelming majority of computers, somewhat reminiscent of the way that bacteria make up the overwhelming majority of life.

Desktops computers, however, are general-purpose programmable devices, and so must accept a variety of different programs. The lowest level of such a program must correspond to the underlying instruction set of the processor. The computer that is a 40 Mhz 80386 microchip from 1991 uses the same instruction set as the 4.77 Mhz 8086 chip in an IBM PC, and this is the same instruction set that a 1 Ghz Pentium III or Athlon uses. While an Athlon has hundreds of times more transistors than an 8086 and a radically different internal architecture, it still presents to the world essentially the same instruction set, called the x86 instruction set, as the original 8086. And thus programs which could be executed with an 8086 can also be executed, substantially faster, by an Athlon.

Such a program could not, however, be executed by the 6502 microchip in an Apple II. The 6502 instruction set is different from the x86 instruction set, and also different from the 68xxx instruction set in the 68000, 68010, and so forth, used by Apple Macintosh computers. And even though the NeXT computer uses a 68040 chip with the same instruction set as a Macintosh, Macintosh programs will not execute on a NeXT computer. The reason for this is the next level of abstraction, the operating system.

The operating system is a program that translates between the hardware and the rest of the software. In addition to the microchip that is the heart of a typical computer, other pieces of hardware, such as a video display chip or a hard drive, also contain microcode. In a desktop computer, the operating system converts the instruction set that the hardware understands to a more abstract, more universal set of functions. The operating system is an architectural convention, and other computers, such as the one in a CD player, wouldn't necessarily have one. In fact, the entire program for a CD player would typically be permanently etched into hardware in the form of a custom chip. A desktop computer, however, is a general-purpose computer and therefore needs to be able to accept different programs.

Recall that a computer program is a precise list of instructions to convert input into output. And recall that most programmers, even those working on embedded systems without sophisticated operating systems, do not write their instructions as sequences of binary digits or simple logic commands, but instead use high-level languages, producing lists of instructions called source code. There are several ways to convert source code into machine-executable programs. One is called compiling. When a program is compiled, another program called a compiler examines the source code and converts it into list of instructions that can be directly executed by the operating system or by the microcode in the chip. This new list of instructions, comprising mostly binary digits, is a binary executable. A binary executable is specific to a particular operating system, and so a binary which was compiled for Windows 3.1 cannot be executed by an Apple II. Sometimes such a binary cannot even be executed by a computer running Windows 3.0, because the different versions of the operating system are not very compatible.

Early computers were sold as hardware, with the software necessary to make them function included without additional charge much in the way that engines are included without additional charge in automobiles. This software was provided both as executable binaries and as source code. While Microsoft did not pioneer the practice of charging for software, they were the first to create a mass market specifically for software. When you buy a Microsoft program, you are buying a binary executable specific to some version of a Microsoft operating system, or sometimes to a Macintosh operating system. Eventually the operating system changes, and you are forced to buy new programs. While Microsoft is quite happy with this arrangement, many developers in the 1960s and 1970s who had not yet realized or were not personally attracted to the benefits of commercial software were troubled by the lack of portability of programs. They felt that a program written for one computer should be usable on another computer with a different instruction set or operating system.

The C language was the most successful attempt to accomplish this. A program written in the C language can be compiled on for any operating system that provides a specific minimum set of functions. The problem is that this minimum set is quite small, and the set of desirable functions increases as new hardware is invented and new uses are conceived. For example, a scanner must be controlled with a different set of functions than a printer.

In addition, programmers are deeply committed to the concept of code re-use. For example, a programmer may need to sort a list of word alphabetically. Because this is a very common need, the program to accomplish this has almost certainly already been written. These collections of programs that aren't directly useful in isolation but provide reusable functionality for other programs are called libraries. Depending on her mood and time to deadline, a programmer may find a library containing the sorting function she needs, or simply write a new sorting function and make it available as a library to others. Programmers love to write sorting functions.

An modern operating system thus consists of a kernel, which primarily handles coordination between other programs and between software and hardware, and many libraries. The Linux kernel in isolation is useless; the thing called linux which is compared to Microsoft Windows is actually the linux kernel packaged together with many libraries and other programs. The programming language C has accumulated a library called libc which provides many basic functions such as square roots. A typical linux distribution has hundreds of libraries, many of them quite obscure and only used by one or two programs - this occurs when a developer becomes convinced that her sorting function's 1% speed improvement and built-in support for French will compell all other developers on the planet to abandon the twenty years of testing and improvement represented by the standard library's sorting function and instead recode their programs to require her library instead.

Issues of both commercial greed and individual ego led to a web of incompatibilities in the Unix C world. In many ways these exceeded even Microsoft's wretched history of library incompatibilities, a history both exemplified by and climaxing with ODBC, version 2.5, I think, which in the summer of 1998 was available in three different, mutually incompatible versions distributed with three different Microsoft products by three different, rival Microsoft internal groups, such that installing any one of the products would tend to silently and untraceably break any program by any company that assumed the presence of one of the other two versions. I am not making this up - I experienced it first-hand and later heard the story from a Microsoft insider.

And so many people gave up on the idea of portable C programs that could be compiled on different platforms. Java is an attempt to solve this with another layer of abstraction. Instead of compiling source code into binary code and then passing the binary code to an operating system, Java interprets code. This means that Java code is converted to binary code as it is used, by a Java interpreter that knows both Java and a specific operating system. In theory, this means that a Java program can be executed on any computer for which a Java interpreter exists. In practice, this means that Java is too slow to be pleasant for many uses.

While Microsoft suceeded with commercial distribution of binary-only software, and the rest of the industry followed, some people rejected the concept. The open source and Free Software movements believe that software should be distributed both as binary executables and as source code. Since computer software is digital information, and digital information can be copied reliably and without significant cost, an alternative economy is possible. Instead of giving money to a software developer in exchange for an single copy of a program, a user can contribute her own work to the community in umetered exchange for other people's work. Because of the negligable cost of duplication and the distributive power of the network, this kind of system can support an incredible number of freeloaders. To date, open source development has been powered in large part by personal contributions of code by individuals who receive emotional satisfaction rather than money for their work.

Open source requires the distribution of source code as well as binary executables because source code is more amenable to modification and re-use. When source code is available, a user can change the behavior of a program simply by learning the fundamental principles of computer programming, learning the language of the program, obtaining and configuring the development environment of the program, modifying the program's source code, compiling or interpreting the source code, determining why the modifications failed, and repeating until satisfaction is obtained. Unfortunately, this is not as easy as it might sound to most computer users, and so the number of people actively contributing to open-source projects is quite limited relative to the total pool of computer users.

The Free Software movement, which predates the open source movement and terminology by over a decade, has almost identical practical goals, and thus the two movements have developed a bitter ideological rivalry. The Free Software people believe that the distribution of binary-only code for profit is innately immoral because it restricts the freedom of computer users, and thus should be eliminated. Source code distributed as Free Software is licensed such that a user has complete freedom to use the program, except that they cannot redistribute the program or a modified version of the program without also making the source code available without charge under the same license. Note that Free/Open Source code is still copyrighted by its authors, who then use their copyright power to enforce the license.

I maintained platform and license agnosticism for my first decade of computer user. While I had preferences, including devotion to OS/2 until well after Windows NT had surpassed it in many ways, and a general distaste for the faith-based assertions of Macintosh usability that seemed to cause followers to forget the fact that Macintoshes crash even more frequently than Windows computers, I refused to categorically rule out any company or operating system. I abandoned this position in 2001 for several reasons. I felt Microsoft's general practices, in additional to being illegal, had crossed the line to establish a "with us or against us" situation. I found the rationale behind Free and open software compelling. And I was installing a new computer in China, where I had access to English-language linux distributions but not English-language Windows.

So I have not used Microsoft software, either personally or professionally, for over two years. This last statement is only 99% accurate - it's virtually impossible to function as a computer professional without encountering and using Microsoft software, if only in net bars and borrowed desktops. As with my vegetarianism, acquired under similar circumstances, I feel that humorless absolutism is tedious for both the bearer and bystanders.

Instead, I have used linux and, to a lesser extent, FreeBSD. (I won't mention FreeBSD further in this essay except to say that the using the installer, even in the latest version, continues to be a less pleasant experience than the proverbial sharp stick in the eye.) Because linux itself is only a kernel, using linux means picking a distribution, a collection of programs dependent on linux in the way that a car is dependent on a motor, even if the motor is unseen. There are dozens or hundreds of distributions floating about, each embodying a different philosophy or profit motive. Several of the most enduring include Red Hat, Debian, and SuSE. I have used Red Hat to varying degrees since 1997.

With this information as background, I want to explain why I spent a reasonably warm and not entirely rainy weekend in Copenhagen beating my head on a metaphorical brick wall at a high frequency instead of touring the city and enjoying the extensive non-metaphorical brick architecture.

Before I do this, however, I want to talk about pronunciation for a minute. The proper English pronunciation for linux, I first insisted out of inarticulate instinct and later had justified for me quite convincingly, is lie-nucks, the first syllable rhyming with pi or pie. Many people pronounce it lih-nucks, using the same short i sound found in "lindy-hop." This is apparently because the Finnish author of linux is named Linus, which he pronouces "lee-nus," the first syllable rhyming with see or be. The anglicized version of Linus, however, is "lie-nus," not "lin-us," and so the anglicized version of Linux should follow suit. I must confess, however, that I can't bring myself to call Beijing "Peking," so expect additional justification at a later date.

Back to our story. While free software is by definition available as source code, it's usually more practical to acquire it as binary executables. This is both because of the chicken-and-egg problem of compiling a kernel without having a compiled kernel and compiler, and because compiling the thousands of programs in a typical distribution can take days. Binary executables are specific both to an operating system and to a particular set of libraries, and so binary distributions are more fragile than source distributions.

Libraries are supposed to be "backwards-compatible," meaning that new versions may add functionality but should behave in exactly the same way as old versions. But this is often not true, because of various tradeoffs in how programs can use libraries, because new functions are radically different, and because developers sometimes feel compelled to make things "better," where "better" is defined very narrowly and without accounting for other human beings - for example, fixing typos after thousands of other developers have accomodated the typo in their own code. This kind of accomodation, called somewhat tongue-in-cheek "bug-for-bug compatibility," is a notorious problem for those who write free software that interacts with Microsoft software - most of the complexity in Microsoft-compatible programs, such as those which open Microsoft Office documents, comes from discovering, mapping, and compensating for inconsistences, errors, and secret variations in Microsoft programs.

Choosing a linux distribution means choosing between source-based and binary-based programs. It also means choosing between philosophies - Red Hat is a commercial company which provides both free and non-free software. Debian is a volunteer collective. Mandrake is French, or it's Red Hat, or both. Nobody outside of Germany knows what SuSE is.

Once a distribution is chosen, it must be used. This generally means picking which of two or three different programs you will use for each function. For example, there are two different major desktop projects. A desktop program provides the glitter and underlying plumbing for the WIMP metaphor - Windows Icons Menus Pointer. As we all know, Microsoft stole WIMP from Apple, who had stolen it from Xerox. WIMP offers the devil's bargain of an easier learning curve in exchange for a loss of simplicity and speed. With WIMP, it's both possible and necessary to get computers to work by fiddling with them for a long time. And linux has two different ones to choose from. Each has a different terminal program, a different control panel, a different help system. There are two dominant text editors. There are three major office suites. There are three major web browsers, one not even free. There are three or four different journalling file systems. The general rule of thumb is that if there are N programs that do the same thing, each one will be 1/N exactly the way you like it, and (N-1)/N intolerably wrong-headed.

Now, you might think that, since it's almost all open-source and there are plenty of standards, you could just modify the source code to mix and match what you like from several different programs. You would of course be wrong. Wrong because, while each program scrupulously adheres to a standard, each program adheres to a different standard. After extensive negotiation and open warfare, the two desktop projects agreed to share a website to host their usability guidelines. Not to share the guidelines themselves, but just to store their different guidelines on a common machine. It is impossible to imagine what compromise programs the machine itself must be running.

Red Hat has improved by a quantum leap with each release. I don't think I ever got version 4 to work. Version 5 was worked but I didn't use it for anything. Version 6 was really coming along nicely. Version 7 would install correctly quite often, and once set up could be used by a normal person. Version 8 was, for someone not already familiar with Windows or Macintosh, no harder to learn. Version 9 is actually pretty.

Red Hat is distributed as a collection of closely correlated packages, so it works quite reliably. Red Hat is distributed as a collection of closely correlated packages, so it is often gratuitously difficult to upgrade. Each package has a list of other packages that it thinks it needs, and sometimes this list is wrong. Or needlessly specific. Or one packages will need a specific version of a second, but a third package will need a different version. Most frequently, one package requires a second, which itself requires two others, each of which require one or two more, which then requires one more. Yes, this process of discovery is manual and every bit as much fun as it sounds. There are several automated tools, but they don't work. So you get a very slick and stable system just by putting in the CDs - it's simpler than almost any Windows installation - but upgrading it later is quite a bother.

Because of all this, when I needed to install a new, bigger hard drive, I decided to try Debian again. I've tried it in the past and given up, because, if the installer isn't quite FreeBSD's sharp stick in the eye, the stick's still pointy at best. But Debian offers a packaging system which is, in theory, extremely slick. The computer is given a list of servers which contain packages. Each package has information about its dependencies. The magic happens when Debian's installer tries to get a package. If that package has dependencies, the installer will get those packages too. If they have dependencies, the installer will get those as well. It will keep doing this until both it and the packages are happy, and you don't have to watch any more closely than you want. All you have to do is type a command and the name of the package you want. After you've figured out that you want a package, and what its name is. Then you come back in a few minutes (hours, if you are on a modem) and it all works. Or it doesn't, in which case reconsidering your original goal may be more fruitful than trying to fix the package system. Debian seems to typify linux, in that most things just work perfectly but those that don't generally aren't worth the bother of trying to fix.

The big plus of Debian is that, when you hear about a cool new piece of software, you can just type in one line and the software materializes on your computer. Once you've used it and decided that it sucks, you can remove it from your computer just as easily. For those of us addicted to the pointless rush of trivially improved software on a daily basis, hey, at least it isn't carcinogenic. FreeBSD takes the package system to the next level - source code. You identify the package you want, and issue a command. The computer retrieves the source code from a predetermined location. And the source code for any other programs, and so forth. Then it compiles all of the necessary programs, and installs them. In exchange for this power, the installer is the worst, most user-hostile, trap-laden villainous installer I've ever seen, barring of course the Oracle installer which is simply a cruel and unfunny practical joke.

The minus of Debian is that it doesn't have nearly the polish of Red Hat. And I wasn't very familiar with it. So in order to reap the theoretical future benefit of easy upgrades, I spent pretty much the entire weekend in the office cursing and banging the table trying to get the computer to do something that I felt it should already do but couldn't articulate in language it could understand. The only other thing I did all weekend was go to a jazz club and watch Danes swing.

To summarize, in descending order of pain:

1. Oracle installer
2. (tied) sharp stick in the eye
2. (tied) FreeBSD installer
4. pointy but dull stick in the eye
5. Getting Debian to do something it doesn't want to do (like install)
6. blunt stick in the eye
7. (tied) upgrading Red Hat
7. (tied) no stick but hot smoke in the eye
9. some dust in the eye
10. the sensation you get when you bite into a York peppermint patty
11. (tied) Red Hat installer
11. (tied) Upgrading Debian

We went early for the dance lesson, but when I saw that everyone else was quite well-dressed I took my excuse to head home to change - I was still in swea pants from doing laundry in the morning, where a woman helped me negotiate the automated machines and I played peekabo with the roller baskets with her her toddler daughter (we traded keys and pocket change and she took me for a Kr1.50) and was then interviewed as material for a short film competition on the topic of Tolerance, and then spending the entire rest of the day in the office messing with my computer. So I came back before the main show started, and I was looking all around the main square for an open coffee shop and didn't see one, so when I walked in the lobby and saw a full bar with espresso machine I knew it was a sign, and got a hot chocolate and sat by the door to watch the Danes filter in. This activity felt very hip at first but when no Danes filtered in for quite some time I started to feel stupid. But then this perfectly dressed guy came in - a peach suit with long jacket, dark solid shirt, nice tie, and matching fedora, and he looked good. He hung out with the band, most of which was sitting by the bar. This other guy came in with a baseball cap and orange nylon jacket and nylon pants, and I felt that maybe I could have worn the sweatpants after all.

Later, it became obvious that two guys on the dance floor were clearly several levels above anyone except this one girl wearing a hair net and reasonable approximation of a flapper dress. One was the guy in the peach suit and the other was the guy in nylon. He danced so well, and was so perfectly built, that he managed to make a fitted black baseball cap worn low over the eyes appropriate garb for swing dancing. Peter, meanwhile, our tall, crewcut blonde Swede, was quite a good dancer but in his black shirt and tight jeans looked like he belonged in a country-western line dance.