Chapter L (4)

:WYSIAYG: /wiz'ee-ayg/ /adj./ Describes a user interface
under which "What You See Is *All* You Get"; an unhappy
variant of {WYSIWYG}. Visual, `point-and-shoot'-style
interfaces tend to have easy initial learning curves, but also to
lack depth; they often frustrate advanced users who would be better
served by a command-style interface. When this happens, the
frustrated user has a WYSIAYG problem. This term is most often
used of editors, word processors, and document formatting programs.
WYSIWYG `desktop publishing' programs, for example, are a clear
win for creating small documents with lots of fonts and graphics in
them, especially things like newsletters and presentation slides.
When typesetting book-length manuscripts, on the other hand, scale
changes the nature of the task; one quickly runs into WYSIAYG
limitations, and the increased power and flexibility of a
command-driven formatter like {{TeX}} or Unix's {{troff}}
becomes not just desirable but a necessity. Compare {YAFIYGI}.

:WYSIWYG: /wiz'ee-wig/ /adj./ Describes a user interface
under which "What You See Is What You Get", as opposed to one
that uses more-or-less obscure commands that do not result in
immediate visual feedback. True WYSIWYG in environments supporting
multiple fonts or graphics is a a rarely-attained ideal; there are
variants of this term to express real-world manifestations
including WYSIAWYG (What You See Is *Almost* What You Get) and
WYSIMOLWYG (What You See Is More or Less What You Get). All these
can be mildly derogatory, as they are often used to refer to
dumbed-down {user-friendly} interfaces targeted at
non-programmers; a hacker has no fear of obscure commands (compare
{WYSIAYG}). On the other hand, {EMACS} was one of the very
first WYSIWYG editors, replacing (actually, at first overlaying)
the extremely obscure, command-based {TECO}. See also {WIMP
environment}. [Oddly enough, WYSIWYG has already made it into the
OED, in lower case yet. --ESR]

= X = =====

:X: /X/ /n./ 1. Used in various speech and writing contexts
(also in lowercase) in roughly its algebraic sense of `unknown
within a set defined by context' (compare {N}). Thus, the
abbreviation 680x0 stands for 68000, 68010, 68020, 68030, or 68040,
and 80x86 stands for 80186, 80286 80386 or 80486 (note that a Unix
hacker might write these as 680[0-4]0 and 80[1-4]86 or 680?0 and
80?86 respectively; see {glob}). 2. [after the name of an
earlier window system called `W'] An over-sized, over-featured,
over-engineered and incredibly over-complicated window system
developed at MIT and widely used on Unix systems.

:XEROX PARC: /zee'roks park'/ /n./ The famed Palo Alto
Research Center. For more than a decade, from the early 1970s into
the mid-1980s, PARC yielded an astonishing volume of groundbreaking
hardware and software innovations. The modern mice, windows, and
icons style of software interface was invented there. So was the
laser printer and the local-area network; and PARC's series of D
machines anticipated the powerful personal computers of the 1980s
by a decade. Sadly, the prophets at PARC were without honor in
their own company, so much so that it became a standard joke to
describe PARC as a place that specialized in developing brilliant
ideas for everyone else.

The stunning shortsightedness and obtusity of XEROX's top-level
{suit}s has been well anatomized in "Fumbling The Future:
How XEROX Invented, Then Ignored, the First Personal Computer" by
Douglas K. Smith and Robert C. Alexander (William Morrow & Co.,
1988, ISBN 0-688-09511-9).

:XOFF: /X-of/ /n./ Syn. {control-S}.

:XON: /X-on/ /n./ Syn. {control-Q}.

:xor: /X'or/, /kzor/ /conj./ Exclusive or. `A xor B' means
`A or B, but not both'. "I want to get cherry pie xor a banana
split." This derives from the technical use of the term as a
function on truth-values that is true if exactly one of its two
arguments is true.

:xref: /X'ref/ /v.,n./ Hackish standard abbreviation for
`cross-reference'.

:XXX: /X-X-X/ /n./ A marker that attention is needed.
Commonly used in program comments to indicate areas that are kluged
up or need to be. Some hackers liken `XXX' to the notional
heavy-porn movie rating. Compare {FIXME}.

:xyzzy: /X-Y-Z-Z-Y/, /X-Y-ziz'ee/, /ziz'ee/, or /ik-ziz'ee/
/adj./ [from the ADVENT game] The {canonical} `magic
word'. This comes from {ADVENT}, in which the idea is to
explore an underground cave with many rooms and to collect the
treasures you find there. If you type `xyzzy' at the appropriate
time, you can move instantly between two otherwise distant points.
If, therefore, you encounter some bit of {magic}, you might
remark on this quite succinctly by saying simply "Xyzzy!"
"Ordinarily you can't look at someone else's screen if he has
protected it, but if you type quadruple-bucky-clear the system will
let you do it anyway." "Xyzzy!"

Xyzzy has actually been implemented as an undocumented no-op
command on several OSes; in Data General's AOS/VS, for example, it
would typically respond "Nothing happens", just as {ADVENT}
did if the magic was invoked at the wrong spot or before a player
had performed the action that enabled the word. In more recent
32-bit versions, by the way, AOS/VS responds "Twice as much
happens".

The popular `minesweeper' game under Microsoft Windows has a
cheat mode triggered by the command `xyzzy<enter><right-shift>'
that turns the top-left pixel of the screen different colors
depending on whether or not the cursor is over a bomb.

= Y = =====

:YA-: /abbrev./ [Yet Another] In hackish acronyms this almost
invariably expands to {Yet Another}, following the precedent set
by Unix `yacc(1)' (Yet Another Compiler-Compiler). See
{YABA}.

