The New Hacker's Dictionary

1121

*[14028]voice-net:

*[14029]voodoo programming:

*[14030]VR:

*[14031]Vulcan nerve pinch:

*[14032]vulture capitalist:

---

Node:V7, Next:[14033]vadding, Previous:[14034]UUCPNET,

Up:[14035]= V =

V7 /V'sev'en/ n.

See [14036]Version 7.

---

Node:vadding, Next:[14037]vanilla, Previous:[14038]V7, Up:[14039]= V

=

vadding /vad'ing/ n.

[from VAD, a permutation of ADV (i.e., [14040]ADVENT), used to avoid a particular [14041]admin's continual search-and-destroy sweeps for the game] A leisure-time activity of certain hackers involving the covert exploration of the `secret' parts of large buildings -- basements, roofs, freight elevators, maintenance crawlways, steam tunnels, and the like. A few go so far as to learn locksmithing in order to synthesize vadding keys. The verb is `to vad' (compare [14042]phreaking; see also [14043]hack, sense 9). This term dates from the late 1970s, before which such activity was simply called `hacking'; the older usage is still prevalent at MIT.

1122

The most extreme and dangerous form of vadding is `elevator rodeo', a.k.a. `elevator surfing', a sport played by wrasslin' down a thousand-pound elevator car with a 3-foot piece of string, and then exploiting this mastery in various stimulating ways (such as elevator hopping, shaft exploration, rat-racing, and the ever-popular drop experiments). Kids, don't try this at home! See also [14044]hobbit (sense 2).

---

Node:vanilla, Next:[14045]vanity domain, Previous:[14046]vadding, Up:[14047]= V =

vanilla adj.

[from the default flavor of ice cream in the U.S.] Ordinary [14048]flavor, standard. When used of food, very often does not mean that the food is flavored with vanilla extract! For example, `vanilla wonton soup' means ordinary wonton soup, as opposed to hot-and-sour wonton soup. Applied to hardware and software, as in "Vanilla Version 7 Unix can't run on a vanilla 11/34." Also used to orthogonalize chip nomenclature; for instance, a 74V00 means what TI calls a 7400, as distinct from a 74LS00, etc. This word differs from [14049]canonical in that the latter means `default', whereas vanilla simply means `ordinary'. For example, when hackers go on a [14050]great-wall, hot-and-sour soup is the [14051]canonical soup to get (because that is what most of them usually order) even though it isn't the vanilla (wonton) soup.

---

Node:vanity domain, Next:[14052]vannevar, Previous:[14053]vanilla, Up:[14054]= V =

vanity domain n.

[common; from `vanity plate' as in car license plate] An Internet domain, particularly in the .com or .org top-level domains, apparently created for no

1123

reason other than boosting the creator's ego.

---

Node:vannevar, Next:[14055]vaporware, Previous:[14056]vanity domain, Up:[14057]= V =

vannevar /van'*-var/ n.

A bogus technological prediction or a foredoomed engineering concept, esp. one that fails by implicitly assuming that technologies develop linearly, incrementally, and in isolation from one another when in fact the learning curve tends to be highly nonlinear, revolutions are common, and competition is the rule. The prototype was Vannevar Bush's prediction of `electronic brains' the size of the Empire State Building with a Niagara-Falls-equivalent cooling system for their tubes and relays, a prediction made at a time when the semiconductor effect had already been demonstrated. Other famous vannevars have included magnetic-bubble memory, LISP machines, [14058]videotex, and a paper from the late 1970s that computed a purported ultimate limit on areal density for ICs that was in fact less than the routine densities of 5 years later.

---

Node:vaporware, Next:[14059]var, Previous:[14060]vannevar,

Up:[14061]= V =

vaporware /vay'pr-weir/ n.

Products announced far in advance of any release (which may or may not actually take place). See also [14062]brochureware.

---

Node:var, Next:[14063]vaston, Previous:[14064]vaporware, Up:[14065]=

V =

1124

var /veir/ or /var/ n.

Short for `variable'. Compare [14066]arg, [14067]param.

---

Node:vaston, Next:[14068]VAX, Previous:[14069]var, Up:[14070]= V =

vaston n.

[Durham, UK] The unit of `load average'. A measure of how much work a computer is doing. A meter displaying this as a function of time is known as a `vastometer'. First used during a computing practical in December 1996.

---

Node:VAX, Next:[14071]VAXectomy, Previous:[14072]vaston,

Up:[14073]= V =

VAX /vaks/ n.

1. [from Virtual Address eXtension] The most successful minicomputer design in industry history, possibly excepting its immediate ancestor, the PDP-11. Between its release in 1978 and its eclipse by [14074]killer micros after about 1986, the VAX was probably the hacker's favorite machine of them all, esp. after the 1982 release of 4.2 BSD Unix (see [14075]BSD). Esp. noted for its large, assembler-programmer-friendly instruction set -- an asset that became a liability after the RISC revolution. 2. A major brand of vacuum cleaner in Britain. Cited here because its sales pitch, "Nothing sucks like a VAX!" became a sort of battle-cry of RISC partisans. It is even sometimes claimed that DEC actually entered a cross-licensing deal with the vacuum-Vax people that allowed them to market VAX computers in the U.K. in return for not challenging the vacuum cleaner trademark in the U.S.

1125

A rival brand actually pioneered the slogan: its original form was "Nothing sucks like Electrolux". It has apparently become a classic example (used in advertising textbooks) of the perils of not knowing the local idiom. But in 1996, the press manager of Electrolux AB, while confirming that the company used this slogan in the late 1960s, also tells us that their marketing people were fully aware of the possible double entendre and intended it to gain attention.

And gain attention it did - the VAX-vacuum-cleaner people thought the slogan a sufficiently good idea to copy it. Several British hackers report that VAX's promotions used it in 1986-1987, and we have one report from a New Zealander that the infamous slogan surfaced there in TV ads for the product in 1992.

---

Node:VAXectomy, Next:[14076]VAXen, Previous:[14077]VAX,

Up:[14078]= V =

VAXectomy /vak-sek't*-mee/ n.

[by analogy with `vasectomy'] A VAX removal. [14079]DEC's Microvaxen, especially, are much slower than newer RISC-based workstations such as the SPARC. Thus, if one knows one has a replacement coming, VAX removal can be cause for celebration.

---

Node:VAXen, Next:[14080]vaxherd, Previous:[14081]VAXectomy,

Up:[14082]= V =

VAXen /vak'sn/ n.

[from `oxen', perhaps influenced by `vixen'] (alt. `vaxen') The plural canonically used among hackers for the [14083]DEC VAX computers. "Our installation has four PDP-10s and twenty vaxen." See [14084]boxen.

1126

---

Node:vaxherd, Next:[14085]vaxism, Previous:[14086]VAXen,

Up:[14087]= V =

vaxherd /vaks'herd/ n. obs.

[from `oxherd'] A VAX operator. The image is reinforced because VAXen actually did tend to come in herds, technically known as `clusters'.

---

Node:vaxism, Next:[14088]vaxocentrism, Previous:[14089]vaxherd,

Up:[14090]= V =

vaxism /vak'sizm/ n.

A piece of code that exhibits [14091]vaxocentrism in critical areas. Compare [14092]PC-ism, [14093]unixism.

---

Node:vaxocentrism, Next:[14094]vdiff, Previous:[14095]vaxism,

Up:[14096]= V =

vaxocentrism /vak`soh-sen'trizm/ n.

[analogy with `ethnocentrism'] A notional disease said to afflict C programmers who persist in coding according to certain assumptions that are valid (esp. under Unix) on [14097]VAXen but false elsewhere. Among these are: 1. The assumption that dereferencing a null pointer is safe because it is all bits 0, and location 0 is readable and 0. Problem: this may instead cause an illegal-address trap on non-VAXen, and even on VAXen under OSes other than BSD Unix. Usually this is an implicit assumption of sloppy code (forgetting to check the pointer before using it), rather than deliberate exploitation of a misfeature. 2. The assumption that characters

1127

are signed. 3. The assumption that a pointer to any one type can freely be cast into a pointer to any other type. A stronger form of this is the assumption that all pointers are the same size and format, which means you don't have to worry about getting the casts or types correct in calls. Problem: this fails on word-oriented machines or others with multiple pointer formats. 4. The assumption that the parameters of a routine are stored in memory, on a stack, contiguously, and in strictly ascending or descending order. Problem: this fails on many RISC architectures. 5. The assumption that pointer and integer types are the same size, and that pointers can be stuffed into integer variables (and vice-versa) and drawn back out without being truncated or mangled. Problem: this fails on segmented architectures or word-oriented machines with funny pointer formats. 6. The assumption that a data type of any size may begin at any byte address in memory (for example, that you can freely construct and dereference a pointer to a wordor greater-sized object at an odd char address). Problem: this fails on many (esp. RISC) architectures better optimized for [14098]HLL execution speed, and can cause an illegal address fault or bus error. 7. The (related) assumption that there is no padding at the end of types and that in an array you can thus step right from the last byte of a previous component to the first byte of the next one. This is not only machinebut compiler-dependent. 8. The assumption that memory address space is globally flat and that the array reference foo[-1] is necessarily valid. Problem: this fails at 0, or other places on segment-addressed machines like Intel chips (yes, segmentation is universally considered a [14099]brain-damaged way to design machines (see [14100]moby), but that is a separate issue). 9. The assumption that objects can be arbitrarily large with no special considerations. Problem: this fails on segmented architectures and under non-virtual-addressing environments. 10. The assumption that the stack can be as large as memory. Problem: this fails on segmented architectures or almost anything else without virtual addressing and a paged stack. 11. The assumption that bits and addressable units within an object are ordered in the same way and that this order is a constant of nature. Problem: this fails on [14101]big-endian machines. 12. The assumption that it is meaningful to compare pointers to different objects not located within the same array, or to objects of different types. Problem: the former fails on segmented architectures, the latter on

1130

[after the insect-eating plant] See [14127]firewall machine.

---

Node:verbage, Next:[14128]verbiage, Previous:[14129]Venus flytrap, Up:[14130]= V =

verbage /ver'b*j/ n.

A deliberate misspelling and mispronunciation of [14131]verbiage that assimilates it to the word `garbage'. Compare [14132]content-free. More pejorative than `verbiage'.

---

Node:verbiage, Next:[14133]Version 7, Previous:[14134]verbage,

Up:[14135]= V =

verbiage n.

When the context involves a software or hardware system, this refers to [14136]documentation. This term borrows the connotations of mainstream `verbiage' to suggest that the documentation is of marginal utility and that the motives behind its production have little to do with the ostensible subject.

---

Node:Version 7, Next:[14137]vgrep, Previous:[14138]verbiage,

Up:[14139]= V =

Version 7 alt. V7 /vee' se'vn/ n.

The first widely distributed version of [14140]Unix, released unsupported by Bell Labs in 1978. The term is used adjectivally to describe Unix features and programs that date from that release, and are thus guaranteed