The Hacker's Dictionary by - (sneezy the snowman read aloud txt) 📕

the 4.4BSD release on the horizon, complete free source code for UNIX-clone toolsets and kernels should soon be widely available.

:UUCPNET: n. The store-and-forward network consisting of all the world's connected UNIX machines (and others running some clone of the UUCP (UNIX-to-UNIX CoPy) software). Any machine reachable only via a {bang path} is on UUCPNET. See {network address}.

= V =

=====

:vadding: /vad'ing/ [from VAD, a permutation of ADV (i.e., {ADVENT}), used to avoid a particular {admin}'s continual search-and-destroy sweeps for the game] n. 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 isto vad' (compare {phreaking}; see also {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.

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 {hobbit} (sense 2).

:vanilla: [from the default flavor of ice cream in the U.S.] adj.

Ordinary {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 {canonical} in that the latter meansdefault', whereas vanilla simply means `ordinary'.

For example, when hackers go on a {great-wall}, hot-and-sour wonton soup is the {canonical} wonton soup to get (because that is what most of them usually order) even though it isn't the vanilla wonton soup.

: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, made at a time when the semiconductor effect had already been demonstrated. Other famous vannevars have included magnetic-bubble memory, LISP machines, {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.

:vaporware: /vay'pr-weir/ n. Products announced far in advance of any release (which may or may not actually take place).

:var: /veir/ or /var/ n. Short for `variable'. Compare {arg}, {param}.

: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 {killer micro}s 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 {BSD}). Esp.

noted for its large, assembler-programmer-friendly instruction set --- an asset that became a liability after the RISC revolution.

A major brand of vacuum cleaner in Britain. Cited here because its alleged sales pitch, "Nothing sucks like a VAX!" became a sort of battle-cry of RISC partisans. It is sometimes claimed that this slogan was not actually used by the Vax vacuum-cleaner people, but was actually that of a rival brand called Electrolux (as in "Nothing sucks like..."); your editors have not yet been able to verify either version of the legend. It is also 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.

:VAXectomy: /vak-sek't*-mee/ [by analogy with `vasectomy'] n. A VAX removal. 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.

:VAXen: /vak'sn/ [from oxen', perhaps influenced byvixen'] n.

(alt. `vaxen') The plural canonically used among hackers for the DEC VAX computers. "Our installation has four PDP-10s and twenty vaxen." See {boxen}.

:vaxherd: n. /vaks'herd/ [from `oxherd'] A VAX operator.

:vaxism: /vak'sizm/ n. A piece of code that exhibits {vaxocentrism} in critical areas. Compare {PC-ism}, {unixism}.

:vaxocentrism: /vaksoh-sen'trizm/ [analogy withethnocentrism'] n. A notional disease said to afflict C programmers who persist in coding according to certain assumptions that are valid (esp. under UNIX) on {VAXen} but false elsewhere. Among these are:

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 are signed.

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 types correct in calls. Problem: this fails on word-oriented machines or others with multiple pointer formats.

The assumption that the parameters of a routine are stored in memory, contiguously, and in strictly ascending or descending order. Problem: this fails on many RISC architectures.

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.

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 word- or greater-sized object at an odd char address). Problem: this fails on many (esp. RISC) architectures better optimized for {HLL} execution speed, and can cause an illegal address fault or bus error.

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 machine- but compiler-dependent.

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 {brain-damaged} way to design machines (see {moby}), but that is a separate issue).

The assumption that objects can be arbitrarily large with no special considerations. Problem: this fails on segmented architectures and under non-virtual-addressing environments.

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.

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 {big-endian} machines.

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 word-oriented machines or others with multiple pointer formats.

The assumption that an int' is 32 bits, or (nearly equivalently) the assumption thatsizeof(int) == sizeof(long)'. Problem: this fails on PDP-11s, 286-based systems and even on 386 and 68000

systems under some compilers.

The assumption that `argv[]' is writable. Problem: this fails in many embedded-systems C environments and even under a few flavors of UNIX.

Note that a programmer can validly be accused of vaxocentrism even if he or she has never seen a VAX. Some of these assumptions (esp. 2--5) were valid on the PDP-11, the original C machine, and became endemic years before the VAX. The terms `vaxocentricity'

and `all-the-world's-a-VAX syndrome' have been used synonymously.

:vdiff: /vee'dif/ v.,n. Visual diff. The operation of finding differences between two files by {eyeball search}. The term optical diff' has also been reported, and is sometimes more specifically used for the act of superimposing two nearly identical printouts on one another and holding them up to a light to spot differences. Though this method is poor