:YABA: /ya'b*/ /n./ [Cambridge] Yet Another Bloody Acronym.
Whenever some program is being named, someone invariably suggests
that it be given a name that is acronymic. The response from those
with a trace of originality is to remark ironically that the
proposed name would then be `YABA-compatible'. Also used in
response to questions like "What is WYSIWYG?" See also
{TLA}.

:YAFIYGI: /yaf'ee-y*-gee/ /adj./ [coined in response to
WYSIWYG] Describes the command-oriented ed/vi/nroff/TeX style of
word processing or other user interface, the opposite of
{WYSIWYG}. Stands for "You asked for it, you got it", because
what you actually asked for is often not apparent until long after
it is too late to do anything about it. Used to denote perversity
("Real Programmers use YAFIYGI tools...and *like* it!")
or, less often, a necessary tradeoff ("Only a YAFIYGI tool can
have full programmable flexibility in its interface.").

This precise sense of "You asked for it, you got it" seems to
have first appeared in Ed Post's classic parody "Real
Programmers don't use Pascal" (see {Real Programmer}s); the
acronym is a more recent invention.

:YAUN: /yawn/ /n./ [Acronym for `Yet Another Unix Nerd']
Reported from the San Diego Computer Society (predominantly a
microcomputer users' group) as a good-natured punning insult aimed
at Unix zealots.

:Yellow Book: /n./
The print version of this Jargon
File; "The New Hacker's Dictionary" from MIT Press; The book
includes essentially all the material the File, plus a Foreword by
Guy L. Steele Jr. and a Preface by Eric S. Raymond. Most
importantly, the book version is nicely typeset and includes almost
all of the infamous Crunchly cartoons by the Great Quux, each
attached to an appropriate entry. The first edition (1991, ISBN
0-262-68069-6) corresponded to the Jargon File version 2.9.6. The
second edition (1993, ISBN 0-262-68079-3) corresponded to the
Jargon
File 3.0.0. The third (1996, ISBN 0-262-68092-0) will correspond
to 4.0.0.

:yellow wire: /n./ [IBM] Repair wires used when connectors
(especially ribbon connectors) got broken due to some schlemiel
pinching them, or to reconnect cut traces after the FE mistakenly
cut one. Compare {blue wire}, {purple wire}, {red wire}.

:Yet Another: /adj./ [From Unix's `yacc(1)', `Yet
Another Compiler-Compiler', a LALR parser generator] 1. Of your own
work: A humorous allusion often used in titles to acknowledge that
the topic is not original, though the content is. As in `Yet
Another AI Group' or `Yet Another Simulated Annealing Algorithm'.
2. Of others' work: Describes something of which there are already
far too many. See also {YA-}, {YABA}, {YAUN}.

:YKYBHTLW: // /abbrev./ Abbreviation of `You know you've been
hacking too long when...', which became established on the Usenet
group alt.folklore.computers during extended discussion of the
indicated entry in the Jargon File.

:YMMV: // /cav./ Abbreviation for {Your mileage
may vary} common on Usenet.

:You are not expected to understand this: [Unix] /cav./ The
canonical comment describing something {magic} or too
complicated to bother explaining properly. From an infamous
comment in the context-switching code of the V6 Unix kernel.

:You know you've been hacking too long when...: The
set-up line for a genre of one-liners told by hackers about
themselves. These include the following:

* not only do you check your email more often than your paper
mail, but you remember your {network address} faster than your
postal one.
* your {SO} kisses you on the neck and the first thing you
think is "Uh, oh, {priority interrupt}."
* you go to balance your checkbook and discover that you're
doing it in octal.
* your computers have a higher street value than your car.
* in your universe, `round numbers' are powers of 2, not 10.
* more than once, you have woken up recalling a dream in
some programming language.
* you realize you have never seen half of your best friends.

[An early version of this entry said "All but one of these
have been reliably reported as hacker traits (some of them quite
often). Even hackers may have trouble spotting the ringer." The
ringer was balancing one's checkbook in octal, which I made up out
of whole cloth. Although more respondents picked that one
out as fiction than any of the others, I also received multiple
independent reports of its actually happening, most famously
to Grace Hopper while she was working with BINAC in 1949. --ESR]

:Your mileage may vary: /cav./ [from the standard disclaimer
attached to EPA mileage ratings by American car manufacturers] 1. A
ritual warning often found in Unix freeware distributions.
Translates roughly as "Hey, I tried to write this portably, but
who *knows* what'll happen on your system?" 2. More
generally, a qualifier attached to advice. "I find that sending
flowers works well, but your mileage may vary."

:Yow!: /yow/ /interj./ [from "Zippy the Pinhead" comix] A
favored hacker expression of humorous surprise or emphasis. "Yow!
Check out what happens when you twiddle the foo option on this
display hack!" Compare {gurfle}.

:yoyo mode: /n./ The state in which the system is said to be
when it rapidly alternates several times between being up and being
down. Interestingly (and perhaps not by coincidence), many
hardware vendors give out free yoyos at Usenix exhibits.

Sun Microsystems gave out logoized yoyos at SIGPLAN '88. Tourists
staying at one of Atlanta's most respectable hotels were
subsequently treated to the sight of 200 of the country's top
computer scientists testing yo-yo algorithms in the lobby.

:Yu-Shiang Whole Fish: /yoo-shyang hohl fish/ /n. obs./ The
character gamma (extended SAIL ASCII 0001001), which with a loop in
its tail looks like a little fish swimming down the page. The term
is actually the name of a Chinese dish in which a fish is cooked
whole (not {parse}d) and covered with Yu-Shiang (or Yu-Hsiang)
sauce. Usage: primarily by people on the MIT LISP Machine, which
could display this character on the screen. Tends to elicit
incredulity from people who hear about it second-hand.

= Z = =====

:zap: 1. /n./ Spiciness. 2. /vt./ To make food spicy. 3. /vt./ To
make someone `suffer' by making his food spicy. (Most hackers
love spicy food. Hot-and-sour soup is considered wimpy unless it
makes you wipe your nose for the rest of the meal.) See
{zapped}. 4. /vt./ To modify, usually to correct; esp. used
when the action is performed with a debugger or binary patching
tool. Also implies surgical precision. "Zap the debug level to 6
and run it again." In the IBM mainframe world, binary patches are
applied to programs or to the OS with a program called
`superzap', whose file name is `IMASPZAP' (possibly contrived
from I M A SuPerZAP). 5. /vt./ To erase or reset. 6. To {fry} a
chip with static electricity. "Uh oh -- I think that lightning
strike may have zapped the disk controller."

