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, Minnesota
peter@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.uk
jcburt@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).
Paul
zap@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?
Zap
darragh@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