eric@snark.thyrsus.com (Eric S. Raymond) (11/29/90)
= P =
PAGE IN [MIT] v. To become aware of one's surroundings again after
having paged out (see PAGE OUT). Usually confined to the sarcastic
comment, ``So-and-so pages in. Film at 11.'' See FILM AT 11.
PAGE OUT [MIT] v. To become unaware of one's surroundings temporarily,
due to daydreaming or preoccupation. ``Can you repeat that? I
paged out for a minute.'' See PAGE IN.
PANIC [UNIX] v. An action taken by a process or the entire operating
system when an unrecoverable error is discovered. The action
usually consists of: (1) displaying localized information on the
controlling terminal, (2) saving, or preparing for saving, a memory
image of the process or operating system, and (3) terminating the
process or rebooting the system.
PARAM (p@-ram') n. Speeech-only shorthand for ``parameter''. Compare
ARG, VAR. The plural `params' is often further compressed to
`parms'.
PARITY ERRORS pl.n. Those little lapses of attention or (in more
severe cases) consciousness, usually brought on by having spent all
night and most of the next day hacking. ``I need to go home and
crash; I'm starting to get a lot of parity errors.''
PARSE [from linguistic terminology] v. 1. To determine the syntactic
structure of a sentence or other utterance (close to the standard
English meaning). Example: ``That was the one I saw you.'' ``I
can't parse that.'' 2. More generally, to understand or
comprehend. ``It's very simple; you just kretch the glims and then
aos the zotz.'' ``I can't parse that.'' 3. Of fish, to have to
remove the bones yourself (usually at a Chinese restaurant). ``I
object to parsing fish'' means ``I don't want to get a whole fish,
but a sliced one is okay.'' A ``parsed fish'' has been deboned.
There is some controversy over whether ``unparsed'' should mean
``bony'', or also mean ``deboned''.
PATCH 1. n. A temporary addition to a piece of code, usually as a
quick-and-dirty remedy to an existing bug or misfeature. A patch
may or may not work, and may or may not eventually be incorporated
permanently into the program. 2. v. To insert a patch into a piece
of code. 3. [in the UNIX world] n. a set of differences between two
versions of source code, generated with diff(1) and intended to be
mechanically applied using patch(1); often used as a way of
distributing permanent C code upgrades and fixes over USENET.
PD (pee-dee) adj. Common abbreviation for ``public domain'', applied
to software distributed over USENET and from Internet archive
sites. Much of this software is not in fact ``public domain'' in
the legal sense but travels under various copyrights granting
reproduction and use rights to anyone who can SNARF a copy. See
COPYLEFT.
PDL (pid'l or pud'l) [acronym for Push Down List] n. 1. A LIFO queue
(stack); more loosely, any priority queue; even more loosely, any
queue. A person's pdl is the set of things he has to do in the
future. One speaks of the next project to be attacked as having
risen to the top of the pdl. ``I'm afraid I've got real work to
do, so this'll have to be pushed way down on my pdl.'' All these
usages are also frequently found with STACK (q.v) itself as the
subject noun. See PUSH and POP. 2. Dave Lebling (PDL@DM).
PDP-10 [Programmable Digital Processor model 10] n. The machine that
made timesharing real. Looms large in hacker folklore due to early
adoption in the mid-70s by many university computing facilities and
research labs including the MIT AI lab, Stanford and CMU. Some
aspects of the instruction set (most notably the bit-field
instructions) are still considered unsurpassed. The '10 was
eventually eclipsed by the PDP-11 and VAX machines and dropped from
DEC's line in the early '80s, and in 1990 to have cut one's teeth
on one is considered something of a badge of honorable
old-timerhood among hackers. See TOPS-10, ITS, Appendix B.
PERCENT-S (per-sent' es) [From ``%s'', the formatting sequence in C's
printf() library function used to indicate that an arbitrary string
may be inserted] n. An unspecified person or object. ``I was just
talking to some percent-s in administration.'' Compare RANDOM.
PERF (perf) n. See CHAD (sense #1).
PESSIMAL (pes'i-ml) [Latin-based antonym for ``optimal''] adj.
Maximally bad. ``This is a pessimal situation.''
PESSIMIZING COMPILER (pes'i-miez-ing kuhm-pie'lr) [antonym of
`optimizing compiler'] n. A compiler that produces object code that
is worse than the straightforward or obvious translation.
PHASE 1. n. The phase of one's waking-sleeping schedule with respect
to the standard 24-hour cycle. This is a useful concept among
people who often work at night according to no fixed schedule. It
is not uncommon to change one's phase by as much as six hours/day
on a regular basis. ``What's your phase?'' ``I've been getting in
about 8 PM lately, but I'm going to work around to the day schedule
by Friday.'' A person who is roughly 12 hours out of phase is
sometimes said to be in ``night mode''. (The term ``day mode'' is
also used, but less frequently.) 2. CHANGE PHASE THE HARD WAY: To
stay awake for a very long time in order to get into a different
phase. 3. CHANGE PHASE THE EASY WAY: To stay asleep etc.
PHASE OF THE MOON n. Used humorously as a random parameter on which
something is said to depend. Sometimes implies unreliability of
whatever is dependent, or that reliability seems to be dependent on
conditions nobody has been able to determine. ``This feature
depends on having the channel open in mumble mode, having the foo
switch set, and on the phase of the moon.''
PIG, RUN LIKE A adj. To run very slowly on given hardware, said of
software. Distinct from HOG, q.v.
PING (ping) [from TCP/IP terminology] n.,v. 1. Slang term for a small
network message (ICMP ECHO) sent by a computer to check for the
presence and aliveness of another. Occasionally used as a phone
greeting. See ACK. 2. To verify the presence of. 3. To get the
attention of. From the Unix command by the same name (an acronym
of ``Packet INternet Groper) that sends an ICMP ECHO packet to
another host. This was probably contrived to match WWII-era
``ping'' (sonar ranging pulse).
PINK SHIRT BOOK ``The Peter Norton Programmer's Guide to the IBM PC''.
The original cover featured a picture of Peter Norton with a silly
smirk on his face, wearing a pink shirt. Perhaps in recognition of
this usage, the current edition has a different picture of Norton
wearing a pink shirt.
PIPELINE [UNIX, orig. by Doug McIlroy; now also used under MS-DOS and
elsewhere] n. A chain of FILTER programs connected
``head-to-tail'', so that the output of one becomes the input of
the next. Under UNIX, user utilities can often be implemented or
at least prototyped by a suitable collection of pipelines and
temp-file grinding encapsulated in a shell script; this is much
less effort than writing C every time, and the capability is
considered one of UNIX's major WINNING features.
PIZZA, ANSI STANDARD (pee'tz@, an'see stan'd@rd) [CMU] Pepperoni and
mushroom pizza. Coined allegedly because most pizzas ordered by
CMU hackers during some period leading up to mid-1990 were of that
flavor. [Myself, I have observed a high frequency of pepperoni,
mushroom and sausage. -- ESR] See also ROTARY DEBUGGER.
PLAYPEN [IBM] n. A room where programmers work. Compare SALT MINES.
PLUGH (ploogh) [from the ADVENT game] v. See XYZZY.
PM (pee em) 1. [from ``preventive maintenence''] v. to bring down a
machine for inspection or test purposes. 2. n. Abbrev. for
``Presentation Manager'', an ELEPHANTINE OS/2 GUI.
P.O.D. (pee-oh-dee) Acronym for `Piece Of Data' (as opposed to a code
section). Usage: pedantic and rare.
POINTER ARITHMETIC [C programmers] n. The use of increment and
decrement operations on address pointers to traverse arrays or
structure fields. See also BUMP.
POLL v.,n. 1. The action of checking the status of an input line,
sensor, or memory location to see if a particular external event
has been registered. 2. To ask. ``I'll poll everyone and see where
they want to go for lunch.''
POLYGON PUSHER n. A chip designer who spends most of his/her time at
the physical layout level (which requires drawing *lots* of
multi-colored polygons).
POM (pee-oh-em) n. Phase of the moon (q.v.). Usage: usually used in
the phrase ``POM dependent'' which means FLAKEY (q.v.).
POP also POPJ (pop-jay) [based on the stack operation that removes the
top of a stack, and the fact that procedure return addresses are
saved on the stack] v. To return from a digression (the J-form
derives from a PDP-10 assembler instruction). By verb doubling,
``Popj, popj'' means roughly, ``Now let's see, where were we?''
See RTI.
PRECEDENCE LOSSAGE (pre's@-dens los'j) [C programmers] n. Coding error
in an expression due to unexpected grouping of arithmetic or
logical operators by the compiler. Used esp. of certain common
coding errors in C due to the nonintuitively low precedence levels
of &, | and ^. Can always be avoided by suitable use of
parentheses. See ALIASING BUG, MEMORY LEAK, SMASH THE STACK,
FANDANGO ON CORE, OVERRUN SCREW.
PRETTY PRINT or PRETTYPRINT v. 1. To generate `pretty' human-readable
output from a hairy internal representation; esp. used for the
process of GRINDing (sense #2) LISP code. 2. To format in some
particularly slick and nontrivial way.
PRIME TIME [from TV programming] n. Normal high-usage hours on a
timesharing system, the `day shift'. Avoidance of prime time is a
major reason for NIGHT MODE hacking.
PRIORITY INTERRUPT [from the hardware term] n. Describes any stimulus
compelling enough to yank one right out of HACK MODE. Classically
used to describe being dragged away by an SO for immediate sex, but
may also refer to more mundane interruptions such as a fire alarm
going off in the near vicinity.
PROPELLER HEAD n. Used by hackers, this is syn. with COMPUTER GEEK.
Non-hackers sometimes use it to describe all techies.
PROTOCOL n. See DO PROTOCOL.
PROWLER [UNIX] n. A DEMON that is run periodically (typically once a
week) to seek out and erase core files, truncate administrative
logfiles, nuke lost+found directories, and otherwise clean up the
cruft that tends to pile up in the corners of a file system. See
also GFR.
PSEUDOPRIME n. A backgammon prime (six consecutive occupied points)
with one point missing.
PUNT [from the punch line of an old joke: ``Drop back 15 yards and
punt''] v. To give up, typically without any intention of retrying.
PURPLE BOOK, THE n. The System V Interface Definition. The covers of
the first editions were an amazingly nauseating shade of
off-lavender. See WHITE BOOK, SILVER BOOK, ORANGE BOOK, GREEN BOOK.
PUSH [based on the stack operation that puts the current information
on a stack, and the fact that procedure call addresses are saved on
the stack] dialect: PUSHJ (push-jay), based on the PDP-10 procedure
call instruction. v. To enter upon a digression, to save the
current discussion for later.
= Q =
QUANTUM BOGODYNAMICS (kwahn'tm boh`goh-die-nam'iks) n. Theory
promulgated by ESR which characterizes the universe in terms of
bogon sources (such as politicians, used-car salesmen, TV
evangelists, and SUITs in general), bogon sinks (such as taxpayers
and computers), and bogosity potential fields. Bogon absorption,
of course, causes human beings to behave mindlessly and machines to
fail (and may cause them to emit secondary bogons as well);
however, the precise mechanics of the bogon-computron interaction
are not yet understood and remain to be elucidated. Quantum
bogodynamics is most frequently invoked to explain the sharp
increase in hardware and software failures in the presence of
suits; the latter emit bogons which the former absorb. See BOGON,
COMPUTRON, SUIT.
QUES (kwess) 1. n. The question mark character (``?''). 2. interj.
What? Also QUES QUES? See WALL.
QUX (kwuhx) The fourth of the standard metasyntactic variables, after
BAZ and before the QUU*X series. See FOO, BAR, BAZ, QUUX.
QUUX (kwooks) [invented by Steele] Mythically, from the Latin
semi-deponent verb QUUXO, QUUXARE, QUUXANDUM IRI; noun form
variously QUUX (plural QUUCES, Anglicized to QUUXES) and QUUXU
(genitive plural is QUUXUUM, four U's in seven letters).] 1.
Originally, a meta-word like FOO and FOOBAR. Invented by Guy
Steele for precisely this purpose when he was young and naive and
not yet interacting with the real computing community. Many people
invent such words; this one seems simply to have been lucky enough
to have spread a little. 2. interj. See FOO; however, denotes very
little disgust, and is uttered mostly for the sake of the sound of
it. 3. n. Refers to one of three people who went to Boston Latin
School and eventually to MIT:
THE GREAT QUUX: Guy L. Steele Jr.
THE LESSER QUUX: David J. Littleboy
THE MEDIOCRE QUUX: Alan P. Swide
(This taxonomy is said to be similarly applied to three Frankston
brothers at MIT.) QUUX, without qualification, usually refers to
The Great Quux, who is somewhat infamous for light verse and for
the ``Crunchly'' cartoons. 4. QUUXY: adj. Of or pertaining to a
QUUX. 5. n. The Micro Quux (Sam Lewis).
= R =
RANDOM adj. 1. Unpredictable (closest to mathematical definition);
weird. ``The system's been behaving pretty randomly.'' 2.
Assorted; undistinguished. ``Who was at the conference?'' ``Just
a bunch of random business types.'' 3. Frivolous; unproductive;
undirected (pejorative). ``He's just a random loser.'' 4.
Incoherent or inelegant; not well organized. ``The program has a
random set of misfeatures.'' ``That's a random name for that
function.'' ``Well, all the names were chosen pretty randomly.''
5. Gratuitously wrong, i.e., poorly done and for no good apparent
reason. For example, a program that handles file name defaulting
in a particularly useless way, or an assembler routine that could
easily have been coded using only three ac's, but randomly uses
seven for assorted non-overlapping purposes, so that no one else
can invoke it without first saving four extra registers's. 6. In
no particular order, though deterministic. ``The I/O channels are
in a pool, and when a file is opened one is chosen randomly.'' n.
7. A random hacker; used particularly of high school students who
soak up computer time and generally get in the way. 8. (occasional
MIT usage) One who lives at Random Hall. J. RANDOM is often
prefixed to a noun to make a ``name'' out of it (by comparison to
common names such as ``J. Fred Muggs''). The most common uses are
``J. RANDOM HACKER, ``J. Random Loser'' and ``J. Random Nerd''
("Should J. Random Loser be allowed to gun down other people?"),
but it can be used just as an elaborate version of RANDOM in any
sense. See also SOME RANDOM X.
RANDOM NUMBERS n. When one wishes to specify a large but random number
of things, and the context is inappropriate for `N' (q.v.), certain
numbers are preferred by hacker tradition (that is, easily
recognized as placeholders). These include
17 Long described at MIT as ``the least random number'', see 23.
23 Sacred number of Eris, Goddess of Discord (along with 17 & 5).
42 The Answer to the Question of Life, the Universe and Everything.
69 From the sexual act. This one was favored in MIT's ITS culture.
666 The Number of the Beast.
For further enlightenment, consult the _Principia_Discordia_,
_The_Hitchhiker's_Guide_To_The_Galaxy_, any porn movie, and the
Christian Bible's _Book_Of_Revelations_. See also DISCORDIANISM.
RANDOMNESS n. An unexplainable misfeature; gratuitous inelegance.
Also, a HACK or CROCK which depends on a complex combination of
coincidences (or rather, the combination upon which the crock
depends). ``This hack can output characters 40-57 by putting the
character in the accumulator field of an XCT and then extracting 6
bits -- the low two bits of the XCT opcode are the right thing.''
``What randomness!''
RAPE v. To (metaphorically) screw someone or something, violently.
Usage: often used in describing file-system damage. ``So-and-so
was running a program that did absolute disk I/O and ended up
raping the master directory.''
RARE [UNIX] adj. CBREAK mode (character-by-character with interrupts
enabled). Distinguished from `raw' and `cooked', but unlike them
this term is strictly a creature of folklore, not found in the
manuals. Usage: rare.
RASTER BURN n. Eyestrain brought on by too many hours of looking at
low-res, poorly tuned or glare-ridden monitors, esp. graphics
monitors. See TERMINAL ILLNESS.
RAVE [WPI] v. 1. To persist in discussing a specific subject. 2. To
speak authoritatively on a subject about which one knows very
little. 3. To complain to a person who is not in a position to
correct the difficulty. 4. To purposely annoy another person
verbally. 5. To evangelize. See FLAME. Also used to describe a
less negative form of blather, such as friendly bullshitting.
RAVE ON! imp. Sarcastic invitation to continue a RAVE, often by
someone who wishes the raver would get a clue but realizes this is
unlikely.
READ-ONLY USER n. Describes a LUSER who uses computers almost
exclusively for reading USENET, bulletin boards and email, as
opposed to writing code or purveying useful information. See TWINK.
REAL SOON NOW [orig. from SF's fanzine community. popularized by Jerry
Pournelle's BYTE column] adj. 1. Supposed to be available (or
fixed, or cheap, or whatever) real soon now according to somebody,
but the speaker is quite skeptical. 2. When the gods/fates/other
time commitments permit the speaker to get to it. Often
abbreviated RSN.
REAL TIME adv. Doing something while people are watching or waiting.
``I asked her how to find the calling procedure's program counter
on the stack and she came up with an algorithm in real time.''
REAL USER n. 1. A commercial user. One who is paying ``real'' money
for his computer usage. 2. A non-hacker. Someone using the system
for an explicit purpose (research project, course, etc.). See
USER.
REAL WORLD, THE n. 1. In programming, those institutions at which
programming may be used in the same sentence as FORTRAN, COBOL,
RPG, IBM, etc. 2. To programmers, the location of non-programmers
and activities not related to programming. 3. A universe in which
the standard dress is shirt and tie and in which a person's working
hours are defined as 9 to 5. 4. The location of the status quo.
5. Anywhere outside a university. ``Poor fellow, he's left MIT and
gone into the real world.'' Used pejoratively by those not in
residence there. In conversation, talking of someone who has
entered the real world is not unlike talking about a deceased
person. See also FEAR AND LOATHING and UNINTERESTING.
RED BOOK n. Informal name for one of the three standard references on
PostScript; the others are known as the GREEN BOOK and BLUE BOOK.
REGEXP (reg'exp) [UNIX] n. Common written and spoken abbreviation for
`regular expression', one of the wildcard patterns used, e.g., by
UNIX utilities such as grep(1), sed(1) and awk(1). These use
conventions similar to but more elaborate than those described
under GLOB.
REINCARNATION, CYCLE OF n. Term used to refer to a well-known effect
whereby function in a computing system family is migrated out to
special purpose peripheral hardware for speed, then the peripheral
evolves towards more computing power as it does its job, then
somebody notices that it's inefficient to support two asymmetrical
processors in the architecture and folds the function back into the
main CPU, at which point the cycle begins again. Several
iterations of this cycle have been observed in graphics processor
design, and at least one or two in communications and
floating-point processors. Also known as ``the Wheel of Life'',
``the Wheel of Samsara'', and other variations of the basic
Hindu/Buddhist idea.
RELIGIOUS ISSUES n. Questions which seemingly cannot be raised without
touching off a FLAME WAR, such as ``What is the best
editor/language/operating system/architecture''. See also THEOLOGY.
RELIGIOUS WAR from USENET, but may predate it] n. FLAME WARS over
RELIGIOUS ISSUES.
REPLICATOR n. Any construct that acts to produce copies of itself;
this could be a living organism, an idea (see MEME), a program (see
WORM, WABBIT and VIRUS), or a robot.
RETROCOMPUTING (ret'-roh-k@m-pyoo'ting) n. Refers to emulations of
way-behind-the state-of-the-art hardware or software, or
implementations of never-was-state-of-the-art; esp. if such
implementations are elaborate practical jokes and/or parodies of
more `serious' designs. Perhaps the most widely distributed
retrocomputing utility was the pnch(6) program on V7 and other
early UNIX versions, which would accept up to 80 characters of text
argument and display the corresponding pattern in Hollerith card
code. Other well-known retrocomputing hacks have included the
language INTERCAL, a jcl-emulating shell for UNIX, and the
card-punch-emulating editor named 029.
RFC (ahr ef see) n. Request For Comment. One of a long-established
series of numbered Internet standards widely followed by commercial
and PD software in the Internet and UNIX communities. Perhaps the
single most influential one has been RFC-822 (the Internet
mail-format standard). The RFCs are unusual in that they are
floated by technical experts acting on their own initiative and
reviewed by the Internet at large, rather than formally promulgated
through an institution such as ANSI.
RICE BOX [from ham radio slang] n. Any Asian-made commodity computer,
esp. an 8086, 80286, 80386 or 80486-based machine built to IBM
PC-compatible ISA or EISA-bus standards.
RIGHT THING, THE n. That which is ``obviously'' the correct or
appropriate thing to use, do, say, etc. Use of this term often
implies that in fact reasonable people may disagree. ``Never let
your conscience keep you from doing the right thing!'' ``What's
the right thing for LISP to do when it reads `(.)'?'' Antonym: THE
WRONG THING (q.v.).
ROACH [Bell Labs] v. To destroy, esp. of a data structure. Hardware
gets TOASTed, software gets roached.
ROBUST adj. Said of a system which has demonstrated an ability to
recover gracefully from the whole range of exception conditions in
a given environment. One step below BULLETPROOF. Compare SMART,
oppose BRITTLE.
ROGUE [UNIX] n. Graphic Dungeons-And-Dragons-like game written under
BSD UNIX and subsequently ported to other UNIX systems. The
original BSD curses(3) screen-handling package was hacked together
by Ken Arnold to support ROGUE, and has since become one of UNIX's
most important and heavily used application libraries. See HACK.
ROOM-TEMPERATURE IQ [IBM] 80 or below. Used in describing the
expected intelligence range of the LUSER. As in ``Well, but how's
this interface gonna play with the room-temperature IQ crowd?'' See
DROOL-PROOF PAPER.
RTFM (ahr-tee-ef-em) [UNIX] Abbrev. for ``Read The Fucking Manual''.
Used by GURUs to brush off questions they consider trivial or
annoying. Compare DON'T DO THAT, THEN.
RTI (ahr-tee-ie) interj. The mnemonic for the `return from interrupt'
instruction on Intel microprocessors. Equivalent to ``Now, where
was I?'' or used to end a conversational digression. See POP, POPJ.
RUDE [WPI] adj. 1. (of a program) Badly written. 2. Functionally
poor, e.g. a program which is very difficult to use because of
gratuitously poor (random?) design decisions. See CUSPY.
= S =
SACRED adj. Reserved for the exclusive use of something (a
metaphorical extension of the standard meaning). ``Accumulator 7
is sacred to the UUO handler.'' Often means that anyone may look
at the sacred object, but clobbering it will screw whatever it is
sacred to.
SADISTICS (s@'dis'tiks) n. University slang for statistics and
probability theory, often used by hackers.
SAGA [WPI] n. A cuspy but bogus raving story dealing with N random
broken people.
SAIL n. Stanford University Artificial Intelligence Lab. An important
site in the early development of LISP (with the MIT AI LAB, CMU and
the UNIX community) one of the major founts of hacker culture
traditions. The SAIL machines were shut down in late May 1990,
scant weeks after the MIT AI lab's ITS cluster went down for the
last time.
SALT MINES n. Dense quarters housing large numbers of programmers
working long hours on grungy projects, with some hope of seeing the
end of the tunnel in N years. Noted for their absence of sunshine.
Compare PLAYPEN.
SANDBENDER [IBM] n. A person involved with silicon lithography and the
physical design of chips. Compare IRONMONGER, POLYGON PUSHER.
SCIENCE-FICTION FANDOM n. Another voluntary subculture having a very
heavy overlap with hackerdom; most hackers read SF and/or fantasy
fiction avidly, and many go to ``cons'' (SF conventions) or are
involved in fandom-connected activities like the Society for
Creative Anachronism. Some hacker slang originated in SF fandom;
see DEFENESTRATION, GREAT-WALL, CYBERPUNK, H INFIX, HA HA ONLY
SERIOUS, IMHO, MUNDANE, NEEP-NEEP, REAL SOON NOW. Additionally,
the jargon terms CYBERSPACE, GO FLATLINE, ICE, VIRUS, and WORM
originated in SF itself.
SCRATCH [from ``scratchpad''] 1. adj. A device or recording medium
attached to a machine for testing purposes; one which can be
SCRIBBLED on without loss. Usually in the combining forms SCRATCH
MEMORY, SCRATCH DISK, SCRATCH TAPE, SCRATCH VOLUME. See SCRATCH
MONKEY. 2. [primarily IBM] v. To delete (as in a file).
SCRATCH MONKEY n. As in, ``Before testing or reconfiguring, always
mount a''. A proverb used to advise caution when dealing with
irreplacable data or devices. Used in memory of Mabel, the Swimming
Wonder Monkey who expired when a computer vendor PM'd a machine
which was regulating the gas mixture that the monkey was breathing
at the time. See Appendix A. See SCRATCH.
SCREW [MIT] n. A LOSE, usually in software. Especially used for
user-visible misbehavior caused by a bug or misfeature.
SCREWAGE (scroo'@j) n. Like LOSSAGE (q.v.) but connotes that the
failure is due to a designed-in misfeature rather than a simple
inadequacy or mere bug.
SCROG (skrog) [Bell Labs] v. To damage, trash or corrupt a data
structure. ``The cblock got scrogged.'' Also reported as SKROG,
and ascribed to ``The Wizard of Id'' comix. Equivalent to SCRIBBLE
or MANGLE (q.v.)
SCROZZLE (skroh'zl) v. Used when a self-modifying code segment runs
incorrectly and corrupts the running program, or vital data. ``The
damn compiler scrozzled itself again!''
SCRIBBLE n. To modify a data structure in a random and unintentionally
destructive way. ``Bletch! Somebody's disk-compactor program went
berserk and scribbled on the i-node table.'' ``It was working fine
until one of the allocation routines scribbled on low core.''
Synonymous with TRASH; compare MUNG, which conveys a bit more
intention, and MANGLE, which is more violent and final.
SEARCH-AND-DESTROY MODE n. Hackerism for the search-and-replace
facility in an editor, so called because an incautiously chosen
match pattern can cause INFINITE damage.
SECOND-SYSTEM SYNDROME n. When designing the successor to a relatively
small, elegant and successful system, there is a tendency to become
grandiose in one's success and perpetrate an ELEPHANTINE
feature-laden monstrosity. The term `second-system syndrome' was
first used for this affliction in describing how the success of
CTSS led to the debacle that was MULTICS.
SEGGIE (seg'ee) [UNIX] n. Reported from Britain as a shorthand for
`segment violation', an attempted access to a protected memory area
usually resulting in a CORE DUMP.
SELF-REFERENCE n. See SELF-REFERENCE.
SELVAGE (selv'@j) n. See CHAD (sense #1).
SEMI (se'mee) 1. n. Abbreviation for ``semicolon'', when speaking.
``Commands to GRIND are prefixed by semi-semi-star'' means that the
prefix is ``;;*'', not 1/4 of a star. 2. Prefix with words such as
``immediately'', as a qualifier. ``When is the system coming up?''
``Semi-immediately.''
SERVER n. A kind of DAEMON which performs a service for the requester,
which often runs on a computer other than the one on which the
server runs. A particularly common term on the Internet, which is
rife with ``name servers'' ``domain servers'' ``news servers''
``finger servers'' and the like.
SEX [Sun User's Group & elsewhere] n. 1. Software EXchange. A
technique invented by the blue-green algae hundereds of millions of
years ago to speed up their evolution, which had been terribly slow
up until then. Today, SEX parties are popular among hackers and
others. 2. The rather Freudian mnemonic often used for Sign Extend,
a machine instruction found in many architectures.
SHAREWARE n. FREEWARE for which the author requests some payment,
usually in the accompanying documentation files or in an
announcement made by the software itself. Such payment may or may
not buy additional support or functionality. See GUILTWARE,
CRIPPLEWARE.
SHELFWARE n. Software purchased on a whim (by an individual user) or
in accordance with policy (by a corporation or government) but not
actually required for any particular use. Therefore, it often ends
up on some shelf.
SHELL [from UNIX, now used elsewhere] n. 1. The command interpreter
used to pass commands to an operating system. 2. More generally,
any interface program which mediates access to a special resource
or SERVER for convenience, efficiency or security reasons; for this
meaning, the usage is usually A SHELL AROUND whatever.
SHELL OUT [UNIX] n. To spawn an interactive subshell from within a
program such as a mailer or editor. ``BANG FOO runs FOO in a
SUBSHELL, while BANG alone shells out.''
SHIFT LEFT (or RIGHT) LOGICAL [from any of various machines'
instruction sets] 1. v. To move oneself to the left (right). To
move out of the way. 2. imper. Get out of that (my) seat! Usage:
often used without the ``logical'', or as ``left shift'' instead of
``shift left''. Sometimes heard as LSH (lish), from the PDP-10
instruction set.
SHRIEK See EXCL. Occasional CMU usage, also in common use among
mathematicians, especially category theorists.
SIG (sig) or SIG BLOCK (sig blahk) [UNIX; often written ``.sig''
there] n. Short for ``signature'', used specifically to refer to
the electronic signature block which most UNIX mail- and
news-posting software will allow you to automatically append to
outgoing mail and news. The composition of one's sig can be quite
an art form, including an ASCII logo or one's choice of witty
sayings; but many consider large sigs a waste of bandwidth, and it
has been observed that the size of one's sig block is usually
inversely proportional to one's longevity and level of prestige on
THE NETWORK.
SILICON n. Hardware, esp. ICs or microprocessor-based computer systems
(compare IRON). Contrasted with software.
SILLY WALK [from Monty Python] v. A ridiculous procedure required to
accomplish a task. Like GROVEL, but more RANDOM and humorous. ``I
had to silly-walk through half the /usr directories to find the
maps file.''
SILO n. The FIFO input-character buffer in an RS-232 line card. So
called from DEC terminology used on DH and DZ line cards for the
VAX and PDP-11.
SILVER BOOK, THE n. Jensen & Wirth's infamous ``Pascal User Manual and
Report'', so called because of the silver cover of the
widely-distributed Springer-Verlag second edition of 1978. See
WHITE BOOK, PURPLE BOOK, ORANGE BOOK.
ROTARY DEBUGGER [Commodore] n. Essential equipment for those late
night or early morning debugging sessions. Mainly used as
sustenance for the hacker. Comes in many decorator colors such as
Sausage, Pepperoni, and Garbage. See ANSI-STANDARD PIZZA.
SLEEP [from the UNIX sleep(3)] On a timesharing system, a process
which relinquishes its claim on the scheduler until some given
event occurs or a specified time delay elapses is said to `go to
sleep'.
SLOP n. 1. A one-sided fudge factor (q.v.). Often introduced to avoid
the possibility of a fencepost error (q.v.). 2. (used by compiler
freaks) The ratio of code generated by a compiler to hand-compiled
code, minus 1; i.e., the space (or maybe time) you lose because you
didn't do it yourself.
SLOPSUCKER n. A lowest-priority task that must wait around until
everything else has ``had its fill'' of machine resources. Only
when the machine would otherwise be idle is the task allowed to
``suck up the slop.'' Also called a HUNGRY PUPPY. One common
variety of slopsucker hunts for large prime numbers. Compare
BACKGROUND.
SLUGGY (sluh'gee) adj. Hackish variant of `sluggish'. Used only of
people, esp. someone just waking up after a long GRONK-OUT.
SLURP v. To read a large data file entirely into core before working
on it. ``This program slurps in a 1K-by-1K matrix and does an
FFT.''
SMART adj. Said of a program that does the RIGHT THING (q.v.) in a
wide variety of complicated circumstances. There is a difference
between calling a program smart and calling it intelligent; in
particular, there do not exist any intelligent programs (yet).
Compare ROBUST (smart programs can be BRITTLE).
SMASH THE STACK [C programming] n. On many C implementations it is
possible to corrupt the execution stack by writing past the end of
an array declared auto in a routine. Code that does this is said to
`smash the stack', and can cause return from the routine to jump to
a random text address. This can produce some of the most insidious
data-dependent bugs known to mankind. Variants include `trash the
stack', `SCRIBBLE ON the stack', `MANGLE the stack'; `MUNG the
stack' is not used as this is never done intentionally. See
ALIASING BUG, FANDANGO ON CORE, MEMORY LEAK, PRECEDENCE LOSSAGE,
OVERRUN SCREW.
SMILEY n. See EMOTICON.
SMOKE TEST n. 1. A rudimentary form of testing applied to electronic
equipment following repair or reconfiguration in which AC power is
applied and during which the tester checks for sparks, smoke, or
other dramatic signs of fundamental failure. 2. By extension, the
first run of a piece of software after construction or a critical
change. See MAGIC SMOKE.
SMOKING CLOVER n. A DISPLAY HACK originally due to Bill Gosper. Many
convergent lines are drawn on a color monitor in AOS mode (so that
every pixel struck has its color incremented). The color map is
then rotated. The lines all have one endpoint in the middle of the
screen; the other endpoints are spaced one pixel apart around the
perimeter of a large square. This results in a striking,
rainbow-hued, shimmering four-leaf clover. Gosper joked about
keeping it hidden from the FDA lest it be banned.
SMOP (smop) [Simple (or Small) Matter of Programming] n. A piece of
code, not yet written, whose anticipated length is significantly
greater than its complexity. Usage: used to refer to a program
that could obviously be written, but is not worth the trouble.
SNAIL-MAIL n. Paper mail, as opposed to electronic. See EMAIL.
SNARF (snarf) v. 1. To grab, esp. a large document or file for the
purpose of using it either with or without the author's permission.
See BLT. Variant: SNARF (IT) DOWN. (At MIT on ITS, DDT has a
command called :SNARF which grabs a job from another (inferior)
DDT.) 2. [in the UNIX community] to fetch a file or set of files
across a network. See also BLAST.
SNARF & BARF (snarf-n-barf) n. The act of grabbing a region of text
using a WIMP (q.v.) environment (Window, Icon, Mouse, Pointer) and
then ``stuffing'' the contents of that region into another region
or into the same region, to avoid re-typing a command line.
SNEAKERNET n. Term used (generally with ironic intent) for transfer of
electronic information by physically carrying tape, disks, or some
other media from one machine to another. ``Never underestimate the
bandwidth of a station wagon filled with magtape, or a 747 filled
with CD-ROMs.'' Also called ``Tennis-Net'', ``Armpit-Net''.
SNIFF v.,n. Synonym for POLL.
S.O. (ess-oh) n. Acronym for Significant Other, almost invariably
written abbreviated and pronounced ``ess-oh'' by hackers. In fact
the form without periods ``SO'' is most common. Used to refer to
one's primary relationship, esp. a live-in to whom one is not
married. See MOTAS, MOTOS, MOTSS.
SOFTCOPY n. [back-formation from `hardcopy'] A machine readable form
of corresponding hardcopy. See BITS.
SOFTWARE ROT n. Hypothetical disease the existence of which has been
deduced from the observation that unused programs or features will
stop working after sufficient time has passed, even if ``nothing
has changed''. Also known as BIT DECAY, BIT ROT. Occasionally
this turns out to be a real problem due to media failure.
SOFTWARILY (soft-weir'i-lee) adv. In a way pertaining to software.
``The system is softwarily unreliable.'' The adjective
``softwary'' is NOT used. See HARDWARILY.
SOME RANDOM X adj. Used to indicate a member of class X, with the
implication that the particular X is interchangeable with most
other Xs in whatever context was being discussed. ``I think some
random cracker tripped over the guest timeout last night.''
SORCEROR'S APPRENTICE MODE n. A bug in a protocol where, under some
circumstances, the receipt of a message causes more than one
message to be sent, each of which, when received, triggers the same
bug. Used esp. of such behavior caused by BOUNCE MESSAGE loops in
EMAIL software. Compare BROADCAST STORM.
SPACEWAR n. A space-combat simulation game first implemented on the
PDP-1 at MIT in 1960-61. SPACEWAR aficionados formed the core of
the early hacker culture at MIT. Ten years later a descendant of
the game motivated Ken Thompson to invent UNIX (q.v.). Ten years
after that, SPACEWAR was commercialized as one of the first video
games; descendants are still feeping in video arcades everywhere.
SPAGHETTI CODE n. Describes code with a complex and tangled control
structure, esp. one using many GOTOs, exceptions or other
`unstructured' branching constructs. Pejorative.
SPAGHETTI INHERITANCE n. [Encountered among users of object-oriented
languages that use inheritance, such as Smalltalk] A convoluted
class-subclass graph, often resulting from carelessly deriving
subclasses from other classes just for the sake of reusing their
code. Coined in a (successful) attempt to discourage such
practice, through guilt by association with SPAGHETTI CODE.
SPIFFY (spi'fee) adj. 1. Said of programs having a pretty, clever or
exceptionally well-designed interface. ``Have you seen the spiffy X
version of EMPIRE yet?'' 2. Said sarcastically of programs which
are perceived to have little more than a flashy interface going for
them. Which meaning should be drawn depends delicately on tone of
voice and context.
SPIN v. Equivalent to BUZZ (q.v.). More common among C and UNIX
programmers.
SPLAT n. 1. Name used in many places (DEC, IBM, and others) for the
ASCII star (``*'') character. 2. [MIT] Name used by some people
for the ASCII pound-sign (``#'') character. 3. [Stanford] Name
used by some people for the Stanford/ITS extended ASCII circle-x
character. (This character is also called ``circle-x'',
``blobby'', and ``frob'', among other names.) 4. [Stanford] Name
for the semi-mythical extended ASCII circle-plus character. 5.
Canonical name for an output routine that outputs whatever the the
local interpretation of splat is. Usage: nobody really agrees what
character ``splat'' is, but the term is common.
SPOOGE (spooj) 1. n. Inexplicable or arcane code, or random and
probably incorrect output from a computer program 2. v. To generate
code or output as in definition 1.
SPOOL v. To send files to some device or program (a `spooler') that
queues them up and does something useful with them later. The
spooler usually understood is the `print spooler' controlling
output of jobs to a printer, but the term has been used in
connection with other peripherals (especially plotters and graphics
devices).
STACK n. See PDL. The STACK usage is probably more common outside
universities.
STACK PUKE n. Some micros are said to ``puke their guts onto the
stack'' to save their internal state during exception processing.
On a pipelined machine this can take a while (up to 92 bytes for a
bus fault on the 68020, for example).
STALE POINTER BUG n. Synonym for ALIASING BUG used esp. aming
microcomputer hackers.
STATE n. Condition, situation. ``What's the state of NEWIO?'' ``It's
winning away.'' ``What's your state?'' ``I'm about to gronk
out.'' As a special case, ``What's the state of the world?'' (or,
more silly, ``State-of-world-P?'') means ``What's new?'' or
``What's going on?''
STIR-FRIED RANDOM alt. STIR-FRIED MUMBLE (ster-fried mum'bl) n. Term
used for frequent best dish of those hackers who can cook. Consists
of random fresh veggies and meat wokked with random spices. Tasty
and economical. See RANDOM, GREAT-WALL, CHINESE RAVS, ORIENTAL
FOOD.
STOMP ON v. To inadvertently overwrite something important, usually
automatically. Example: ``All the work I did this weekend got
stomped on last night by the nightly-server script.'' Compare
SCRIBBLE, MANGLE, TRASH, SCROG, ROACH.
STOPPAGE (sto'p@j) n. Extreme lossage (see LOSSAGE) resulting in
something (usually vital) becoming completely unusable.
STUNNING adj. Mind-bogglingly stupid. Usually used in sarcasm. ``You
want to code *what* in ADA? That's...a stunning idea!'' See also
NON-OPTIMAL SOLUTION.
SUBSHELL [UNIX, MS-DOS] n. An OS command interpreter (see SHELL)
spawned from within a program, such that exit from the command
interpreter returns one to the parent program in a state that
allows it to continue execution. Oppose CHAIN.
SUIT n. 1. Ugly and uncomfortable `business clothing' often worn by
non-hackers. Invariably worn with a `tie', a strangulation device
which partially cuts off the blood supply to the brain. It is
thought that this explains much about the behavior of suit-
wearers. 2. A person who habitually wears suits, as distinct from a
techie or hacker. See LOSER, BURBLE and BRAIN-DAMAGED.
SUNSPOTS n. Notional cause of an odd error. ``Why did the program
suddenly turn the screen blue?'' ``Sunspots, I guess''. Also cause
of bitrot, from the genuine, honest-to-god fact that sunspots will
increase cosmic radiation which can flip single bits in memory.
Needless to say, although real sunspot errors happen, they are
extremely rare. See PHASE OF THE MOON.
SUN-STOOLS n. Unflattering hackerism for SunTools, a pre-X windowing
environment notorious in its day for size, slowness and
misfeatures.
SUPERPROGRAMMER n. See WIZARD, HACKER, GURU. Usage: rare. (Becoming
more common among IBM and Yourdon types.)
SUZIE COBOL (soo'zee koh'bol) 1. [IBM, prob. fr. Frank Zappa's
``little Suzy Creamcheese''] n. A coder straight out of training
school who knows everything except the benefits of comments in
plain English. Also (fashionable among personkind wishing to avoid
accusations of sexism) `Sammy Cobol' 2. [generalization proposed by
ESR] Meta-name for any CODE GRINDER, analogous to J. RANDOM HACKER.
SWAB [From the PDP-11 ``byte swap'' instruction] 1. v. to solve the
NUXI PROBLEM by swapping bytes in a file. 2. Also, the program in
V7 UNIX used to perform this action. See also BIG-ENDIAN,
LITTLE-ENDIAN, BYTESEXUAL.
SWAPPED adj. From the use of secondary storage devices to implement
virtual memory in computer systems. Something which is SWAPPED IN
is available for immediate use in main memory, and otherwise is
SWAPPED OUT. Often used metaphorically to refer to people's
memories (``I read TECO ORDER every few months to keep the
information swapped in.'') or to their own availability (``I'll
swap you in as soon as I finish looking at this other problem.'').
Compare PAGE IN, PAGE OUT.
SWIZZLE v. To convert external names or references within a data
structure into direct pointers when the data structure is brought
into main memory from external storage; also called POINTER
SWIZZLING; the converse operation is sometimes termed UNSWIZZLING.
SYNC (sink) [from UNIX] n.,v. 1. To force all pending I/O to the disk.
2. More generally, to force a number of competing processes or
agents to a state that would be `safe' if the system were to crash;
thus, to checkpoint. See FLUSH.
SYNTACTIC SUGAR n. Features added to a language or formalism to make
it `sweeter' for humans, that do not affect the expressiveness of
the formalism (compare CHROME). Used esp. when there is an obvious
and trivial translation of the `sugar' feature into other
constructs already present in the notation. Example: the \n, \t,
\r, and \b escapes in C strings, which could be expressed as octal
escapes. Coined by Peter Landin. ``Syntactic sugar causes cancer of
the semicolon.'' - Alan Perlis.
SYS-FROG [the PLATO system] n. Playful hackish variant of ``sysprog''
which is in turn short for ``systems-programmer''.
SYSTEM n. 1. The supervisor program on the computer. 2. Any
large-scale program. 3. Any method or algorithm. 4. The way
things are usually done. Usage: a fairly ambiguous word. ``You
can't beat the system.'' SYSTEM HACKER: one who hacks the system
(in sense 1 only; for sense 2 one mentions the particular program:
e.g., LISP HACKER)smith@sctc.com (Rick Smith) (12/01/90)
I detect some serious Multics ignorance here... check the entries
for MULTICS, BRAIN DAMAGE, and SECOND SYSTEM EFFECT. The correction
is lengthy...
First, MULTICS stands for "MULTIplexed Information and Computing Service,"
not "Multiprogrammed" whatever. Multics started as an ARPA/IPTO project
involving people from Project MAC (that's now MIT/LCS), Bell Labs, and
General Electric. Bell and MIT dropped out in '69. GE was bought by
Honeywell and Honeywell offered Multics 'commercially' in the early 70s.
BTW, A common term for Multics hackers, out here anyway, was MULTICIAN.
The classical definition of BRAIN DAMAGE (qv JARGON.TXT circa '79) derived
it from HBD ("Honeywell Brain Damage"), a term applied to certain nasty
things done to Multics after Honeywell took it over, NOT the whole system.
For example, there are some weird accounting practices that would boot
people off unnecessarily. Also, Multics security was of the B&D variety,
not at all consistent with the ITS :CRASH mindset. Of course, DOD
loved it and their security jocks gave it the first B2 security rating.
In general, Multics was an incredible piece of work. Lots and Lots of
orthogonality. Everything was a segment, like Unix' 'everything a file.'
Multics was the first major system developed using a high level language,
and (like Unix in the good old days) the source was ONLINE. Unlike
many timesharing systems at the time, you could do EVERYTHING through
timesharing -- you never *needed* to run a batch job to do some mundate
system task. IBM, GE, CDC, ad nauseum, eat your hearts out.
The Problem with Multics was that it ran on Big Iron. PDP-10s weren't big
iron, not quite. Big Iron is EXPENSIVE. Few hackers were invited to hack
away at Multics, though there were enough to make it a really fine place
to work. The high cost made Bell Labs decide to not use it. And the SUITS
who sold computers for Honeywell didn't want to be bothered with Multics:
it wasn't the same as the ugly GECOS/GCOS boxes that they all knew how
to sell. There were never more than a handful of Multics systems, and
I only remember ever seeing 3 of them on the Arpanet.
The SECOND SYSTEM EFFECT was a term used by Fred Brooks in his classic
book "Mythical Man Month." It described the jump from a set of nice, simple,
operating monitors on the IBM 70xx series to OS/360 on the 360 series.
OS/360 and its unfortunate offspring set the standard for ELEPHANTINE, UGLY,
WRONG THING, and so on. The SECOND SYSTEM EFFECT has to do with BRUTE FORCE
implementation of CHROME, BELLS, and WHISTLES, and not with mere size and
cost.
What is the source of this nonsense describing Multics as the SECOND
SYSTEM EFFECT applied to CTSS? That's as fair as comparing Unix V6
(as CTSS) with today's Unix (as Multics). Sure, V6 is clean and simple,
but it doesn't make very good use of virtual memory and it doesn't support
a zillion users, TCP, or windows.
A Unix hacker can't sneer at Multics. It's like sneering at your grandad.
Sure he's a doddering wreck, but he created some pretty fine stuff that
we can still be proud of. You, for example.
Rick.
smith@sctc.com Arden Hills, Minnesotapeter@ficc.ferranti.com (Peter da Silva) (12/02/90)
In article <1990Nov30.172512.5282@sctc.com> smith@sctc.com (Rick Smith) writes: > What is the source of this nonsense describing Multics as the SECOND > SYSTEM EFFECT applied to CTSS? That's as fair as comparing Unix V6 > (as CTSS) with today's Unix (as Multics). Sure, V6 is clean and simple, > but it doesn't make very good use of virtual memory and it doesn't support > a zillion users, TCP, or windows. Actually, those of us who still thing REAL UNIX means Version 6 or Version 7 find this particular comparison wonderfully appropriate. Version 7 UNIX at Berekeley supported 60 users on an 11/70. Not very well, but it stayed up and kept popping out prompts (albeit slowly). The EECSVAX running 4.0 BSD could handle maybe 35. The 386 box on my desk at work is a comparable machine, with 5 times the RAM of the old 11/70, but more than 10 users kill it dead. And that's probably more users than the typical 386-class UNIX box is expected to support. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
pst@ir.Stanford.EDU (Paul Traina) (12/02/90)
In article <O7Y77DB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
Actually, those of us who still thing REAL UNIX means Version 6 or Version 7
find this particular comparison wonderfully appropriate. Version 7 UNIX at
Berekeley supported 60 users on an 11/70. Not very well, but it stayed up
and kept popping out prompts (albeit slowly). The EECSVAX running 4.0 BSD
could handle maybe 35. The 386 box on my desk at work is a comparable
machine, with 5 times the RAM of the old 11/70, but more than 10 users kill
it dead. And that's probably more users than the typical 386-class UNIX box
is expected to support.
You're comparing CPU performance to I/O performance. It's natural
that sofware will grow and become more complex. CPU's have done a
good job of keeping up. However, most electrical engineers who design
computers couldn't DESIGN a good CPU unit (read: chip/chip set) if
their lives depended on it. However, they feel perfectly at home
mucking up support hardware and I/O subsystems.
Back when there were REAL(tm) computers like 780, a lot of time and
energy went into designing efficient I/O from the CPU bus to the
electrons going to the disk or tty. Now, Joe schlock, the snot nosed
kid you used to beat up when you were a teenager, works for <generic
PC clone ripoff company> and thinks that he knows how to design a
computer because he can cut and paste in pCAD.
Sure OS's and apps have gotten bloated, but when you put a chip like
the MIPS R3000 on a machine barely more advanced than an IBM-AT you
end up with a toy that can think fast but can't do anything. I can't
really blame companies like DEC and Sun for producing mismatched
hardware, because their marketing drones are constantly trying to
undercut each other in price. It's a hell of a lot more expensive to
ship a product with a well designed I/O system than to drop in a
"killer bitchen" CPU chip; occasionally someone makes the attempt do
design a great piece of hardware, and you end up with something not
half bad (like the DECstation 5000, which is only crippled by Ultrix
(grin)).
--
It's clear to me who the real enemy of the United States is--it's not Iraq.
The enemy of the people of the United States is McDonald-Douglas, General
Motors, General Electric, Lockheed, and the leaders of the combined forces of
the United States. Do your patriotic duty--kill a hawk to save the country.eric@snark.thyrsus.com (Eric S. Raymond) (12/02/90)
In <1990Nov30.172512.5282@sctc.com> Rick Smith wrote: > What is the source of this nonsense describing Multics as the SECOND > SYSTEM EFFECT applied to CTSS? Um...Dennis Ritchie, I think, in a retrospective on the history of UNIX -- but I can't put my finger on the exact quote. Dennis, if you're listening, can you confirm or deny this? I will incorporate several of your corrections. Upon doing a context grep for MULTICS it does seem that the references to it are uniformly negative. That is unfair and was unintended; though I agree with the charge that MULTICS became somewhat bloated and at least partly a victim of design grandiosity, I also do think that it expressed some of the best thinking about OS design in its day and doesn't deserve to be `sneered at' by anyone. I will add some description of MULTICS's contributions to OS design to the MULTICS entry. Thanks for your feedback. -- Eric S. Raymond = eric@snark.thyrsus.com (mad mastermind of TMN-Netnews)
zap@savage.UUCP (Zap Savage) (12/03/90)
In article <O7Y77DB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > The 386 box on my desk at work is a comparable >machine, with 5 times the RAM of the old 11/70, but more than 10 users kill >it dead. And that's probably more users than the typical 386-class UNIX box >is expected to support. Actually, we had a 386/33 with 8Mb Ram, 500Mb FD with a very expensive controller card with about 4M or 8M (I can't remember which) of RAM of its own, two 16-port ARNET SmartPort cards (28-30 ports used) running SCO Unix 386 Sys V. We were running shared copies of some inhouse software written with dbVista and Vermont Views (nice stuff, both of them) and also Word Perfect for Unix. We didn't have much problem with slow down unless everyone was running a report at the same time. Zap
sef@kithrup.COM (Sean Eric Fagan) (12/03/90)
In article <O7Y77DB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >The 386 box on my desk at work is a comparable >machine, with 5 times the RAM of the old 11/70, but more than 10 users kill >it dead. And that's probably more users than the typical 386-class UNIX box >is expected to support. That's because the '386 box, although it has the processing power, doesn't have the I/O power. I.e., NO BANDWIDTH! If we're really lucky, the EISA machines will help this a lot; they should be able to do things better. Note that, while the Intel-based MCA machines don't have the throughput needed for lots of users, the RS6000 (also MCA based) *does*. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
tjo@its.bt.co.uk (Tim Oldham) (12/04/90)
In article <1990Dec03.015154.9137@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <O7Y77DB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>The 386 box on my desk at work is a comparable >>machine, with 5 times the RAM of the old 11/70, but more than 10 users kill >>it dead. And that's probably more users than the typical 386-class UNIX box >>is expected to support. > >That's because the '386 box, although it has the processing power, doesn't >have the I/O power. I.e., NO BANDWIDTH! True for a basic generic 386 box. Bung in a decent disk cache board with a few Megs and, say, a 286 and you're away. Usually. Application specific, of course. Tim. -- Tim Oldham, BT Applied Systems. tjo@its.bt.co.uk or ...uunet!ukc!its!tjo Well, you'd have a corporate siege mentality, too.
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/05/90)
On 1 Dec 90 21:14:40 GMT, pst@ir.Stanford.EDU (Paul Traina) said:
pst> In article <O7Y77DB@xds13.ferranti.com> peter@ficc.ferranti.com
pst> (Peter da Silva) writes:
pst> Actually, those of us who still thing REAL UNIX means Version 6 or
pst> Version 7 find this particular comparison wonderfully appropriate.
pst> Version 7 UNIX at Berekeley supported 60 users on an 11/70. [ ... ]
pst> The 386 box on my desk at work is a comparable machine, with 5
pst> times the RAM of the old 11/70, but more than 10 users kill it
pst> dead.
Note that the number of users that an 11/70 could support depended
critically on whether they were using ed or vi (line or character at a
time IO), and on whether you had fast or slow swapping. Swapping is good
-- most of the time timeharing users are thinking (say one user in 10 is
usually "active"). If swapping in takes less than half a second it is
imperceptible. Unfortunately designing a good swapper is a tough thing
apparently, and the UNIX swapper has not been redesigned for VM; it is
still the one used to swap 64k images.
pst> You're comparing CPU performance to I/O performance. [ ... ] Back
pst> when there were REAL(tm) computers like 780, a lot of time and
pst> energy went into designing efficient I/O from the CPU bus to the
pst> electrons going to the disk or tty. [ ... ] Sure OS's and apps have
pst> gotten bloated, but when you put a chip like the MIPS R3000 on a
pst> machine barely more advanced than an IBM-AT you end up with a toy
pst> that can think fast but can't do anything.
No, no, no, no, no, no, no. The IO bandwidth of a typical 386 is
equivalent or better than that of any UNIBUS based machine, and, in
practical terms, equivalent to that of MASSBUS based ones. You can get
observable raw disc data rates of 600-900KB/s and observable filesystem
bandwidths of 300-500KB/s under SVR3.2 (with suitable controllers and a
FFS of some sort). This is way better than a PDP-11.
There are many reasons for which UNIX has become even more obscenely
inefficient; mostly it is just plain old lack of hard thinking (read
"lack of design talent"). I love to repeat my old line: talented
(japanese) process engineers are easier to find than (american) OS
designers, so there is abundant supply of high density RAMs and high
waste OSes.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukjcburt@ipsun.larc.nasa.gov (John Burton) (12/05/90)
In article <PCG.90Dec4160737@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: [...] >pst> You're comparing CPU performance to I/O performance. [ ... ] Back >pst> when there were REAL(tm) computers like 780, a lot of time and >pst> energy went into designing efficient I/O from the CPU bus to the >pst> electrons going to the disk or tty. [ ... ] Sure OS's and apps have >pst> gotten bloated, but when you put a chip like the MIPS R3000 on a >pst> machine barely more advanced than an IBM-AT you end up with a toy >pst> that can think fast but can't do anything. > >No, no, no, no, no, no, no. The IO bandwidth of a typical 386 is >equivalent or better than that of any UNIBUS based machine, and, in >practical terms, equivalent to that of MASSBUS based ones. You can get >observable raw disc data rates of 600-900KB/s and observable filesystem >bandwidths of 300-500KB/s under SVR3.2 (with suitable controllers and a >FFS of some sort). This is way better than a PDP-11. > True, a typical 386 machine has good I/O bandwidth, but bandwidth isn't everything. The majority of 386 machines have an ISA bus which is a very simple bus controlled by the cpu. When performing I/O, the cpu blocks itself and turns control of the bus to the I/O device. When the I/O operation is complete, control returns to the cpu, which unblocks itself. What this means is that any I/O severly impacts the apparent system response. As a single user system, the typical 386 machine is just fine. A typical multi-user, virtual memory system (UNIX) requires a significantly greater amount of I/O than a single user system. Machines that were originally designed as a multi-user platform usually where set up so that the I/O could be performed without the direct control (or blocking) of the cpu. The system bus was designed so that multiple operations could occur more or less independent of the cpu (multi-tasking hardware design). The typical 386 machine is designed as a single tasking machine (regardless of what the cpu can do, the bus & support hardware was designed for single tasking). If you are planning on using a 386 machine as a multi-user platform, you might want to consider an EISA or an MicroChannel based system as opposed to an ISA based system. EISA & MicroChannel at least have some provisions for multi-tasking operations. Hope this helps some. John Burton
magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) (12/05/90)
Could you PLEASE move this discussion about I/O bandwidth, multitasking etc to comp.arch or some other appropriate newsgroup? It has nothing whatsoever to do with folklore anymore... Magnus
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/06/90)
On 30 Nov 90 17:25:12 GMT, smith@sctc.com (Rick Smith) said: smith> A Unix hacker can't sneer at Multics. It's like sneering at your smith> grandad. Sure he's a doddering wreck, but he created some pretty smith> fine stuff that we can still be proud of. You, for example. If only! A very good argument can be made that Multics is a descendant of Unix! You can consider Multics the grandchild of Unix. Maybe Unix SVR6 or 4.9BSD will come close in elegance and functionality and efficiency to what Multics was 20 years ago. Or more probably it will be a hacked up monster ten times the size and ten times slower and incomprehensible and ... (note: Unix V7 is quite another thing, addresses different needs than those served by a Multics or System V, and was an elegant exercise in minimalism on a very simple architecture) -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
pst@ack.Stanford.EDU (Paul Traina) (12/06/90)
In <PCG.90Dec4160737@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
<No, no, no, no, no, no, no. The IO bandwidth of a typical 386 is
<equivalent or better than that of any UNIBUS based machine, and, in
<practical terms, equivalent to that of MASSBUS based ones. You can get
<observable raw disc data rates of 600-900KB/s and observable filesystem
<bandwidths of 300-500KB/s under SVR3.2 (with suitable controllers and a
<FFS of some sort). This is way better than a PDP-11.
You're absolutely right and I stand corrected. The UNIBUS itself _is_ a pig
compared to modern bus'es. However, you're not scaling your I/O performance
with your CPU. You're talking about blowing CPU performance out of the water
(386 vs 11/70) but you're still talking about comparable I/O (even if we go
MASSBUS and 780). Where's the exponential performance increase in I/O?
<There are many reasons for which UNIX has become even more obscenely
<inefficient; mostly it is just plain old lack of hard thinking (read
<"lack of design talent"). I love to repeat my old line: talented
<(japanese) process engineers are easier to find than (american) OS
<designers, so there is abundant supply of high density RAMs and high
<waste OSes.
Gee, I hope the guys at Sun don't read your note. :-) One of my favorite
lines is "you get what you pay for." You're welcome to fix the bsd VM
subsystem (actually, it has been fixed).
Paulzap@savage.UUCP (Zap Savage) (12/07/90)
In article <1990Dec5.144445.18632@abcfd20.larc.nasa.gov> jcburt@ipsun.larc.nasa.gov (John Burton) writes:
%True, a typical 386 machine has good I/O bandwidth, but bandwidth isn't
%everything. The majority of 386 machines have an ISA bus which is a
%very simple bus controlled by the cpu. When performing I/O, the
%cpu blocks itself and turns control of the bus to the I/O device.
%When the I/O operation is complete, control returns to the cpu, which
%unblocks itself.
%...
%Machines that were originally designed as a multi-user platform usually
%where set up so that the I/O could be performed without the direct control
%(or blocking) of the cpu. The system bus was designed so that multiple
%operations could occur more or less independent of the cpu (multi-tasking
%hardware design). The typical 386 machine is designed as a single tasking
%machine (regardless of what the cpu can do, the bus & support hardware
%was designed for single tasking).
Significant bottlenecks in multiuser micros should be disk and serial ports,
right? Anyone know how much system loading Arnet Smartports create? I know
they have their own 80286 onboard that does all of the work; the main processor
just sends and receives over the bus to the 286 and continues on its merry way.
Do Arnet Smartports also cause the CPU to block the bus and sleep?
How about disk or network controllers? Are there any out there that are smart
boards that don't cause the system to block?
Zapdarragh@maths.tcd.ie (Darragh J. Delany) (12/11/90)
In article <PCG.90Dec5162259@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: }On 30 Nov 90 17:25:12 GMT, smith@sctc.com (Rick Smith) said: }smith> A Unix hacker can't sneer at Multics. It's like sneering at your }smith> grandad. Sure he's a doddering wreck, but he created some pretty }smith> fine stuff that we can still be proud of. You, for example. }If only! A very good argument can be made that Multics is a descendant }of Unix! You can consider Multics the grandchild of Unix. If I remember rightly the very name Unix was a pun on Multics which was the epitomy of what an efficient operating system should not have been. Darragh.
dlw@odi.com (Dan Weinreb) (12/12/90)
In article <1990Dec10.173546.25184@maths.tcd.ie> darragh@maths.tcd.ie (Darragh J. Delany) writes:
If I remember rightly the very name Unix was a pun on Multics
which was the epitomy of what an efficient operating system
should not have been.
The word is spelled "epitome", and Multics was so efficient that its
emulator for the alternative operating system that could run on that
hardware (namely GCOS-3) actually ran programs FASTER than GCOS-3
did itself. The name "Unix" was meant to mean "a little version
of Multics". It had to be little, to fit on a PDP-7.rembo@unisoft.UUCP (Tony Rems) (12/13/90)
In article <1990Dec11.165727.5357@odi.com> dlw@odi.com writes: >In article <1990Dec10.173546.25184@maths.tcd.ie> darragh@maths.tcd.ie (Darragh J. Delany) writes: > > If I remember rightly the very name Unix was a pun on Multics > which was the epitomy of what an efficient operating system > should not have been. > >The word is spelled "epitome", and Multics was so efficient that its >emulator for the alternative operating system that could run on that >hardware (namely GCOS-3) actually ran programs FASTER than GCOS-3 >did itself. The name "Unix" was meant to mean "a little version >of Multics". It had to be little, to fit on a PDP-7. From page 3 of "The Design and Implementation of the 4.3BSD UNIX Operating System" "Even the name "UNIX" is merely a pun on Multics; in areas where Multics attempted to do many things, UNIX tried to do one thing well." Sounds reasonable to me. -Tony
dlw@odi.com (Dan Weinreb) (12/14/90)
In article <3268@unisoft.UUCP> rembo@unisoft.UUCP (Tony Rems) writes:
From page 3 of
"The Design and Implementation of the 4.3BSD UNIX Operating System"
"Even the name "UNIX" is merely a pun on Multics; in areas where
Multics attempted to do many things, UNIX tried to do one thing well."
Well, Multics isn't called that because it does "many things". The
"Multi" part is from the word "multiplexed", meaning that it is
time-sharing system. As is Unix, of course. I wonder what is the
one thing that Unix tried to do well.rbj@uunet.UU.NET (Root Boy Jim) (12/14/90)
In article <1990Dec13.214234.16529@odi.com> dlw@odi.com writes: >Well, Multics isn't called that because it does "many things". The >"Multi" part is from the word "multiplexed", meaning that it is >time-sharing system. As is Unix, of course. I wonder what is the >one thing that Unix tried to do well. Actually, it does two things: Schedule Processes and Multiplex I/O. Now if /dev/proc (Processes as Files) had existed at that time, it could be truly said that it did just one thing. Actually, I think that from Ken Thompson's point of view that the one thing it did well was play chess. At least endgames. -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between