Chapter 45

:unixism: /n./ A piece of code or a coding technique that depends on the protected multi-tasking environment with relatively low process-spawn overhead that exists on virtual-memory Unix systems. Common {unixism}s include: gratuitous use of `fork(2)'; the assumption that certain undocumented but well-known features of Unix libraries such as `stdio(3)' are supported elsewhere; reliance on {obscure} side-effects of system calls (use of `sleep(2)' with a 0 argument to clue the scheduler that you're willing to give up your time-slice, for example); the assumption that freshly allocated memory is zeroed; and the assumption that fragmentation problems won't arise from never `free()'ing memory. Compare {vaxocentrism}; see also {New Jersey}.

:unswizzle: /v./ See {swizzle}.

:unwind the stack: /vi./ 1. [techspeak] During the execution of a procedural language, one is said to `unwind the stack' from a called procedure up to a caller when one discards the stack frame and any number of frames above it, popping back up to the level of the given caller. In C this is done with `longjmp'/`setjmp', in LISP with `throw/catch'. See also {smash the stack}. 2. People can unwind the stack as well, by quickly dealing with a bunch of problems: "Oh heck, let's do lunch. Just a second while I unwind my stack."

:unwind-protect: /n./ [MIT: from the name of a LISP operator] A task you must remember to perform before you leave a place or finish a project. "I have an unwind-protect to call my advisor."

:up: /adj./ 1. Working, in order. "The down escalator is up." Oppose {down}. 2. `bring up': /vt./ To create a working version and start it. "They brought up a down system." 3. `come up' /vi./ To become ready for production use.

:upload: /uhp'lohd/ /v./ 1. [techspeak] To transfer programs or data over a digital communications link from a smaller or peripheral `client' system to a larger or central `host' one. A transfer in the other direction is, of course, called a {download} (but see the note about ground-to-space comm under that entry). 2. [speculatively] To move the essential patterns and algorithms that make up one's mind from one's brain into a computer. Those who are convinced that such patterns and algorithms capture the complete essence of the self view this prospect with pleasant anticipation.

:upthread: /adv./ Earlier in the discussion (see {thread}), i.e., `above'. "As Joe pointed out upthread, ..." See also {followup}.

:urchin: /n./ See {munchkin}.

:URL: /U-R-L/ or /erl/ /n./ Uniform Resource Locator, an address widget that identifies a document or resource on the World Wide Web. This entry is here primarily to record the fact that the term is commonly pronounced both /erl/, and /U-R-L/ (the latter predominates in more formal contexts).

:Usenet: /yoos'net/ or /yooz'net/ /n./ [from `Users' Network'; the original spelling was USENET, but the mixed-case form is now widely preferred] A distributed {bboard} (bulletin board) system supported mainly by Unix machines. Originally implemented in 1979--1980 by Steve Bellovin, Jim Ellis, Tom Truscott, and Steve Daniel at Duke University, it has swiftly grown to become international in scope and is now probably the largest decentralized information utility in existence. As of early 1996, it hosts over 10,000 {newsgroup}s and an average of over 500 megabytes (the equivalent of several thousand paper pages) of new technical articles, news, discussion, chatter, and {flamage} every day.

By the year the Internet hit the mainstream (1994) the original UUCP transport for Usenet was fading out of use (see {UUCPNET}) -- almost all Usenet connections were over Internet links. A lot of newbies and journalists began to refer to "Internet newsgroups" as though Usenet was and always had been just another Internet service. This ignorance greatly annoys experienced Usenetters.

:user: /n./ 1. Someone doing `real work' with the computer, using it as a means rather than an end. Someone who pays to use a computer. See {real user}. 2. A programmer who will believe anything you tell him. One who asks silly questions. [GLS observes: This is slightly unfair. It is true that users ask questions (of necessity). Sometimes they are thoughtful or deep. Very often they are annoying or downright stupid, apparently because the user failed to think for two seconds or look in the documentation before bothering the maintainer.] See {luser}. 3. Someone who uses a program from the outside, however skillfully, without getting into the internals of the program. One who reports bugs instead of just going ahead and fixing them.

The general theory behind this term is that there are two classes of people who work with a program: there are implementors (hackers) and {luser}s. The users are looked down on by hackers to some extent because they don't understand the full ramifications of the system in all its glory. (The few users who do are known as `real winners'.) The term is a relative one: a skilled hacker may be a user with respect to some program he himself does not hack. A LISP hacker might be one who maintains LISP or one who uses LISP (but with the skill of a hacker). A LISP user is one who uses LISP, whether skillfully or not. Thus there is some overlap between the two terms; the subtle distinctions must be resolved by context.

