WhatIs

/dek'hed/

n. 1. A DEC field servoid. Not flattering.

2. [from 'deadhead'] A Grateful Dead fan working at DEC.

/dek wȯrs/

n. A 1983 USENET posting by Alan Hastings and Steve Tarr spoofing the "Star Wars" movies in hackish terms. Some years later, ESR (disappointed by Hastings and Tarr's failure to exploit a great premise more thoroughly) posted a 3-times-longer complete rewrite called "UNIX WARS"; the two are often confused.

/deth stär/

[from the movie "Star Wars"]

1. The AT&T corporate logo, which appears on computers sold by AT&T and bears an uncanny resemblance to the 'Death Star' in the movie. This usage is particularly common among partisans of BSD UNIX, who tend to regard the AT&T versions as inferior and AT&T as a bad guy. Copies still circulate of a poster printed by Mt. Xinu showing a starscape with a space fighter labeled 4.2 BSD streaking away from a broken AT&T logo wreathed in flames.

/ded-lē im-ˈbrās/

n. Same as deadlock, though usually used only when exactly 2 processes are involved. This is the more popular term in Europe, while deadlock predominates in the United States.

/ded-ˌläk/

n. 1. [techspeak] A situation wherein two or more processes are unable to proceed because each is waiting for one of the others to do something. A common example is a program communicating to a server, which may find itself waiting for output from the server before sending anything more to it, while the server is similarly waiting for more input from the controlling program before outputting anything.

/ded-beef/

n. The hexadecimal word-fill pattern for freshly allocated memory (decimal -21524111) under a number of IBM environments, including the RS/6000. As in

"Your program is DEADBEEF"

(meaning gone, aborted, flushed from memory); if you start from an odd half-word boundary, of course, you have BEEFDEAD.

/ded kōd/

n. Routines that can never be accessed because all calls to them have been removed, or code that cannot be reached because it is guarded by a control structure that provably must always transfer control somewhere else. The presence of dead code may reveal either logical errors due to alterations in the program or significant changes in the assumptions and environment of the program (see also software rot); a good compiler should report dead code so a maintainer can think about what it means.

/dee-rez'/

[from 'de-resolve' via the movie "Tron"]

(also 'derez') 1. vi. To disappear or dissolve; the image that goes with it is of an object breaking up into raster lines and static and then dissolving. Occasionally used of a person who seems to have suddenly 'fuzzed out' mentally rather than physically. Usage: extremely silly, also rare. This verb was actually invented as *fictional* hacker jargon, and adopted in a spirit of irony by real hackers years after the fact.

/D-D-T/

n. 1. Generic term for a program that assists in debugging other programs by showing individual machine instructions in a readable symbolic form and letting the user change them. In this sense the term DDT is now archaic, having been widely displaced by 'debugger' or names of individual programs like 'dbx', 'adb', 'gdb', or 'sdb'.

2. [ITS] Under MIT's fabled ITS operating system, DDT (running under the alias HACTRN) was also used as the shell or top level command language used to execute other programs.

/dee-dee/

[UNIX: from IBM JCL]

vt. Equivalent to cat or BLT.

This was originally the name of a UNIX copy command with special options suitable for block-oriented devices. Often used in heavy-handed system maintenance, as in "Let's dd the root partition onto a tape, then use the boot PROM to load it back on to a new disk".