Part 40

:This time, for sure!: excl. Ritual affirmation frequently uttered during protracted debugging sessions involving numerous small obstacles (e.g., attempts to bring up a UUCP connection). For the proper effect, this must be uttered in a fruity imitation of Bullwinkle J. Moose. Also heard: "Hey, Rocky! Watch me pull a rabbit out of my hat!" The {canonical} response is, of course, "But that trick *never* works!" See {{Humor, Hacker}}.

:thrash: vi. To move wildly or violently, without accomplishing anything useful. Paging or swapping systems that are overloaded waste most of their time moving data into and out of core (rather than performing useful computation) and are therefore said to thrash. Someone who keeps changing his mind (esp. about what to work on next) is said to be thrashing. A person frantically trying to execute too many tasks at once (and not spending enough time on any single task) may also be described as thrashing. Compare {multitask}.

:thread: n. [USENET, GEnie, CompuServe] Common abbreviation of `topic thread', a more or less continuous chain of postings on a single topic. To `follow a thread' is to read a series of USENET postings sharing a common subject or (more correctly) which are connected by Reference headers. The better newsreaders present news in thread order.

:three-finger salute: n. Syn. {Vulcan nerve pinch}.

:thud: n. 1. Yet another {metasyntactic variable} (see {foo}). It is reported that at CMU from the mid-1970s the canonical series of these was `foo', `bar', `thud', `blat'. 2. Rare term for the hash character, `#' (ASCII 0100011). See {ASCII} for other synonyms.

:thumb: n. The slider on a window-system scrollbar. So called because moving it allows you to browse through the contents of a text window in a way analogous to thumbing through a book.

