Very Computer

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

read more »

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

Quote:> What is the source of this nonsense describing Multics as the SECOND
> SYSTEM EFFECT applied to CTSS?

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

   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 *ager, 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 *en" 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.

Quote:>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 *en" 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

                                        ---Rob

--

        *WHY* is it natural that software will grow? *WHY* is it natural
that it become more complex? *WHY* does it have to have ever more
expensive processors to run on?

        Because the idea of eliminating old "features" has never been
considered. If cars were designed the same way as software is today,
they'd all have buggy-whip holders (from "Car V1.0") and starter cranks
(from "Car V2.1") and electric ignitions (from "Car V3.0") and so on.

        Has anyone ever attempted any kind of studies to quantify the
effect (other than on size and CPU requirements, disk requirements, and
cost/seat) of adding "features" to software? I'd love to see some data
about the aggregate usefulness of software *within its problem area*
as features are added. What I mean by *within its problem area* is
to study text editors, for example, only in terms of their functionality
as text editors - rather than as LISP interpreters or news readers. :)
It's been my impression that only a small percentage of any given
program's functinality is ever used - possibly for each new set of
"features" that are added only a comparable percentage of those are
used as well, so the performance cost and monetary cost of the new
"features" is largely wasted. I'd love to see a study as to what
the adoption rate is of new "features" among users who are familiar
with the software already, and already have developed patterns of
use. If someone were to double the "features" in, say, X-window,
making it half again as large and half again as slow, how long
would it be before 10% of those new "features" were in active use?
how long would it take for 20%, 30%? - and would it ever hit 100%?

        My perception, which is doubtless flawed, is that once
software hits a certain basic level of functionality any additional
features are simply extensions of that software's functionality
outside of its problem area. In other words, once the developer
has sold you all the functionality you NEED in your spreadsheet,
it is extended into a rendering and visualization system as well,
giving pie charts, etc, ad nauseam - and, oops, you need another
2 Meg in your machine now. The fallacy here is the pursuit of the
"integrated environment" - users are unwilling to have to exit
their text editor to read news (for example) - but it's chicken
and egg - possibly their unwillingness is a result of the incredible
startup time their bloated text editor requires. :) Add to that
the confusion between different command interfaces, and it seems
that every significant software system tries to evolve into being
its own operating system - hogging and allocating all the resources
of the host hardware.

        I don't quite know how it happened this way. Software,
being unreal, is probably better able to fit together in modular
components than just about anything else - yet I can walk to
the hardware store, and buy a light switch that doesn't have an
integrated timer/thermostat/LISP interpreter, and I can still
build simple, elegant systems with only the functionality I
need - at a reasonable cost. The designers of UNIX had it right,
UNIX' modularity and simplicity made it ideal for handling just
about anything except commercial success.

        Sorry to ramble. All disclaimers apply, of course. I
don't speak for Digital, my cats, or my friends.

mjr.
--
        If your windowing system is placing undue demands on your hardware
and operating system, don't ask yourself what can be done to improve the
operating system or hardware - ask yourself why you are using that windowing
system.         [from the programming notebooks of a heretic, 1990]

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

Zap

    The CPU couldn't have been as powerful as a 68030 or 486, but it'd
do real-time flight simulation without a hitch, or timeshare more than
90 users before it started to get annoying.

--
 _

DeMott Electronics Co. 14707 Keswick St.   Van Nuys, CA 91405-1266
VOICE (818) 988-4975   FAX (818) 997-1190  MODEM (818) 997-4496 PEP last

                96.37% of all statistics are made up.

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

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;

-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.