Chapter 14

:down: 1. /adj./ Not operating. "The up escalator is down" is considered a humorous thing to say (unless of course you were expecting to use it), and "The elevator is down" always means "The elevator isn't working" and never refers to what floor the elevator is on. With respect to computers, this term has passed into the mainstream; the extension to other kinds of machine is still confined to techies (e.g. boiler mechanics may speak of a boiler being down). 2. `go down' /vi./ To stop functioning; usually said of the {system}. The message from the {console} that every hacker hates to hear from the operator is "System going down in 5 minutes". 3. `take down', `bring down' /vt./ To deactivate purposely, usually for repair work or {PM}. "I'm taking the system down to work on that bug in the tape drive." Occasionally one hears the word `down' by itself used as a verb in this /vt./ sense. See {crash}; oppose {up}.

:download: /vt./ To transfer data or (esp.) code from a larger `host' system (esp. a {mainframe}) over a digital comm link to a smaller `client' system, esp. a microcomputer or specialized peripheral. Oppose {upload}.

However, note that ground-to-space communications has its own usage rule for this term. Space-to-earth transmission is always `down' and the reverse `up' regardless of the relative size of the computers involved. So far the in-space machines have invariably been smaller; thus the upload/download distinction has been reversed from its usual sense.

:DP: /D-P/ /n./ 1. Data Processing. Listed here because, according to hackers, use of the term marks one immediately as a {suit}. See {DPer}. 2. Common abbrev for {Dissociated Press}.

:DPB: /d*-pib'/ /vt./ [from the PDP-10 instruction set] To plop something down in the middle. Usage: silly. "DPB yourself into that couch there." The connotation would be that the couch is full except for one slot just big enough for one last person to sit in. DPB means `DePosit Byte', and was the name of a PDP-10 instruction that inserts some bits into the middle of some other bits. Hackish usage has been kept alive by the Common LISP function of the same name.

:DPer: /dee-pee-er/ /n./ Data Processor. Hackers are absolutely amazed that {suit}s use this term self-referentially. *Computers* process data, not people! See {DP}.

:dragon: /n./ [MIT] A program similar to a {daemon}, except that it is not invoked at all, but is instead used by the system to perform various secondary tasks. A typical example would be an accounting program, which keeps track of who is logged in, accumulates load-average statistics, etc. Under ITS, many terminals displayed a list of people logged in, where they were, what they were running, etc., along with some random picture (such as a unicorn, Snoopy, or the Enterprise), which was generated by the `name dragon'. Usage: rare outside MIT -- under Unix and most other OSes this would be called a `background demon' or {daemon}. The best-known Unix example of a dragon is `cron(1)'. At SAIL, they called this sort of thing a `phantom'.

:Dragon Book: /n./ The classic text "Compilers: Principles, Techniques and Tools", by Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman (Addison-Wesley 1986; ISBN 0-201-10088-6), so called because of the cover design featuring a dragon labeled `complexity of compiler design' and a knight bearing the lance `LALR parser generator' among his other trappings. This one is more specifically known as the `Red Dragon Book' (1986); an earlier edition, sans Sethi and titled "Principles Of Compiler Design" (Alfred V. Aho and Jeffrey D. Ullman; Addison-Wesley, 1977; ISBN 0-201-00022-9), was the `Green Dragon Book' (1977). (Also `New Dragon Book', `Old Dragon Book'.) The horsed knight and the Green Dragon were warily eying each other at a distance; now the knight is typing (wearing gauntlets!) at a terminal showing a video-game representation of the Red Dragon's head while the rest of the beast extends back in normal space. See also {{book titles}}.

:drain: /v./ [IBM] Syn. for {flush} (sense 2). Has a connotation of finality about it; one speaks of draining a device before taking it offline.

:dread high-bit disease: /n./ A condition endemic to some now-obsolete computers and peripherals (including ASR-33 teletypes and PRIME minicomputers) that results in all characters having their high (0x80) bit forced on. This of course makes transporting files to other systems much more difficult, not to mention the problems these machines have talking with true 8-bit devices.

This term was originally used specifically of PRIME (a.k.a. PR1ME) minicomputers. Folklore has it that PRIME adopted the reversed-8-bit convention in order to save 25 cents per serial line per machine; PRIME old-timers, on the other hand, claim they inherited the disease from Honeywell via customer NASA's compatibility requirements and struggled heroically to cure it. Whoever was responsible, this probably qualifies as one of the most {cretinous} design tradeoffs ever made. See {meta bit}.

:DRECNET: /drek'net/ /n./ [from Yiddish/German `dreck', meaning filth] Deliberate distortion of DECNET, a networking protocol used in the {VMS} community. So called because DEC helped write the Ethernet specification and then (either stupidly or as a malignant customer-control tactic) violated that spec in the design of DRECNET in a way that made it incompatible. See also {connector conspiracy}.