:thunk: /thuhnk/ n. 1. "A piece of coding which provides an address", according to P. Z. Ingerman, who invented thunks in 1961 as a way of binding actual parameters to their formal definitions in Algol-60 procedure calls. If a procedure is called with an expression in the place of a formal parameter, the compiler generates a {thunk} to compute the expression and leave the address of the result in some standard location. 2. Later generalized into: an expression, frozen together with its environment, for later evaluation if and when needed (similar to what in techspeak is called a `closure'). The process of unfreezing these thunks is called `forcing'. 3. A {stubroutine}, in an overlay programming environment, that loads and jumps to the correct overlay. Compare {trampoline}. 4. People and activities scheduled in a thunklike manner. "It occurred to me the other day that I am rather accurately modeled by a thunk --- I frequently need to be forced to completion." --- paraphrased from a {plan file}.

Historical note: There are a couple of onomatopoeic myths circulating about the origin of this term. The most common is that it is the sound made by data hitting the stack; another holds that the sound is that of the data hitting an accumulator. Yet another holds that it is the sound of the expression being unfrozen at argument-evaluation time. In fact, according to the inventors, it was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought, simplifying the evaluation machinery. In other words, it had `already been thought of'; thus it was christened a `thunk', which is "the past tense of `think' at two in the morning".

:tick: n. 1. A {jiffy} (sense 1). 2. In simulations, the discrete unit of time that passes between iterations of the simulation mechanism. In AI applications, this amount of time is often left unspecified, since the only constraint of interest is the ordering of events. This sort of AI simulation is often pejoratively referred to as `tick-tick-tick' simulation, especially when the issue of simultaneity of events with long, independent chains of causes is {handwave}d. 3. In the FORTH language, a single quote character.

:tick-list features: [Acorn Computers] n. Features in software or hardware that customers insist on but never use (calculators in desktop TSRs and that sort of thing). The American equivalent would be `checklist features', but this jargon sense of the phrase has not been reported.

:tickle a bug: vt. To cause a normally hidden bug to manifest through some known series of inputs or operations. "You can tickle the bug in the Paradise VGA card's highlight handling by trying to set bright yellow reverse video."

:tiger team: [U.S. military jargon] n. 1. Originally, a team whose purpose is to penetrate security, and thus test security measures. These people are paid professionals who do hacker-type tricks, e.g., leave cardboard signs saying "bomb" in critical defense installations, hand-lettered notes saying "Your codebooks have been stolen" (they usually haven't been) inside safes, etc. After a successful penetration, some high-ranking security type shows up the next morning for a `security review' and finds the sign, note, etc., and all hell breaks loose. Serious successes of tiger teams sometimes lead to early retirement for base commanders and security officers (see the {patch} entry for an example). 2. Recently, and more generally, any official inspection team or special {firefighting} group called in to look at a problem.

A subset of tiger teams are professional {cracker}s, testing the security of military computer installations by attempting remote attacks via networks or supposedly `secure' comm channels. Some of their escapades, if declassified, would probably rank among the greatest hacks of all times. The term has been adopted in commercial computer-security circles in this more specific sense.

:time sink: [poss. by analogy with `heat sink' or `current sink'] n. A project that consumes unbounded amounts of time.

:time T: /ti:m T/ n. 1. An unspecified but usually well-understood time, often used in conjunction with a later time T+1. "We'll meet on campus at time T or at Louie's at time T+1" means, in the context of going out for dinner: "We can meet on campus and go to Louie's, or we can meet at Louie's itself a bit later." (Louie's was a Chinese restaurant in Palo Alto that was a favorite with hackers.) Had the number 30 been used instead of the number 1, it would have implied that the travel time from campus to Louie's is 30 minutes; whatever time T is (and that hasn't been decided on yet), you can meet half an hour later at Louie's than you could on campus and end up eating at the same time. See also {since time T equals minus infinity}.

:times-or-divided-by: [by analogy with `plus-or-minus'] quant. Term occasionally used when describing the uncertainty associated with a scheduling estimate, for either humorous or brutally honest effect. For a software project, the scheduling uncertainty factor is usually at least 2.

:tinycrud: /ti:'nee-kruhd/ n. 1. A pejorative used by habitues of older game-oriented {MUD} versions for TinyMUDs and other user-extensible {MUD} variants; esp. common among users of the rather violent and competitive AberMUD and MIST systems. These people justify the slur on the basis of how (allegedly) inconsistent and lacking in genuine atmosphere the scenarios generated in user extensible MUDs can be. Other common knocks on them are that they feature little overall plot, bad game topology, little competitive interaction, etc. --- not to mention the alleged horrors of the TinyMUD code itself. This dispute is one of the MUD world's hardiest perennial {holy wars}. 2. TinyMud-oriented chat on the USENET group rec.games.mud and elsewhere, especially {newbie} questions and flamage.

:tip of the ice-cube: [IBM] n. The visible part of something small and insignificant. Used as an ironic comment in situations where `tip of the iceberg' might be appropriate if the subject were at all important.

:tired iron: [IBM] n. Hardware that is perfectly functional but far enough behind the state of the art to have been superseded by new products, presumably with sufficient improvement in bang-per-buck that the old stuff is starting to look a bit like a {dinosaur}.

:tits on a keyboard: n. Small bumps on certain keycaps to keep touch-typists registered (usually on the `5' of a numeric keypad, and on the `F' and `J' of a QWERTY keyboard; but the Mac, perverse as usual, has them on the `D' and `K' keys).

:TLA: /T-L-A/ [Three-Letter Acronym] n. 1. Self-describing abbreviation for a species with which computing terminology is infested. 2. Any confusing acronym. Examples include MCA, FTP, SNA, CPU, MMU, SCCS, DMU, FPU, NNTP, TLA. People who like this looser usage argue that not all TLAs have three letters, just as not all four-letter words have four letters. One also hears of `ETLA' (Extended Three-Letter Acronym, pronounced /ee tee el ay/) being used to describe four-letter acronyms. The term `SFLA' (Stupid Four-Letter Acronym) has also been reported. See also {YABA}.

The self-effacing phrase "TDM TLA" (Too Damn Many...) is often used to bemoan the plethora of TLAs in use. In 1989, a random of the journalistic persuasion asked hacker Paul Boutin "What do you think will be the biggest problem in computing in the 90s?" Paul's straight-faced response: "There are only 17,000 three-letter acronyms." (To be exact, there are 26^3 = 17,576.)

:TMRC: /tmerk'/ n. The Tech Model Railroad Club at MIT, one of the wellsprings of hacker culture. The 1959 `Dictionary of the TMRC Language' compiled by Peter Samson included several terms which became basics of the hackish vocabulary (see esp. {foo} and {frob}).

By 1962, TMRC's legendary layout was already a marvel of complexity (and has grown in the thirty years since; all the features described here are still present). The control system alone featured about 1200 relays. There were {scram switch}es located at numerous places around the room that could be thwacked if something undesirable was about to occur, such as a train going full-bore at an obstruction. Another feature of the system was a digital clock on the dispatch, board, which was itself something of a wonder in those bygone days before cheap LEDS and seven-segment displays (no model railroad can begin to approximate the scale distances between towns and stations, so model railroad timetables assume a fast clock so that it seems to take about the right amount of time for a train to complete its journey). When someone hit a scram switch the clock stopped and the display was replaced with the word `FOO'; at TMRC the scram switches are therefore called `foo switches'.

Steven Levy, in his book `Hackers' (see the Bibliography in {appendix C}), gives a stimulating account of those early years. TMRC's Power and Signals group included most of the early PDP-1 hackers and the people who later bacame the core of the MIT AI Lab staff. Thirty years later that connection is still very much alive, and this lexicon accordingly includes a number of entries from a recent revision of the TMRC Dictionary.

:TMRCie: /tmerk'ee/, /tuh-merk'ee/ [MIT] n. A denizen of {TMRC}.

:to a first approximation: 1. [techspeak] When one is doing certain numerical computations, an approximate solution may be computed by any of several heuristic methods, then refined to a final value. By using the starting point of a first approximation of the answer, one can write an algorithm that converges more quickly to the correct result. 2. In jargon, a preface to any comment that indicates that the comment is only approximately true. The remark "To a first approximation, I feel good" might indicate that deeper questioning would reveal that not all is perfect (e.g., a nagging cough still remains after an illness).

:to a zeroth approximation: [from `to a first approximation'] A *really* sloppy approximation; a wild guess. Compare {social science number}.

:toast: 1. n. Any completely inoperable system or component, esp. one that has just crashed and burned: "Uh, oh ... I think the serial board is toast." 2. vt. To cause a system to crash accidentally, especially in a manner that requires manual rebooting. "Rick just toasted the {firewall machine} again."

:toaster: n. 1. The archetypal really stupid application for an embedded microprocessor controller; often used in comments that imply that a scheme is inappropriate technology (but see {elevator controller}). "{DWIM} for an assembler? That'd be as silly as running UNIX on your toaster!" 2. A very, very dumb computer. "You could run this program on any dumb toaster." See {bitty box}, {Get a real computer!}, {toy}, {beige toaster}. 3. A Macintosh, esp. the Classic Mac. Some hold that this is implied by sense 2. 4. A peripheral device. "I bought my box without toasters, but since then I've added two boards and a second disk drive."

:toeprint: n. A {footprint} of especially small size.

:toggle: vt. To change a {bit} from whatever state it is in to the other state; to change from 1 to 0 or from 0 to 1. This comes from `toggle switches', such as standard light switches, though the word `toggle' actually refers to the mechanism that keeps the switch in the position to which it is flipped rather than to the fact that the switch has two positions. There are four things you can do to a bit: set it (force it to be 1), clear (or zero) it, leave it alone, or toggle it. (Mathematically, one would say that there are four distinct boolean-valued functions of one boolean argument, but saying that is much less fun than talking about toggling bits.)

:tool: 1. n. A program used primarily to create, manipulate, modify, or analyze other programs, such as a compiler or an editor or a cross-referencing program. Oppose {app}, {operating system}. 2. [UNIX] An application program with a simple, `transparent' (typically text-stream) interface designed specifically to be used in programmed combination with other tools (see {filter}). 3. [MIT: general to students there] vi. To work; to study (connotes tedium). The TMRC Dictionary defined this as "to set one's brain to the grindstone". See {hack}. 4. [MIT] n. A student who studies too much and hacks too little. (MIT's student humor magazine rejoices in the name `Tool and Die'.)

:toolsmith: n. The software equivalent of a tool-and-die specialist; one who specializes in making the {tool}s with which other programmers create applications. Many hackers consider this more fun than applications per se; to understand why, see {uninteresting}. Jon Bentley, in the "Bumper-Sticker Computer Science" chapter of his book `More Programming Pearls', quotes Dick Sites from DEC as saying "I'd rather write programs to write programs than write programs".

:topic drift: n. Term used on GEnie, USENET and other electronic fora to describe the tendency of a {thread} to drift away from the original subject of discussion (and thus, from the Subject header of the originating message), or the results of that tendency. Often used in gentle reminders that the discussion has strayed off any useful track. "I think we started with a question about Niven's last book, but we've ended up discussing the sexual habits of the common marmoset. Now *that's* topic drift!"

:topic group: n. Syn. {forum}.

:TOPS-10:: /tops-ten/ n. DEC's proprietary OS for the fabled {PDP-10} machines, long a favorite of hackers but now effectively extinct. A fountain of hacker folklore; see {appendix A}. See also {{ITS}}, {{TOPS-20}}, {{TWENEX}}, {VMS}, {operating system}. TOPS-10 was sometimes called BOTS-10 (from `bottoms-ten') as a comment on the inappropriateness of describing it as the top of anything.

:TOPS-20:: /tops-twen'tee/ n. See {{TWENEX}}.

:toto: /toh'toh/ n. This is reported to be the default scratch file name among French-speaking programmers --- in other words, a francophone {foo}. It is reported that the phonetic mutations "titi", "tata", and "tutu" canonically follow `toto', analogously to {bar}, {baz} and {quux} in English.

:tourist: [ITS] n. A guest on the system, especially one who generally logs in over a network from a remote location for {comm mode}, email, games, and other trivial purposes. One step below {luser}. Hackers often spell this {turist}, perhaps by some sort of tenuous analogy with {luser} (this also expresses the ITS culture's penchant for six-letterisms). Compare {twink}, {read-only user}.

:tourist information: n. Information in an on-line display that is not immediately useful, but contributes to a viewer's gestalt of what's going on with the software or hardware behind it. Whether a given piece of info falls in this category depends partly on what the user is looking for at any given time. The `bytes free' information at the bottom of an MS-DOS `dir' display is tourist information; so (most of the time) is the TIME information in a UNIX `ps(1)' display.

:touristic: adj. Having the quality of a {tourist}. Often used as a pejorative, as in `losing touristic scum'. Often spelled `turistic' or `turistik', so that phrase might be more properly rendered `lusing turistic scum'.

:toy: n. A computer system; always used with qualifiers. 1. `nice toy': One that supports the speaker's hacking style adequately. 2. `just a toy': A machine that yields insufficient {computron}s for the speaker's preferred uses. This is not condemnatory, as is {bitty box}; toys can at least be fun. It is also strongly conditioned by one's expectations; Cray XMP users sometimes consider the Cray-1 a `toy', and certainly all RISC boxes and mainframes are toys by their standards. See also {Get a real computer!}.

:toy language: n. A language useful for instructional purposes or as a proof-of-concept for some aspect of computer-science theory, but inadequate for general-purpose programming. {Bad Thing}s can result when a toy language is promoted as a general purpose solution for programming (see {bondage-and-discipline language}); the classic example is {{Pascal}}. Several moderately well-known formalisms for conceptual tasks such as programming Turing machines also qualify as toy languages in a less negative sense. See also {MFTL}.

:toy problem: [AI] n. A deliberately oversimplified case of a challenging problem used to investigate, prototype, or test algorithms for a real problem. Sometimes used pejoratively. See also {gedanken}, {toy program}.

:toy program: n. 1. One that can be readily comprehended; hence, a trivial program (compare {noddy}). 2. One for which the effort of initial coding dominates the costs through its life cycle. See also {noddy}.

:trampoline: n. An incredibly {hairy} technique, found in some {HLL} and program-overlay implementations (e.g., on the Macintosh), that involves on-the-fly generation of small executable (and, likely as not, self-modifying) code objects to do indirection between code sections. These pieces of {live data} are called `trampolines'. Trampolines are notoriously difficult to understand in action; in fact, it is said by those who use this term that the trampoline that doesn't bend your brain is not the true trampoline. See also {snap}.

:trap: 1. n. A program interrupt, usually an interrupt caused by some exceptional situation in the user program. In most cases, the OS performs some action, then returns control to the program. 2. vi. To cause a trap. "These instructions trap to the monitor." Also used transitively to indicate the cause of the trap. "The monitor traps all input/output instructions."

This term is associated with assembler programming (`interrupt' or `exception' is more common among {HLL} programmers) and appears to be fading into history among programmers as the role of assembler continues to shrink. However, it is still important to computer architects and systems hackers (see {system}, sense 1), who use it to distinguish deterministically repeatable exceptions from timing-dependent ones (such as I/O interrupts).

:trap door: alt. `trapdoor' n. 1. Syn. {back door} --- a {Bad Thing}. 2. [techspeak] A `trap-door function' is one which is easy to compute but very difficult to compute the inverse of. Such functions are {Good Thing}s with important applications in cryptography, specifically in the construction of public-key cryptosystems.

:trash: vt. To destroy the contents of (said of a data structure). The most common of the family of near-synonyms including {mung}, {mangle}, and {scribble}.

:trawl: v. To sift through large volumes of data (e.g. USENET postings or FTP archives) looking for something of interest.

:tree-killer: [Sun] n. 1. A printer. 2. A person who wastes paper. This should be interpreted in a broad sense; `wasting paper' includes the production of {spiffy} but {content-free} documents. Thus, most {suit}s are tree-killers. The negative loading of this term may reflect the epithet `tree-killer' applied by Treebeard the Ent to the Orcs in J.R.R. Tolkien's `Lord of the Rings' trilogy (see also {elvish}, {elder days}).

:trit: /trit/ [by analogy with `bit'] n. One base-3 digit; the amount of information conveyed by a selection among one of three equally likely outcomes (see also {bit}). These arise, for example, in the context of a {flag} that should actually be able to assume *three* values --- such as yes, no, or unknown. Trits are sometimes jokingly called `3-state bits'. A trit may be semi-seriously referred to as `a bit and a half', although it is linearly equivalent to 1.5849625 bits (that is, log2(3) bits).

:trivial: adj. 1. Too simple to bother detailing. 2. Not worth the speaker's time. 3. Complex, but solvable by methods so well known that anyone not utterly {cretinous} would have thought of them already. 4. Any problem one has already solved (some claim that hackish `trivial' usually evaluates to `I've seen it before'). Hackers' notions of triviality may be quite at variance with those of non-hackers. See {nontrivial}, {uninteresting}.

:troff: /tee'rof/ or /trof/ [UNIX] n. The gray eminence of UNIX text processing; a formatting and phototypesetting program, written originally in PDP-11 assembler and then in barely-structured early C by the late Joseph Ossana, modeled after the earlier ROFF which was in turn modeled after Multics' RUNOFF. A companion program, `nroff', formats output for terminals and line printers.

In 1979, Brian Kernighan modified TROFF so that it could drive phototypesetters other than the Graphic Systems CAT. His paper describing that work ("A Typesetter-independent TROFF," AT&T CSTR #97) explains `troff''s durability. After discussing the program's "obvious deficiencies --- a rebarbative input syntax, mysterious and undocumented properties in some areas, and a voracious appetite for computer resources" and noting the ugliness and extreme hairiness of the code and internals, Kernighan concludes: