The Jargon File by Eric S. Raymond (ebook reader android txt) π
The AI Lab culture had been hit hard in the late 1970s by funding cuts and the resulting administrative decision to use vendor-supported hardware and software instead of homebrew whenever possible. At MIT, most AI work had turned to dedicated LISP Machines. At the same time, the commercialization of AI technology lured some of the AI Lab's best and brightest away to startups along the Route 128 strip in Massachusetts and out West in Silicon Valley. The startups built LISP machines for MIT; the central MIT-AI computer became a [45]TWENEX system rather than a host for the AI hackers' beloved [46]ITS.
The Stanford AI Lab had effectively ceased to exist by 1980, although the SAIL computer continued as a Computer Science Department resource until 1991. Stanford became a major [47]TWENEX site, at one point operating more than a dozen TOPS-20 systems; but by the mid-1980s most of the interesting software work was being
Read free book Β«The Jargon File by Eric S. Raymond (ebook reader android txt) πΒ» - read online or download for free at americanlibrarybooks.com
- Author: Eric S. Raymond
- Performer: -
Read book online Β«The Jargon File by Eric S. Raymond (ebook reader android txt) πΒ». Author - Eric S. Raymond
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
=
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.
[from Virtual Address eXtension] The most successful minicomputerdesign 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.
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 byvixen'] (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.
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:
The assumption that dereferencing a null pointer is safe becauseit 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.
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 casts or 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 inmemory, on a stack, 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 byteaddress 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 [14098]HLL execution speed, and
can cause an illegal address fault or bus error.
The (related) assumption that there is no padding at the end oftypes 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 thatthe 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).
The assumption that objects can be arbitrarily large with nospecial 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 objectare ordered in the same way and that this order is a constant of
nature. Problem: this fails on [14101]big-endian machines.
The assumption that it is meaningful to compare pointers todifferent 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 that sizeof(int) == sizeof(long). Problem: this
fails on PDP-11s, 286-based systems and even on 386 and 68000
systems under some compilers (and on 64-bit systems like the
Alpha, of course).
The assumption that argv[] is writable. Problem: this fails inmany 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.
Node:vdiff, Next:[14102]veeblefester, Previous:[14103]vaxocentrism,
Up:[14104]= V =
vdiff /vee'dif/ v.,n.
Visual diff. The operation of finding differences between two files by
[14105]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 [14106]diff.
Node:veeblefester, Next:[14107]velveeta, Previous:[14108]vdiff,
Up:[14109]= V =
veeblefester /vee'b*l-fes`tr/ n.
[from the "Born Loser" comix via Commodore; prob. originally from
"Mad" Magazine's `Veeblefetzer' parodies beginning in #15, 1954] Any
obnoxious person engaged in the (alleged) professions of marketing or
management. Antonym of [14110]hacker. Compare [14111]suit,
[14112]marketroid.
Node:velveeta, Next:[14113]ventilator card,
Previous:[14114]veeblefester, Up:[14115]= V =
velveeta n.
[Usenet: by analogy with [14116]spam. The trade name Velveeta is
attached in the U.S. to a particularly nasty processed-cheese spread.]
Also knows as [14117]ECP; a message that is excessively cross-posted,
as opposed to [14118]spam which is too frequently posted. This term is
widely recognized but not commonly used; most people refer to both
kinds of abuse as spam. Compare [14119]jello.
Node:ventilator card, Next:[14120]Venus flytrap,
Previous:[14121]velveeta, Up:[14122]= V =
ventilator card n.
Syn. [14123]lace card.
Node:Venus flytrap, Next:[14124]verbage, Previous:[14125]ventilator
card, Up:[14126]= V =
Venus flytrap n.
[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 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 [14141]Unix"; research [14142]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
[14143]BSD, [14144]USG Unix, [14145]Unix. Some old-timers impatient
with commercialization and kernel bloat still maintain that V7 was the
Last True Unix.
Node:vgrep, Next:[14146]vi, Previous:[14147]Version 7, Up:[14148]= V =
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
[14149]grep; compare [14150]vdiff.
Node:vi, Next:[14151]video toaster, Previous:[14152]vgrep, Up:[14153]=
V =
vi /V-I/, not /vi:/ and never /siks/ n.
[from `Visual Interface'] A screen editor crufted together by Bill Joy
for an early [14154]BSD release. Became the de facto standard Unix
editor and a nearly undisputed hacker favorite outside of MIT until
the rise of [14155]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 on older versions provides
no indication of which mode the editor is in (years ago, a
correspondent reported that he has often heard the editor's name
pronounced /vi:l/; there is now a vi clone named `vile'). Nevertheless
vi (and variants such as vim and elvis) 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
Comments (0)