:driver: /n./ 1. The {main loop} of an event-processing program; the code that gets commands and dispatches them for execution. 2. [techspeak] In `device driver', code designed to handle a particular peripheral device such as a magnetic disk or tape unit. 3. In the TeX world and the computerized typesetting world in general, a program that translates some device-independent or other common format to something a real device can actually understand.

:droid: /n./ [from `android', SF terminology for a humanoid robot of essentially biological (as opposed to mechanical/electronic) construction] A person (esp. a low-level bureaucrat or service-business employee) exhibiting most of the following characteristics: (a) naive trust in the wisdom of the parent organization or `the system'; (b) a blind-faith propensity to believe obvious nonsense emitted by authority figures (or computers!); (c) a rule-governed mentality, one unwilling or unable to look beyond the `letter of the law' in exceptional situations; (d) a paralyzing fear of official reprimand or worse if Procedures are not followed No Matter What; and (e) no interest in doing anything above or beyond the call of a very narrowly-interpreted duty, or in particular in fixing that which is broken; an "It's not my job, man" attitude.

Typical droid positions include supermarket checkout assistant and bank clerk; the syndrome is also endemic in low-level government employees. The implication is that the rules and official procedures constitute software that the droid is executing; problems arise when the software has not been properly debugged. The term `droid mentality' is also used to describe the mindset behind this behavior. Compare {suit}, {marketroid}; see {-oid}.

:drool-proof paper: /n./ Documentation that has been obsessively {dumbed down}, to the point where only a {cretin} could bear to read it, is said to have succumbed to the `drool-proof paper syndrome' or to have been `written on drool-proof paper'. For example, this is an actual quote from Apple's LaserWriter manual: "Do not expose your LaserWriter to open fire or flame."

:drop on the floor: /vt./ To react to an error condition by silently discarding messages or other valuable data. "The gateway ran out of memory, so it just started dropping packets on the floor." Also frequently used of faulty mail and netnews relay sites that lose messages. See also {black hole}, {bit bucket}.

:drop-ins: /n./ [prob. by analogy with {drop-outs}] Spurious characters appearing on a terminal or console as a result of line noise or a system malfunction of some sort. Esp. used when these are interspersed with one's own typed input. Compare {drop-outs}, sense 2.

:drop-outs: /n./ 1. A variety of `power glitch' (see {glitch}); momentary 0 voltage on the electrical mains. 2. Missing characters in typed input due to software malfunction or system saturation (one cause of such behavior under Unix when a bad connection to a modem swamps the processor with spurious character interrupts; see {screaming tty}). 3. Mental glitches; used as a way of describing those occasions when the mind just seems to shut down for a couple of beats. See {glitch}, {fried}.

:drugged: /adj./ (also `on drugs') 1. Conspicuously stupid, heading toward {brain-damaged}. Often accompanied by a pantomime of toking a joint. 2. Of hardware, very slow relative to normal performance.