:zapped: /adj./ Spicy. This term is used to distinguish
between food that is hot (in temperature) and food that is
*spicy*-hot. For example, the Chinese appetizer Bon Bon
Chicken is a kind of chicken salad that is cold but zapped; by
contrast, {vanilla} wonton soup is hot but not zapped. See also
{{oriental food}}, {laser chicken}. See {zap}, senses 1 and
2.

:zen: /vt./ To figure out something by meditation or by a
sudden flash of enlightenment. Originally applied to bugs, but
occasionally applied to problems of life in general. "How'd you
figure out the buffer allocation problem?" "Oh, I zenned it."
Contrast {grok}, which connotes a time-extended version of
zenning a system. Compare {hack mode}. See also {guru}.

:zero: /vt./ 1. To set to 0. Usually said of small pieces of
data, such as bits or words (esp. in the construction `zero
out'). 2. To erase; to discard all data from. Said of disks and
directories, where `zeroing' need not involve actually writing
zeroes throughout the area being zeroed. One may speak of
something being `logically zeroed' rather than being
`physically zeroed'. See {scribble}.

:zero-content: /adj./ Syn. {content-free}.

:Zero-One-Infinity Rule: /prov./ "Allow none of {foo},
one of {foo}, or any number of {foo}." A rule of thumb for
software design, which instructs one to not place {random}
limits on the number of instances of a given entity (such as:
windows in a window system, letters in an OS's filenames, etc.).
Specifically, one should either disallow the entity entirely, allow
exactly one instance (an "exception"), or allow as many as the
user wants -- address space and memory permitting.

The logic behind this rule is that there are often situations where
it makes clear sense to allow one of something instead of none.
However, if one decides to go further and allow N (for N > 1), then
why not N+1? And if N+1, then why not N+2, and so on? Once above
1, there's no excuse not to allow any N; hence, {infinity}.

Many hackers recall in this connection Isaac Asimov's SF novel
"The Gods Themselves" in which a character announces that the
number 2 is impossible -- if you're going to believe in more than
one universe, you might as well believe in an infinite number of
them.

:zeroth: /zee'rohth/ /adj./ First. Among software designers,
comes from C's and LISP's 0-based indexing of arrays. Hardware
people also tend to start counting at 0 instead of 1; this is
natural since, e.g., the 256 states of 8 bits correspond to the
binary numbers 0, 1, ..., 255 and the digital devices known as
`counters' count in this way.

Hackers and computer scientists often like to call the first
chapter of a publication `Chapter 0', especially if it is of an
introductory nature (one of the classic instances was in the First
Edition of {K&R}). In recent years this trait has also been
observed among many pure mathematicians (who have an independent
tradition of numbering from 0). Zero-based numbering tends to
reduce {fencepost error}s, though it cannot eliminate them
entirely.

:zigamorph: /zig'*-morf/ /n./ 1. Hex FF (11111111) when used
as a delimiter or {fence} character. Usage: primarily at IBM
shops. 2. [proposed] /n./ The Unicode non-character U+FFFF
(1111111111111111), a character code which is not assigned to any
character, and so is usable as end-of-string. (Unicode (a subset
of ISO 10646) is a 16-bit character code intended to cover all of
the world's writing systems, including Roman, Greek, Cyrillic,
Chinese, hiragana, katakana, Devanagari, Ethiopic, Thai, Laotian
and many other languages (support for {elvish} is planned for a
future release).

:zip: /vt./ [primarily MS-DOS] To create a compressed archive
from a group of files using PKWare's PKZIP or a compatible
archiver. Its use is spreading now that portable implementations
of the algorithm have been written. Commonly used as follows:
"I'll zip it up and send it to you." See {tar and feather}.

:zipperhead: /n./ [IBM] A person with a closed mind.

:zombie: /n./ [Unix] A process that has died but has not yet
relinquished its process table slot (because the parent process
hasn't executed a `wait(2)' for it yet). These can be seen in
`ps(1)' listings occasionally. Compare {orphan}.

:zorch: /zorch/ 1. [TMRC] /v./ To attack with an inverse heat
sink. 2. [TMRC] /v./ To travel, with v approaching c
[that is, with velocity approaching lightspeed --ESR]. 3. [MIT]
/v./ To propel something very quickly. "The new comm software is
very fast; it really zorches files through the network." 4. [MIT]
/n./ Influence. Brownie points. Good karma. The intangible and
fuzzy currency in which favors are measured. "I'd rather not ask
him for that just yet; I think I've used up my quota of zorch with
him for the week." 5. [MIT] /n./ Energy, drive, or ability. "I
think I'll {punt} that change for now; I've been up for 30 hours
and I've run out of zorch." 6. [MIT] /v./ To flunk an exam or
course.

:Zork: /zork/ /n./ The second of the great early experiments
in computer fantasy gaming; see {ADVENT}. Originally written
on MIT-DM during 1977-1979, later distributed with BSD Unix (as a
patched, sourceless RT-11 FORTRAN binary; see {retrocomputing})
and commercialized as `The Zork Trilogy' by {Infocom}. The
FORTRAN source was later rewritten for portability and released to
Usenet under the name "Dungeon". Both FORTRAN "Dungeon" and
translated C versions are available at many FTP sites.

:zorkmid: /zork'mid/ /n./ The canonical unit of currency in
hacker-written games. This originated in {Zork} but has spread
to {nethack} and is referred to in several other games.

= [^A-Za-z] = =============

:<bobbit>: /n./ [Usenet: alt.folklore.urban and
elsewhere] Commonly used as a placeholder for omitted text in a
followup message (not copying the whole parent message is
considered good form). Refers, of course, to the celebrated
mutilation of John Bobbitt.

:4.2: /for' poynt too'/ /n./ Without a prefix, this almost
invariably refers to {BSD} Unix release 4.2. Note that it is an
indication of cluelessness to say "version 4.2", and "release
4.2" is rare; the number stands on its own, or is used in the more
explicit forms 4.2BSD or (less commonly) BSD 4.2. Similar remarks
apply to "4.3", "4.4" and to earlier, less-widespread releases
4.1 and 2.9.

:'Snooze: /snooz/ [FidoNet] /n./ Fidonews, the weekly
official on-line newsletter of FidoNet. As the editorial policy of
Fidonews is "anything that arrives, we print", there are often
large articles completely unrelated to FidoNet, which in turn tend
to elicit {flamage} in subsequent issues.

:(TM): // [Usenet] ASCII rendition of the
trademark-superscript symbol
appended to phrases that the author feels should be recorded for
posterity, perhaps in future editions of this lexicon. Sometimes
used ironically as a form of protest against the recent spate of
software and algorithm patents and `look and feel' lawsuits. See
also {UN*X}.

:-oid: /suff./ [from `android'] 1. Used as in mainstream
English to indicate a poor imitation, a counterfeit, or some
otherwise slightly bogus resemblance. Hackers will happily use it
with all sorts of non-Greco/Latin stem words that wouldn't keep
company with it in mainstream English. For example, "He's a
nerdoid" means that he superficially resembles a nerd but can't
make the grade; a `modemoid' might be a 300-baud box (Real Modems
run at 9600 or up); a `computeroid' might be any {bitty box}.
The word `keyboid' could be used to describe a {chiclet
keyboard}, but would have to be written; spoken, it would confuse
the listener as to the speaker's city of origin. 2. More
specifically, an indicator for `resembling an android' which in
the past has been confined to science-fiction fans and hackers. It
too has recently (in 1991) started to go mainstream (most notably
in the term `trendoid' for victims of terminal hipness). This is
probably traceable to the popularization of the term {droid} in
"Star Wars" and its sequels. (See also {windoid}.)

Coinages in both forms have been common in science fiction for at
least fifty years, and hackers (who are often SF fans) have
probably been making `-oid' jargon for almost that long
[though GLS and I can personally confirm only that they were
already common in the mid-1970s --ESR].

:-ware: /suff./ [from `software'] Commonly used to form
jargon terms for classes of software. For examples, see
{careware}, {crippleware}, {crudware}, {freeware},
{fritterware}, {guiltware}, {liveware}, {meatware},
{payware}, {psychedelicware}, {shareware}, {shelfware},
{vaporware}, {wetware}.

:/dev/null: /dev-nuhl/ /n./ [from the Unix null device, used
as a data sink] A notional `black hole' in any information space
being discussed, used, or referred to. A controversial posting,
for example, might end "Kudos to [email protected], flames to
/dev/null". See {bit bucket}.

:0: Numeric zero, as opposed to the letter `O' (the 15th
letter of the English alphabet). In their unmodified forms they
look a lot alike, and various kluges invented to make them visually
distinct have compounded the confusion. If your zero is
center-dotted and letter-O is not, or if letter-O looks almost
rectangular but zero looks more like an American football stood on
end (or the reverse), you're probably looking at a modern character
display (though the dotted zero seems to have originated as an
option on IBM 3270 controllers). If your zero is slashed but
letter-O is not, you're probably looking at an old-style ASCII
graphic set descended from the default typewheel on the venerable
ASR-33 Teletype (Scandinavians, for whom Slashed-O is a letter,
curse this arrangement). If letter-O has a slash across it and the
zero does not, your display is tuned for a very old convention used
at IBM and a few other early mainframe makers (Scandinavians curse
*this* arrangement even more, because it means two of their
letters collide). Some Burroughs/Unisys equipment displays a zero
with a *reversed* slash. And yet another convention common on
early line printers left zero unornamented but added a tail or hook
to the letter-O so that it resembled an inverted Q or cursive
capital letter-O (this was endorsed by a draft ANSI standard for
how to draw ASCII characters, but the final standard changed the
distinguisher to a tick-mark in the upper-left corner). Are we
sufficiently confused yet?

:1TBS: // /n./ The "One True Brace Style"; see {indent
style}.

:120 reset: /wuhn-twen'tee ree'set/ /n./ [from 120 volts,
U.S. wall voltage] To cycle power on a machine in order to reset or
unjam it. Compare {Big Red Switch}, {power cycle}.

:2: /infix./ In translation software written by hackers, infix
2 often represents the syllable *to* with the connotation
`translate to': as in dvi2ps (DVI to PostScript), int2string
(integer to string), and texi2roff (Texinfo to [nt]roff).

:@-party: /at'par`tee/ /n./ [from the @-sign in an Internet
address] (alt. `@-sign party' /at'si:n par`tee/) A
semi-closed party thrown for hackers at a science-fiction
convention (esp. the annual World Science Fiction Convention or
"Worldcon"); one must have a {network address} to get in, or
at least be in company with someone who does. One of the most
reliable opportunities for hackers to meet face to face with people
who might otherwise be represented by mere phosphor dots on their
screens. Compare {boink}.

The first recorded @-party was held at the Westercon (a California
SF convention) over the July 4th weekend in 1980. It is not clear
exactly when the canonical @-party venue shifted to the Worldcon
but it had certainly become established by Constellation in 1983.

:@Begin: // See {\begin}.

:\begin: // [from the LaTeX command] With \end, used
humorously in writing to indicate a context or to remark on the
surrounded text. For example:

\begin{flame}
Predicate logic is the only good programming
language. Anyone who would use anything else
is an idiot. Also, all computers should be
tredecimal instead of binary.
\end{flame}

The Scribe users at CMU and elsewhere used to use @Begin/@End in
an identical way (LaTeX was built to resemble Scribe). On Usenet,
this construct would more frequently be rendered as `<FLAME
ON>' and `<FLAME OFF>', or `#ifdef FLAME' and `#endif FLAME''.

:(Lexicon Entries End Here):

:Hacker Folklore: *****************

This appendix contains several legends and fables that illuminate the meaning of various entries in the lexicon.

:The Meaning of `Hack': =======================

"The word {hack} doesn't really have 69 different meanings", according to MIT hacker Phil Agre. "In fact, {hack} has only one meaning, an extremely subtle and profound one which defies articulation. Which connotation is implied by a given use of the word depends in similarly profound ways on the context. Similar remarks apply to a couple of other hacker words, most notably {random}."

Hacking might be characterized as `an appropriate application of ingenuity'. Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it.

An important secondary meaning of {hack} is `a creative practical joke'. This kind of hack is easier to explain to non-hackers than the programming kind. Of course, some hacks have both natures; see the lexicon entries for {pseudo} and {kgbvax}. But here are some examples of pure practical jokes that illustrate the hacking spirit:

In 1961, students from Caltech (California Institute of
Technology, in Pasadena) hacked the Rose Bowl football game. One
student posed as a reporter and `interviewed' the director of the
University of Washington card stunts (such stunts involve people
in the stands who hold up colored cards to make pictures). The
reporter learned exactly how the stunts were operated, and also
that the director would be out to dinner later.

While the director was eating, the students (who called
themselves the `Fiendish Fourteen') picked a lock and stole a
blank direction sheet for the card stunts. They then had a
printer run off 2300 copies of the blank. The next day they
picked the lock again and stole the master plans for the stunts
-- large sheets of graph paper colored in with the stunt
pictures. Using these as a guide, they made new instructions for
three of the stunts on the duplicated blanks. Finally, they
broke in once more, replacing the stolen master plans and
substituting the stack of diddled instruction sheets for the
original set.

The result was that three of the pictures were totally different.
Instead of `WASHINGTON', the word ``CALTECH' was flashed. Another
stunt showed the word `HUSKIES', the Washington nickname, but
spelled it backwards. And what was supposed to have been a picture of
a husky instead showed a beaver. (Both Caltech and MIT use the beaver
--- nature's engineer -- as a mascot.)

After the game, the Washington faculty athletic representative
said: "Some thought it ingenious; others were indignant." The
Washington student body president remarked: "No hard feelings,
but at the time it was unbelievable. We were amazed."

This is now considered a classic hack, particularly because revising the direction sheets constituted a form of programming.

Here is another classic hack:

On November 20, 1982, MIT hacked the Harvard-Yale football game.
Just after Harvard's second touchdown against Yale, in the first
quarter, a small black ball popped up out of the ground at the
40-yard line, and grew bigger, and bigger, and bigger. The
letters `MIT' appeared all over the ball. As the players and
officials stood around gawking, the ball grew to six feet in
diameter and then burst with a bang and a cloud of white smoke.

The "Boston Globe" later reported: "If you want to know the
truth, MIT won The Game."

The prank had taken weeks of careful planning by members of MIT's
Delta Kappa Epsilon fraternity. The device consisted of a
weather balloon, a hydraulic ram powered by Freon gas to lift it
out of the ground, and a vacuum-cleaner motor to inflate it.
They made eight separate expeditions to Harvard Stadium between 1
and 5 A.M., locating an unused 110-volt circuit in the stadium
and running buried wires from the stadium circuit to the 40-yard
line, where they buried the balloon device. When the time came
to activate the device, two fraternity members had merely to flip
a circuit breaker and push a plug into an outlet.

This stunt had all the earmarks of a perfect hack: surprise,
publicity, the ingenious use of technology, safety, and
harmlessness. The use of manual control allowed the prank to be
timed so as not to disrupt the game (it was set off between
plays, so the outcome of the game would not be unduly affected).
The perpetrators had even thoughtfully attached a note to the
balloon explaining that the device was not dangerous and
contained no explosives.

Harvard president Derek Bok commented: "They have an awful lot of
clever people down there at MIT, and they did it again."
President Paul E. Gray of MIT said: "There is absolutely no truth
to the rumor that I had anything to do with it, but I wish there
were."

The hacks above are verifiable history; they can be proved to have happened. Many other classic-hack stories from MIT and elsewhere, though retold as history, have the characteristics of what Jan Brunvand has called `urban folklore' (see {FOAF}). Perhaps the best known of these is the legend of the infamous trolley-car hack, an alleged incident in which engineering students are said to have welded a trolley car to its tracks with thermite. Numerous versions of this have been recorded from the 1940s to the present, most set at MIT but at least one very detailed version set at CMU.

Brian Leibowitz has researched MIT hacks both real and mythical extensively; the interested reader is referred to his delightful pictorial compendium "The Journal of the Institute for Hacks, Tomfoolery, and Pranks" (MIT Museum, 1990; ISBN 0-917027-03-5). The Institute has a World Wide Web page at http://fishwrap.mit.edu/Hacks/Gallery.html.

Finally, here is a story about one of the classic computer hacks.

Back in the mid-1970s, several of the system support staff at
Motorola discovered a relatively simple way to crack system
security on the Xerox CP-V timesharing system. Through a simple
programming strategy, it was possible for a user program to trick
the system into running a portion of the program in `master mode'
(supervisor state), in which memory protection does not apply.
The program could then poke a large value into its `privilege
level' byte (normally write-protected) and could then proceed to
bypass all levels of security within the file-management system,
patch the system monitor, and do numerous other interesting
things. In short, the barn door was wide open.

Motorola quite properly reported this problem to Xerox via an
official `level 1 SIDR' (a bug report with an intended urgency of
`needs to be fixed yesterday'). Because the text of each SIDR
was entered into a database that could be viewed by quite a
number of people, Motorola followed the approved procedure: they
simply reported the problem as `Security SIDR', and attached all
of the necessary documentation, ways-to-reproduce, etc.

The CP-V people at Xerox sat on their thumbs; they either didn't
realize the severity of the problem, or didn't assign the
necessary operating-system-staff resources to develop and
distribute an official patch.

Months passed. The Motorola guys pestered their Xerox
field-support rep, to no avail. Finally they decided to take
direct action, to demonstrate to Xerox management just how easily
the system could be cracked and just how thoroughly the security
safeguards could be subverted.

They dug around in the operating-system listings and devised a
thoroughly devilish set of patches. These patches were then
incorporated into a pair of programs called `Robin Hood' and
`Friar Tuck'. Robin Hood and Friar Tuck were designed to run as
`ghost jobs' (daemons, in Unix terminology); they would use the
existing loophole to subvert system security, install the
necessary patches, and then keep an eye on one another's statuses
in order to keep the system operator (in effect, the superuser)
from aborting them.

One fine day, the system operator on the main CP-V software
development system in El Segundo was surprised by a number of
unusual phenomena. These included the following:

* Tape drives would rewind and dismount their tapes in the
middle of a job.
* Disk drives would seek back and forth so rapidly that they
would attempt to walk across the floor (see {walking
drives}).
* The card-punch output device would occasionally start up of
itself and punch a {lace card}. These would usually jam in
the punch.
* The console would print snide and insulting messages from
Robin Hood to Friar Tuck, or vice versa.
* The Xerox card reader had two output stackers; it could be
instructed to stack into A, stack into B, or stack into A
(unless a card was unreadable, in which case the bad card
was placed into stacker B). One of the patches installed by
the ghosts added some code to the card-reader
driver... after reading a card, it would flip over to the
opposite stacker. As a result, card decks would divide
themselves in half when they were read, leaving the operator
to recollate them manually.

Naturally, the operator called in the operating-system
developers. They found the bandit ghost jobs running, and
{gun}ned them... and were once again surprised. When Robin Hood
was gunned, the following sequence of events took place:

!X id1

id1: Friar Tuck... I am under attack! Pray save me!
id1: Off (aborted)

id2: Fear not, friend Robin! I shall rout the Sheriff
of Nottingham's men!

id1: Thank you, my good fellow!

Each ghost-job would detect the fact that the other had been
killed, and would start a new copy of the recently slain program
within a few milliseconds. The only way to kill both ghosts was
to kill them simultaneously (very difficult) or to deliberately
crash the system.

Finally, the system programmers did the latter -- only to find
that the bandits appeared once again when the system rebooted!
It turned out that these two programs had patched the boot-time
OS image (the kernel file, in Unix terms) and had added
themselves to the list of programs that were to be started at
boot time (this is similar to the way MS-DOS viruses propagate).

The Robin Hood and Friar Tuck ghosts were finally eradicated when
the system staff rebooted the system from a clean boot-tape and
reinstalled the monitor. Not long thereafter, Xerox released a
patch for this problem.

It is alleged that Xerox filed a complaint with Motorola's
management about the merry-prankster actions of the two employees
in question. It is not recorded that any serious disciplinary
action was taken against either of them.

:TV Typewriters: A Tale of Hackish Ingenuity ============================================

Here is a true story about a glass tty: One day an MIT hacker was in a motorcycle accident and broke his leg. He had to stay in the hospital quite a while, and got restless because he couldn't {hack}. Two of his friends therefore took a terminal and a modem for it to the hospital, so that he could use the computer by telephone from his hospital bed.

Now this happened some years before the spread of home computers, and computer terminals were not a familiar sight to the average person. When the two friends got to the hospital, a guard stopped them and asked what they were carrying. They explained that they wanted to take a computer terminal to their friend who was a patient.

The guard got out his list of things that patients were permitted to have in their rooms: TV, radio, electric razor, typewriter, tape player, ... no computer terminals. Computer terminals weren't on the list, so the guard wouldn't let it in. Rules are rules, you know. (This guard was clearly a {droid}.)

Fair enough, said the two friends, and they left again. They were frustrated, of course, because they knew that the terminal was as harmless as a TV or anything else on the list... which gave them an idea.

The next day they returned, and the same thing happened: a guard stopped them and asked what they were carrying. They said: "This is a TV typewriter!" The guard was skeptical, so they plugged it in and demonstrated it. "See? You just type on the keyboard and what you type shows up on the TV screen." Now the guard didn't stop to think about how utterly useless a typewriter would be that didn't produce any paper copies of what you typed; but this was clearly a TV typewriter, no doubt about it. So he checked his list: "A TV is all right, a typewriter is all right ... okay, take it on in!"

[Historical note: Many years ago, "Popular Electronics" published solder-it-yourself plans for a TV typewriter. Despite the essential uselessness of the device, it was an enormously popular project. Steve Ciarcia, the man behind "Byte" magazine's "Circuit Cellar" feature, resurrected this ghost in one of his books of the early 1980s. He ascribed its popularity (no doubt correctly) to the feeling of power the builder could achieve by being able to decide himself what would be shown on the TV. --ESR]

[Antihistorical note: On September 23rd, 1992, the L.A. Times ran the following bit of filler:

Solomon Waters of Altadena, a 6-year-old first-grader, came home
from his first day of school and excitedly told his mother how he
had written on "a machine that looks like a computer -- but
without the TV screen." She asked him if it could have been a
"typewriter." "Yeah! Yeah!" he said. "That's what it was
called."

I have since investigated this matter and determined that many of today's teenagers have never seen a slide rule, either.... -- ESR]

:A Story About `Magic': =======================

Some years ago, I (GLS) was snooping around in the cabinets that housed the MIT AI Lab's PDP-10, and noticed a little switch glued to the frame of one cabinet. It was obviously a homebrew job, added by one of the lab's hardware hackers (no one knows who).

You don't touch an unknown switch on a computer without knowing what it does, because you might crash the computer. The switch was labeled in a most unhelpful way. It had two positions, and scrawled in pencil on the metal switch body were the words `magic' and `more magic'. The switch was in the `more magic' position.

I called another hacker over to look at it. He had never seen the switch before either. Closer examination revealed that the switch had only one wire running to it! The other end of the wire did disappear into the maze of wires inside the computer, but it's a basic fact of electricity that a switch can't do anything unless there are two wires connected to it. This switch had a wire connected on one side and no wire on its other side.

It was clear that this switch was someone's idea of a silly joke. Convinced by our reasoning that the switch was inoperative, we flipped it. The computer instantly crashed.

Imagine our utter astonishment. We wrote it off as coincidence, but nevertheless restored the switch to the `more magic' position before reviving the computer.

A year later, I told this story to yet another hacker, David Moon as I recall. He clearly doubted my sanity, or suspected me of a supernatural belief in the power of this switch, or perhaps thought I was fooling him with a bogus saga. To prove it to him, I showed him the very switch, still glued to the cabinet frame with only one wire connected to it, still in the `more magic' position. We scrutinized the switch and its lone connection, and found that the other end of the wire, though connected to the computer wiring, was connected to a ground pin. That clearly made the switch doubly useless: not only was it electrically nonoperative, but it was connected to a place that couldn't affect anything anyway. So we flipped the switch.

The computer promptly crashed.

This time we ran for Richard Greenblatt, a long-time MIT hacker, who was close at hand. He had never noticed the switch before, either. He inspected it, concluded it was useless, got some diagonal cutters and {dike}d it out. We then revived the computer and it has run fine ever since.

We still don't know how the switch crashed the machine. There is a theory that some circuit near the ground pin was marginal, and flipping the switch changed the electrical capacitance enough to upset the circuit as millionth-of-a-second pulses went through it. But we'll never know for sure; all we can really say is that the switch was {magic}.

I still have that switch in my basement. Maybe I'm silly, but I usually keep it set on `more magic'.

1994: Another explanation of this story has since been offered. Note that the switch body was metal. Suppose that the non-connected side of the switch was connected to the switch body (usually the body is connected to a separate earth lug, but there are exceptions). The body is connected to the computer case, which is, presumably, grounded. Now the circuit ground within the machine isn't necessarily at the same potential as the case ground, so flipping the switch connected the circuit ground to the case ground, causing a voltage drop/jump which reset the machine. This was probably discovered by someone who found out the hard way that there was a potential difference between the two, and who then wired in the switch as a joke.

:AI Koans: ==========

These are some of the funniest examples of a genre of jokes told at the MIT AI Lab about various noted hackers. The original koans were composed by Danny Hillis. In reading these, it is at least useful to know that Minsky, Sussman, and Drescher are AI researchers of note, that Tom Knight was one of the Lisp machine's principal designers, and that David Moon wrote much of Lisp Machine Lisp.

* * *

A novice was trying to fix a broken Lisp machine by turning the
power off and on.

Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."

Knight turned the machine off and on.

The machine worked.

* * *

One day a student came to Moon and said: "I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons."

Moon patiently told the student the following story:

"One day a student came to Moon and said: `I understand how to
make a better garbage collector...

[Ed. note: Pure reference-count garbage collectors have problems with circular structures that point to themselves.]

* * *

In the days when Sussman was a novice, Minsky once came to him as he sat hacking at the PDP-6.

"What are you doing?", asked Minsky.

"I am training a randomly wired neural net to play Tic-Tac-Toe"
Sussman replied.

"Why is the net wired randomly?", asked Minsky.

"I do not want it to have any preconceptions of how to play",
Sussman said.

Minsky then shut his eyes.

"Why do you close your eyes?", Sussman asked his teacher.

"So that the room will be empty."

At that moment, Sussman was enlightened.

* * *

A disciple of another sect once came to Drescher as he was eating
his morning meal.

"I would like to give you this personality test", said the
outsider, "because I want you to be happy."

Drescher took the paper that was offered him and put it into the
toaster, saying: "I wish the toaster to be happy, too."

:OS and JEDGAR: ===============

This story says a lot about the ITS ethos.

On the ITS system there was a program that allowed you to see what was being printed on someone else's terminal. It spied on the other guy's output by examining the insides of the monitor system. The output spy program was called OS. Throughout the rest of the computer science (and at IBM too) OS means `operating system', but among old-time ITS hackers it almost always meant `output spy'.

OS could work because ITS purposely had very little in the way of `protection' that prevented one user from trespassing on another's areas. Fair is fair, however. There was another program that would automatically notify you if anyone started to spy on your output. It worked in exactly the same way, by looking at the insides of the operating system to see if anyone else was looking at the insides that had to do with your output. This `counterspy' program was called JEDGAR (a six-letterism pronounced as two syllables: /jed'gr/), in honor of the former head of the FBI.

But there's more. JEDGAR would ask the user for `license to kill'. If the user said yes, then JEDGAR would actually {gun} the job of the {luser} who was spying. Unfortunately, people found that this made life too violent, especially when tourists learned about it. One of the systems hackers solved the problem by replacing JEDGAR with another program that only pretended to do its job. It took a long time to do this, because every copy of JEDGAR had to be patched. To this day no one knows how many people never figured out that JEDGAR had been defanged.

Interestingly, there is still a security module named JEDGAR alive as of late 1994 -- in the Unisys MCP for large systems. It is unknown to us whether the name is tribute or independent invention.

:The Story of Mel, a Real Programmer: =====================================

This was posted to Usenet by its author, Ed Nather (utastro!nather), on May 21, 1983.

A recent article devoted to the *macho* side of programming
made the bald and unvarnished statement:

Real Programmers write in FORTRAN.

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster -- drum-memory computer.
Cores cost too much,
and weren't here to stay, anyway.
(That's why you haven't heard of the company,
or the computer.)

I had been hired to write a FORTRAN compiler
for this new marvel and Mel was my guide to its wonders.
Mel didn't approve of compilers.

"If a program can't rewrite its own code",
he asked, "what good is it?"

Mel had written,
in hexadecimal,
the most popular computer program the company owned.
It ran on the LGP-30
and played blackjack with potential customers
at computer shows.
Its effect was always dramatic.
The LGP-30 booth was packed at every show,
and the IBM salesmen stood around
talking to each other.
Whether or not this actually sold computers
was a question we never discussed.

Mel's job was to re-write
the blackjack program for the RPC-4000.
(Port? What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.

In modern parlance,
every single instruction was followed by a GO TO!
Put *that* in Pascal's pipe and smoke it.

Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the "read head"
and available for immediate execution.
There was a program to do that job,
an "optimizing assembler",
but Mel refused to use it.

"You never know where it's going to put things",
he explained, "so you'd have to use separate constants".

It was a long time before I understood that remark.
Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier "add" instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.

I compared Mel's hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel's always ran faster.
That was because the "top-down" method of program design
hadn't been invented yet,
and Mel wouldn't have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn't smart enough to do it that way.

Mel never wrote time-delay loops, either,
even when the balky Flexowriter
required a delay between output characters to work right.
He just located instructions on the drum
so each successive one was just *past* the read head
when it was needed;
the drum had to execute another complete revolution
to find the next instruction.
He coined an unforgettable term for this procedure.
Although "optimum" is an absolute term,
like "unique", it became common verbal practice
to make it relative:
"not quite optimum" or "less optimum"
or "not very optimum".
Mel called the maximum time-delay locations
the "most pessimum".

After he finished the blackjack program
and got it to run
("Even the initializer is optimized",
he said proudly),
he got a Change Request from the sales department.
The program used an elegant (optimized)
random number generator
to shuffle the "cards" and deal from the "deck",
and some of the salesmen felt it was too fair,
since sometimes the customers lost.
They wanted Mel to modify the program
so, at the setting of a sense switch on the console,
they could change the odds and let the customer win.

Mel balked.
He felt this was patently dishonest,
which it was,
and that it impinged on his personal integrity as a programmer,
which it did,
so he refused to do it.
The Head Salesman talked to Mel,
as did the Big Boss and, at the boss's urging,
a few Fellow Programmers.
Mel finally gave in and wrote the code,
but he got the test backwards,
and, when the sense switch was turned on,
the program would cheat, winning every time.
Mel was delighted with this,
claiming his subconscious was uncontrollably ethical,
and adamantly refused to fix it.

After Mel had left the company for greener pa$ture$,
the Big Boss asked me to look at the code
and see if I could find the test and reverse it.
Somewhat reluctantly, I agreed to look.
Tracking Mel's code was a real adventure.

I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.

Perhaps my greatest shock came
when I found an innocent loop that had no test in it.
No test. *None*.
Common sense said it had to be a closed loop,
where the program would circle, forever, endlessly.
Program control passed right through it, however,
and safely out the other side.
It took me two weeks to figure it out.

The RPC-4000 computer had a really modern facility
called an index register.
It allowed the programmer to write a program loop
that used an indexed instruction inside;
each time through,
the number in the index register
was added to the address of that instruction,
so it would refer
to the next datum in a series.
He had only to increment the index register
each time through.
Mel never used it.

Instead, he would pull the instruction into a machine register,
add one to its address,
and store it back.
He would then execute the modified instruction
right from the register.
The loop was written so this additional execution time
was taken into account ---
just as this instruction finished,
the next one was right under the drum's read head,
ready to go.
But the loop had no test in it.

The vital clue came when I noticed
the index register bit,
the bit that lay between the address
and the operation code in the instruction word,
was turned on ---
yet Mel never used the index register,
leaving it zero all the time.
When the light went on it nearly blinded me.

He had located the data he was working on
near the top of memory ---
the largest locations the instructions could address ---
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.

I haven't kept in touch with Mel,
so I don't know if he ever gave in to the flood of
change that has washed over programming techniques
since those long-gone days.
I like to think he didn't.
In any event,
I was impressed enough that I quit looking for the
offending test,
telling the Big Boss I couldn't find it.
He didn't seem surprised.