The Hackers'''' Dictionary legal torrents phần 10 doc

: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 means `default', 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. 2. 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 by `vixen'] 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: /vak`soh-sen'trizm/ [analogy with `ethnocentrism'] 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:

Information prepared by the Project Gutenberg legal advisor 241

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 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 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, 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 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.

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 machine- but

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 {brain-damaged} way to design machines (see {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 {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

word-oriented machines or others with multiple pointer formats.

13. The assumption that an `int' is 32 bits, or (nearly equivalently) the assumption that `sizeof(int) ==

sizeof(long)'. Problem: this fails on PDP-11s, 286-based systems and even on 386 and 68000 systems under

some compilers.

14. The assumption that `argv[]' is writable. Problem: this fails in many embedded-systems C environments

and even under a few flavors of UNIX.

Information prepared by the Project Gutenberg legal advisor 242

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 for detecting omissions in the `rear' file, it can also be used with

printouts of graphics, a claim few if any diff programs can make. See {diff}.

:veeblefester: /vee'b*l-fes`tr/ [from the "Born Loser" comix via Commodore; prob. originally from `Mad'

Magazine's `Veeblefeetzer' parodies ca. 1960] n. Any obnoxious person engaged in the (alleged) professions

of marketing or management. Antonym of {hacker}. Compare {suit}, {marketroid}.

:Venus flytrap: [after the insect-eating plant] n. See {firewall machine}.

:verbage: /ver'b*j/ n. A deliberate misspelling and mispronunciation of {verbiage} that assimilates it to the

word `garbage'. Compare {content-free}. More pejorative than `verbiage'.

:verbiage: n. When the context involves a software or hardware system, this refers to {{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.

:Version 7: alt. V7 /vee' se'vn/ n. The 1978 unsupported release of {{UNIX}} ancestral to all current

commercial versions. Before the release of the POSIX/SVID standards, V7's features were often treated as a

UNIX portability baseline. See {BSD}, {USG UNIX}, {{UNIX}}. Some old-timers impatient with

commercialization and kernel bloat still maintain that V7 was the Last True UNIX.

:vgrep: /vee'grep/ v.,n. Visual grep. The operation of finding patterns in a file optically rather than digitally

(also called an `optical grep'). See {grep}; compare {vdiff}.

:vi: /V-I/, *not* /vi:/ and *never* /siks/ [from `Visual Interface'] n. A screen editor crufted together by Bill

Joy for an early {BSD} release. Became the de facto standard UNIX editor and a nearly undisputed hacker

favorite outside of MIT until the rise of {EMACS} after about 1984. Tends to frustrate new users no end, as it

will neither take commands while expecting input text nor vice versa, and the default setup provides no

indication of which mode one is in (one correspondent accordingly reports that he has often heard the editor's

name pronounced /vi:l/). Nevertheless it is still widely used (about half the respondents in a 1991 USENET

poll preferred it), and even EMACS fans often resort to it as a mail editor and for small editing jobs (mainly

because it starts up faster than the bulkier versions of EMACS). See {holy wars}.

:videotex: n. obs. An electronic service offering people the privilege of paying to read the weather on their

television screens instead of having somebody read it to them for free while they brush their teeth. The idea

bombed everywhere it wasn't government-subsidized, because by the time videotex was practical the installed

base of personal computers could hook up to timesharing services and do the things for which videotex might

have been worthwhile better and cheaper. Videotex planners badly overestimated both the appeal of getting

information from a computer and the cost of local intelligence at the user's end. Like the {gorilla arm} effect,

this has been a cautionary tale to hackers ever since. See also {vannevar}.

:virgin: adj. Unused; pristine; in a known initial state. "Let's bring up a virgin system and see if it crashes

again." (Esp. useful after contracting a {virus} through {SEX}.) Also, by extension, buffers and the like

within a program that have not yet been used.

Information prepared by the Project Gutenberg legal advisor 243