:user-friendly: /adj./ Programmer-hostile. Generally used by hackers in a critical tone, to describe systems that hold the user's hand so obsessively that they make it painful for the more experienced and knowledgeable to get any work done. See {menuitis}, {drool-proof paper}, {Macintrash}, {user-obsequious}.

:user-obsequious: /adj./ Emphatic form of {user-friendly}. Connotes a system so verbose, inflexible, and determinedly simple-minded that it is nearly unusable. "Design a system any fool can use and only a fool will want to use it." See {WIMP environment}, {Macintrash}.

:USG Unix: /U-S-G yoo'niks/ /n./ Refers to AT&T Unix commercial versions after {Version 7}, especially System III and System V releases 1, 2, and 3. So called because during most of the lifespan of those versions AT&T's support crew was called the `Unix Support Group'. See {BSD}, {{Unix}}.

:UTSL: // /n./ [Unix] On-line acronym for `Use the Source, Luke' (a pun on Obi-Wan Kenobi's "Use the Force, Luke!" in "Star Wars") -- analogous to {RTFS} (sense 1), but more polite. This is a common way of suggesting that someone would be better off reading the source code that supports whatever feature is causing confusion, rather than making yet another futile pass through the manuals, or broadcasting questions on Usenet that haven't attracted {wizard}s to answer them.

Once upon a time in {elder days}, everyone running Unix had source. After 1978, AT&T's policy tightened up, so this objurgation was in theory appropriately directed only at associates of some outfit with a Unix source license. In practice, bootlegs of Unix source code (made precisely for reference purposes) were so ubiquitous that one could utter it at almost anyone on the network without concern.

Nowadays, free Unix clones have become widely enough distributed that anyone can read source legally. The most widely distributed is certainly Linux, with variants of the NET/2 and 4.4BSD distributions running second. Cheap commercial Unixes with source such as BSD/OS are accelerating this trend.

:UUCPNET: /n. obs./ 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. This term has been rendered obsolescent by the spread of cheap Internet connections in the 1990s; the few remaining UUCP links are essentially slow channels to the Internet rather than an autonomous network. See {network address}.

= V = =====

:V7: /V'sev'en/ /n./ See {Version 7}.

:vadding: /vad'ing/ /n./ [from VAD, a permutation of ADV (i.e., {ADVENT}), used to avoid a particular {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 {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: /adj./ [from the default flavor of ice cream in the U.S.] 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 soup is the {canonical} 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, a prediction 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). See also {brochureware}.

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

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.

:VAXectomy: /vak-sek't*-mee/ /n./ [by analogy with `vasectomy'] 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/ /n./ [from `oxen', perhaps influenced by `vixen'] (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: /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'.

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

: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 {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 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 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.

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/ /n./ [from the "Born Loser" comix via Commodore; prob. originally from "Mad" Magazine's `Veeblefeetzer' parodies ca. 1960] Any obnoxious person engaged in the (alleged) professions of marketing or management. Antonym of {hacker}. Compare {suit}, {marketroid}.

:ventilator card: /n./ Syn. {lace card}.

:Venus flytrap: /n./ [after the insect-eating plant] 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 first widely distributed version of {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 to be present and portable in all Unix versions (this was the standard gauge of portability before the POSIX and IEEE 1003 standards). Note that this usage does *not* derive from the release being the "seventh version of {Unix}"; research {Unix} at Bell Labs has traditionally been numbered according to the edition of the associated documentation. Indeed, only the widely-distributed Sixth and Seventh Editions are widely known as V[67]; the OS that might today be known as `V10' is instead known in full as "Tenth Edition Research Unix" or just "Tenth Edition" for short. For this reason, "V7" is often read by cognoscenti as "Seventh Edition". 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/ /n./ [from `Visual Interface'] 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 the editor 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.

:virtual: /adj./ [via the technical term `virtual memory', prob. from the term `virtual image' in optics] 1. Common alternative to {logical}; often used to refer to the artificial objects (like addressable virtual memory larger than physical memory) simulated by a computer system as a convenient way to manage access to shared resources. 2. Simulated; performing the functions of something that isn't really there. An imaginative child's doll may be a virtual playmate. Oppose {real}.