:drum: adj, /n./ Ancient techspeak term referring to slow, cylindrical magnetic media that were once state-of-the-art storage devices. Under BSD Unix the disk partition used for swapping is still called `/dev/drum'; this has led to considerable humor and not a few straight-faced but utterly bogus `explanations' getting foisted on {newbie}s. See also "{The Story of Mel, a Real Programmer}" in Appendix A.

:drunk mouse syndrome: /n./ (also `mouse on drugs') A malady exhibited by the mouse pointing device of some computers. The typical symptom is for the mouse cursor on the screen to move in random directions and not in sync with the motion of the actual mouse. Can usually be corrected by unplugging the mouse and plugging it back again. Another recommended fix for optical mice is to rotate your mouse pad 90 degrees.

At Xerox PARC in the 1970s, most people kept a can of copier cleaner (isopropyl alcohol) at their desks. When the steel ball on the mouse had picked up enough {cruft} to be unreliable, the mouse was doused in cleaner, which restored it for a while. However, this operation left a fine residue that accelerated the accumulation of cruft, so the dousings became more and more frequent. Finally, the mouse was declared `alcoholic' and sent to the clinic to be dried out in a CFC ultrasonic bath.

:Duff's device: /n./ The most dramatic use yet seen of {fall through} in C, invented by Tom Duff when he was at Lucasfilm. Trying to {bum} all the instructions he could out of an inner loop that copied data serially onto an output port, he decided to unroll it. He then realized that the unrolled version could be implemented by *interlacing* the structures of a switch and a loop:

register n = (count + 7) / 8; /* count > 0 assumed */

switch (count % 8) { case 0: do { *to = *from++; case 7: *to = *from++; case 6: *to = *from++; case 5: *to = *from++; case 4: *to = *from++; case 3: *to = *from++; case 2: *to = *from++; case 1: *to = *from++; } while (--n > 0); }

Shocking though it appears to all who encounter it for the first time, the device is actually perfectly valid, legal C. C's default {fall through} in case statements has long been its most controversial single feature; Duff observed that "This code forms some sort of argument in that debate, but I'm not sure whether it's for or against."

[For maximal obscurity, the outermost pair of braces above could be actually be removed -- GLS]

:dumb terminal: /n./ A terminal that is one step above a {glass tty}, having a minimally addressable cursor but no on-screen editing or other features normally supported by a {smart terminal}. Once upon a time, when glass ttys were common and addressable cursors were something special, what is now called a dumb terminal could pass for a smart terminal.

:dumbass attack: /duhm'as *-tak'/ /n./ [Purdue] Notional cause of a novice's mistake made by the experienced, especially one made while running as {root} under Unix, e.g., typing `rm -r *' or `mkfs' on a mounted file system. Compare {adger}.

:dumbed down: /adj./ Simplified, with a strong connotation of *over*simplified. Often, a {marketroid} will insist that the interfaces and documentation of software be dumbed down after the designer has burned untold gallons of midnight oil making it smart. This creates friction. See {user-friendly}.

:dump: /n./ 1. An undigested and voluminous mass of information about a problem or the state of a system, especially one routed to the slowest available output device (compare {core dump}), and most especially one consisting of hex or octal {runes} describing the byte-by-byte state of memory, mass storage, or some file. In {elder days}, debugging was generally done by `groveling over' a dump (see {grovel}); increasing use of high-level languages and interactive debuggers has made such tedium uncommon, and the term `dump' now has a faintly archaic flavor. 2. A backup. This usage is typical only at large timesharing installations.

:dumpster diving: /dump'-ster di:'-ving/ /n./ 1. The practice of sifting refuse from an office or technical installation to extract confidential data, especially security-compromising information (`dumpster' is an Americanism for what is elsewhere called a `skip'). Back in AT&T's monopoly days, before paper shredders became common office equipment, phone phreaks (see {phreaking}) used to organize regular dumpster runs against phone company plants and offices. Discarded and damaged copies of AT&T internal manuals taught them much. The technique is still rumored to be a favorite of crackers operating against careless targets. 2. The practice of raiding the dumpsters behind buildings where producers and/or consumers of high-tech equipment are located, with the expectation (usually justified) of finding discarded but still-valuable equipment to be nursed back to health in some hacker's den. Experienced dumpster-divers not infrequently accumulate basements full of moldering (but still potentially useful) {cruft}.

:dup killer: /d[y]oop kill'r/ /n./ [FidoNet] Software that is supposed to detect and delete duplicates of a message that may have reached the FidoNet system via different routes.

:dup loop: /d[y]oop loop/ (also `dupe loop') /n./ [FidoNet] An infinite stream of duplicated, near-identical messages on a FidoNet {echo}, the only difference being unique or mangled identification information applied by a faulty or incorrectly configured system or network gateway, thus rendering {dup killer}s ineffective. If such a duplicate message eventually reaches a system through which it has already passed (with the original identification information), all systems passed on the way back to that system are said to be involved in a {dup loop}.

:dusty deck: /n./ Old software (especially applications) which one is obliged to remain compatible with, or to maintain ({DP} types call this `legacy code', a term hackers consider smarmy and excessively reverent). The term implies that the software in question is a holdover from card-punch days. Used esp. when referring to old scientific and {number-crunching} software, much of which was written in FORTRAN and very poorly documented but is believed to be too expensive to replace. See {fossil}; compare {crawling horror}.

:DWIM: /dwim/ [acronym, `Do What I Mean'] 1. /adj./ Able to guess, sometimes even correctly, the result intended when bogus input was provided. 2. /n. obs./ The BBNLISP/INTERLISP function that attempted to accomplish this feat by correcting many of the more common errors. See {hairy}. 3. Occasionally, an interjection hurled at a balky computer, esp. when one senses one might be tripping over legalisms (see {legalese}).

Warren Teitelman originally wrote DWIM to fix his typos and spelling errors, so it was somewhat idiosyncratic to his style, and would often make hash of anyone else's typos if they were stylistically different. Some victims of DWIM thus claimed that the acronym stood for `Damn Warren's Infernal Machine!'.

In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed `delete *$' to free up some disk space. (The editor there named backup files by appending `$' to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported `*$ not found, assuming you meant 'delete *'.' It then started to delete all the files on the disk! The hacker managed to stop it with a {Vulcan nerve pinch} after only a half dozen or so files were lost.

The disgruntled victim later said he had been sorely tempted to go to Warren's office, tie Warren down in his chair in front of his workstation, and then type `delete *$' twice.

DWIM is often suggested in jest as a desired feature for a complex program; it is also occasionally described as the single instruction the ideal computer would have. Back when proofs of program correctness were in vogue, there were also jokes about `DWIMC' (Do What I Mean, Correctly). A related term, more often seen as a verb, is DTRT (Do The Right Thing); see {Right Thing}.

:dynner: /din'r/ /n./ 32 bits, by analogy with {nybble} and {{byte}}. Usage: rare and extremely silly. See also {playte}, {tayste}, {crumb}. General discussion of such terms is under {nybble}.

= E = =====

:earthquake: /n./ [IBM] The ultimate real-world shock test for computer hardware. Hackish sources at IBM deny the rumor that the Bay Area quake of 1989 was initiated by the company to test quality-assurance procedures at its California plants.

:Easter egg: /n./ [from the custom of the Easter Egg hunt observed in the U.S. and many parts of Europe] 1. A message hidden in the object code of a program as a joke, intended to be found by persons disassembling or browsing the code. 2. A message, graphic, or sound effect emitted by a program (or, on a PC, the BIOS ROM) in response to some undocumented set of commands or keystrokes, intended as a joke or to display program credits. One well-known early Easter egg found in a couple of OSes caused them to respond to the command `make love' with `not war?'. Many personal computers have much more elaborate eggs hidden in ROM, including lists of the developers' names, political exhortations, snatches of music, and (in one case) graphics images of the entire development team.

:Easter egging: /n./ [IBM] The act of replacing unrelated components more or less at random in hopes that a malfunction will go away. Hackers consider this the normal operating mode of {field circus} techs and do not love them for it. See also the jokes under {field circus}. Compare {shotgun debugging}.

:eat flaming death: /imp./ A construction popularized among hackers by the infamous {CPU Wars} comic; supposedly derive from a famously turgid line in a WWII-era anti-Nazi propaganda comic that ran "Eat flaming death, non-Aryan mongrels!" or something of the sort (however, it is also reported that the Firesign Theater's 1975 album "In The Next World, You're On Your Own" included the phrase "Eat flaming death, fascist media pigs"; this may have been an influence). Used in humorously overblown expressions of hostility. "Eat flaming death, {{EBCDIC}} users!"

:EBCDIC:: /eb's*-dik/, /eb'see`dik/, or /eb'k*-dik/ /n./ [abbreviation, Extended Binary Coded Decimal Interchange Code] An alleged character set used on IBM {dinosaur}s. It exists in at least six mutually incompatible versions, all featuring such delights as non-contiguous letter sequences and the absence of several ASCII punctuation characters fairly important for modern computer languages (exactly which characters are absent varies according to which version of EBCDIC you're looking at). IBM adapted EBCDIC from {{punched card}} code in the early 1960s and promulgated it as a customer-control tactic (see {connector conspiracy}), spurning the already established ASCII standard. Today, IBM claims to be an open-systems company, but IBM's own description of the EBCDIC variants and how to convert between them is still internally classified top-secret, burn-before-reading. Hackers blanch at the very *name* of EBCDIC and consider it a manifestation of purest {evil}. See also {fear and loathing}.

:echo: [FidoNet] /n./ A {topic group} on {FidoNet}'s echomail system. Compare {newsgroup}.

:eighty-column mind: /n./ [IBM] The sort said to be possessed by persons for whom the transition from {punched card} to tape was traumatic (nobody has dared tell them about disks yet). It is said that these people, including (according to an old joke) the founder of IBM, will be buried `face down, 9-edge first' (the 9-edge being the bottom of the card). This directive is inscribed on IBM's 1402 and 1622 card readers and is referenced in a famous bit of doggerel called "The Last Bug", the climactic lines of which are as follows:

He died at the console Of hunger and thirst. Next day he was buried, Face down, 9-edge first.

The eighty-column mind is thought by most hackers to dominate IBM's customer base and its thinking. See {IBM}, {fear and loathing}, {card walloper}.

:El Camino Bignum: /el' k*-mee'noh big'nuhm/ /n./ The road mundanely called El Camino Real, running along San Francisco peninsula. It originally extended all the way down to Mexico City; many portions of the old road are still intact. Navigation on the San Francisco peninsula is usually done relative to El Camino Real, which defines {logical} north and south even though it isn't really north-south in many places. El Camino Real runs right past Stanford University and so is familiar to hackers.

The Spanish word `real' (which has two syllables: /ray-ahl'/) means `royal'; El Camino Real is `the royal road'. In the FORTRAN language, a `real' quantity is a number typically precise to seven significant digits, and a `double precision' quantity is a larger floating-point number, precise to perhaps fourteen significant digits (other languages have similar `real' types).

When a hacker from MIT visited Stanford in 1976, he remarked what a long road El Camino Real was. Making a pun on `real', he started calling it `El Camino Double Precision' -- but when the hacker was told that the road was hundreds of miles long, he renamed it `El Camino Bignum', and that name has stuck. (See {bignum}.) In recent years, the synonym `El Camino Virtual' has been reported as an alternate at IBM and Amdahl sites in the Valley.

[GLS has since let slip that the unnamed hacker in this story was in fact he --ESR]