Part 31

:P.O.D.: /P-O-D/ Acronym for `Piece Of Data' (as opposed to a code section). Usage: pedantic and rare. See also {pod}.

:padded cell: n. Where you put {luser}s so they can't hurt anything. A program that limits a luser to a carefully restricted subset of the capabilities of the host system (for example, the `rsh(1)' utility on USG UNIX). Note that this is different from an {iron box} because it is overt and not aimed at enforcing security so much as protecting others (and the luser) from the consequences of the luser's boundless na"ivet'e (see {na"ive}). Also `padded cell environment'.

:page in: [MIT] vi. 1. To become aware of one's surroundings again after having paged out (see {page out}). Usually confined to the sarcastic comment: "Eric pages in. Film at 11." See {film at 11}. 2. Syn. `swap in'; see {swap}.

:page out: [MIT] vi. 1. 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}. Compare {glitch}, {thinko}. 2. Syn. `swap out'; see {swap}.

:pain in the net: n. A {flamer}.

:paper-net: n. Hackish way of referring to the postal service, analogizing it to a very slow, low-reliability network. USENET {sig block}s not uncommonly include a "Paper-Net:" header just before the sender's postal address; common variants of this are "Papernet" and "P-Net". Compare {voice-net}, {snail-mail}.

:param: /p*-ram'/ n. Shorthand for `parameter'. See also {parm}; compare {arg}, {var}.

:PARC: n. See {XEROX PARC}.

:parent message: n. See {followup}.

:parity errors: pl.n. 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." Derives from a relatively common but nearly always correctable transient error in RAM hardware.

:Parkinson's Law of Data: prov. "Data expands to fill the space available for storage"; buying more memory encourages the use of more memory-intensive techniques. It has been observed over the last 10 years that the memory usage of evolving systems tends to double roughly once every 18 months. Fortunately, memory density available for constant dollars tends to double about once every 12 months (see {Moore's Law}); unfortunately, the laws of physics guarantee that the latter cannot continue indefinitely.

:parm: /parm/ n. Further-compressed form of {param}. This term is an IBMism, and written use is almost unknown outside IBM shops; spoken /parm/ is more widely distributed, but the synonym {arg} is favored among hackers. Compare {arg}, {var}.

:parse: [from linguistic terminology] vt. 1. To determine the syntactic structure of a sentence or other utterance (close to the standard English meaning). "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. "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'.

:Pascal:: n. An Algol-descended language designed by Niklaus Wirth on the CDC 6600 around 1967--68 as an instructional tool for elementary programming. This language, designed primarily to keep students from shooting themselves in the foot and thus extremely restrictive from a general-purpose-programming point of view, was later promoted as a general-purpose tool and, in fact, became the ancestor of a large family of languages including Modula-2 and {{Ada}} (see also {bondage-and-discipline language}). The hackish point of view on Pascal was probably best summed up by a devastating (and, in its deadpan way, screamingly funny) 1981 paper by Brian Kernighan (of {K&R} fame) entitled "Why Pascal is Not My Favorite Programming Language", which was turned down by the technical journals but circulated widely via photocopies. It was eventually published in "Comparing and Assessing Programming Languages", edited by Alan Feuer and Narain Gehani (Prentice-Hall, 1984). Part of his discussion is worth repeating here, because its criticisms are still apposite to Pascal itself after ten years of improvement and could also stand as an indictment of many other bondage-and-discipline languages. At the end of a summary of the case against Pascal, Kernighan wrote:

9. There is no escape

This last point is perhaps the most important. The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to replace the defective run-time environment with a sensible one, unless one controls the compiler that defines the "standard procedures". The language is closed.

People who use Pascal for serious programming fall into a fatal trap. Because the language is impotent, it must be extended. But each group extends Pascal in its own direction, to make it look like whatever language they really want. Extensions for separate compilation, FORTRAN-like COMMON, string data types, internal static variables, initialization, octal numbers, bit operators, etc., all add to the utility of the language for one group but destroy its portability to others.

I feel that it is a mistake to use Pascal for anything much beyond its original target. In its pure form, Pascal is a toy language, suitable for teaching but not for real programming.

Pascal has since been almost entirely displaced (by {C}) from the niches it had acquired in serious applications and systems programming, but retains some popularity as a hobbyist language in the MS-DOS and Macintosh worlds.

:pastie: /pay'stee/ n. An adhesive-backed label designed to be attached to a key on a keyboard to indicate some non-standard character which can be accessed through that key. Pasties are likely to be used in APL environments, where almost every key is associated with a special character. A pastie on the R key, for example, would remind the user that it is used to generate the rho character. The term properly refers to nipple-concealing devices formerly worn by strippers in concession to indecent-exposure laws; compare {tits on a keyboard}.

: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. Distinguished from a {diff} or {mod} by the fact that a patch is generated by more primitive means than the rest of the program; the classical examples are instructions modified by using the front panel switches, and changes made directly to the binary executable of a program originally written in an {HLL}. Compare {one-line fix}. 2. vt. To insert a patch into a piece of code. 3. [in the UNIX world] n. A {diff} (sense 2). 4. A set of modifications to binaries to be applied by a patching program. IBM operating systems often receive updates to the operating system in the form of absolute hexadecimal patches. If you have modified your OS, you have to disassemble these back to the source. The patches might later be corrected by other patches on top of them (patches were said to "grow scar tissue"). The result was often a convoluted {patch space} and headaches galore. 5. [UNIX] the `patch(1)' program, written by Larry Wall, which automatically applies a patch (sense 3) to a set of source code.

There is a classic story of a {tiger team} penetrating a secure military computer that illustrates the danger inherent in binary patches (or, indeed, any that you can't --- or don't --- inspect and examine before installing). They couldn't find any {trap door}s or any way to penetrate security of IBM's OS, so they made a site visit to an IBM office (remember, these were official military types who were purportedly on official business), swiped some IBM stationery, and created a fake patch. The patch was actually the trapdoor they needed. The patch was distributed at about the right time for an IBM patch, had official stationery and all accompanying documentation, and was dutifully installed. The installation manager very shortly thereafter learned something about proper procedures.

:patch space: n. An unused block of bits left in a binary so that it can later be modified by insertion of machine-language instructions there (typically, the patch space is modified to contain new code, and the superseded code is patched to contain a jump or call to the patch space). The widening use of HLLs has made this term rare; it is now primarily historical outside IBM shops. See {patch} (sense 4), {zap} (sense 4), {hook}.

:path: n. 1. A {bang path} or explicitly routed {{Internet address}}; a node-by-node specification of a link between two machines. 2. [UNIX] A filename, fully specified relative to the root directory (as opposed to relative to the current directory; the latter is sometimes called a `relative path'). This is also called a `pathname'. 3. [UNIX and MS-DOS] The `search path', an environment variable specifying the directories in which the {shell} (COMMAND.COM, under MS-DOS) should look for commands. Other, similar constructs abound under UNIX (for example, the C preprocessor has a `search path' it uses in looking for `#include' files).

:pathological: adj. 1. [scientific computation] Used of a data set that is grossly atypical of normal expected input, esp. one that exposes a weakness or bug in whatever algorithm one is using. An algorithm that can be broken by pathological inputs may still be useful if such inputs are very unlikely to occur in practice. 2. When used of test input, implies that it was purposefully engineered as a worst case. The implication in both senses is that the data is spectacularly ill-conditioned or that someone had to explicitly set out to break the algorithm in order to come up with such a crazy example. 3. Also said of an unlikely collection of circumstances. "If the network is down and comes up halfway through the execution of that command by root, the system may just crash." "Yes, but that's a pathological case." Often used to dismiss the case from discussion, with the implication that the consequences are acceptable since that they will happen so infrequently (if at all) that there is no justification for going to extra trouble to handle that case (see sense 1).

:payware: /pay'weir/ n. Commercial software. Oppose {shareware} or {freeware}.

:PBD: /P-B-D/ [abbrev. of `Programmer Brain Damage'] n. Applied to bug reports revealing places where the program was obviously broken by an incompetent or short-sighted programmer. Compare {UBD}; see also {brain-damaged}.

:PC-ism: /P-C-izm/ n. A piece of code or coding technique that takes advantage of the unprotected single-tasking environment in IBM PCs and the like, e.g., by busy-waiting on a hardware register, direct diddling of screen memory, or using hard timing loops. Compare {ill-behaved}, {vaxism}, {unixism}. Also, `PC-ware' n., a program full of PC-isms on a machine with a more capable operating system. Pejorative.

:PD: /P-D/ 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 /puhd'l/ [abbreviation for `Push Down List'] 1. n. In ITS days, the preferred MITism for {stack}. See {overflow pdl}. 2. n. Dave Lebling, one of the co-authors of {Zork}; (his {network address} on the ITS machines was at one time pdl@dms). 3. n. `Program Design Language'. Any of a large class of formal and profoundly useless pseudo-languages in which {management} forces one to design programs. {Management} often expects it to be maintained in parallel with the code. See also {{flowchart}}. 4. v. To design using a program design language. "I've been pdling so long my eyes won't focus beyond 2 feet." 5. n. `Page Description Language'. Refers to any language which is used to control a graphics device, usually a laserprinter. The most common example, is of course, Adobe's {PostScript} language, but there are many others, such as Xerox InterPress, etc.

:PDP-10: [Programmed Data Processor model 10] n. The machine that made timesharing real. It looms large in hacker folklore because of its adoption in the mid-1970s 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 VAX machines (descendants of the PDP-11) when DEC recognized that the 10 and VAX product lines were competing with each other and decided to concentrate its software development effort on the more profitable VAX. The machine was finally dropped from DEC's line in 1983, following the failure of the Jupiter Project at DEC to build a viable new model. (Some attempts by other companies to market clones came to nothing; see {Foonly}) This event spelled the doom of {{ITS}} and the technical cultures that had spawned the original Jargon File, but by mid-1991 it had become something of a badge of honorable old-timerhood among hackers to have cut one's teeth on a PDP-10. See {{TOPS-10}}, {{ITS}}, {AOS}, {BLT}, {DDT}, {DPB}, {EXCH}, {HAKMEM}, {JFCL}, {LDB}, {pop}, {push}, {appendix A}.

:PDP-20: n. The most famous computer that never was. {PDP-10} computers running the {{TOPS-10}} operating system were labeled `DECsystem-10' as a way of differentiating them from the PDP-11. Later on, those systems running {TOPS-20} were labeled `DECSYSTEM-20' (the block capitals being the result of a lawsuit brought against DEC by Singer, which once made a computer called `system-10'), but contrary to popular lore there was never a `PDP-20'; the only difference between a 10 and a 20 was the operating system and the color of the paint. Most (but not all) machines sold to run TOPS-10 were painted `Basil Blue', whereas most TOPS-20 machines were painted `Chinese Red' (often mistakenly called orange).

:peek: n.,vt. (and {poke}) The commands in most microcomputer BASICs for directly accessing memory contents at an absolute address; often extended to mean the corresponding constructs in any {HLL} (peek reads memory, poke modifies it). Much hacking on small, non-MMU micros consists of `peek'ing around memory, more or less at random, to find the location where the system keeps interesting stuff. Long (and variably accurate) lists of such addresses for various computers circulate (see {{interrupt list, the}}). The results of `poke's at these addresses may be highly useful, mildly amusing, useless but neat, or (most likely) total {lossage} (see {killer poke}).

Since a {real operating system} provides useful, higher-level services for the tasks commonly performed with peeks and pokes on micros, and real languages tend not to encourage low-level memory groveling, a question like "How do I do a peek in C?" is diagnostic of the {newbie}. (Of course, OS kernels often have to do exactly this; a real C hacker would unhesitatingly, if unportably, assign an absolute address to a pointer variable and indirect through it.)

:pencil and paper: n. An archaic information storage and transmission device that works by depositing smears of graphite on bleached wood pulp. More recent developments in paper-based technology include improved `write-once' update devices which use tiny rolling heads similar to mouse balls to deposit colored pigment. All these devices require an operator skilled at so-called `handwriting' technique. These technologies are ubiquitous outside hackerdom, but nearly forgotten inside it. Most hackers had terrible handwriting to begin with, and years of keyboarding tend to have encouraged it to degrade further. Perhaps for this reason, hackers deprecate pencil-and-paper technology and often resist using it in any but the most trivial contexts. See also {appendix B}.

:peon: n. A person with no special ({root} or {wheel}) privileges on a computer system. "I can't create an account on *foovax* for you; I'm only a peon there."

:percent-S: /per-sent' es'/ [From the code in C's `printf(3)' library function used to insert an arbitrary string argument] 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). The term `perfory' /per'f*-ree/ is also heard. The term {perf} may also refer to the preforations themselves, rather than the chad they produce when torn.

:perfect programmer syndrome: n. Arrogance; the egotistical conviction that one is above normal human error. Most frequently found among programmers of some native ability but relatively little experience (especially new graduates; their perceptions may be distorted by a history of excellent performance at solving {toy problem}s). "Of course my program is correct, there is no need to test it." "Yes, I can see there may be a problem here, but *I'll* never type `rm -r /' while in {root}."

:Perl: /perl/ [Practical Extraction and Report Language, a.k.a Pathologically Eclectic Rubbish Lister] n. An interpreted language developed by Larry Wall <[email protected]>, author of `patch(1)' and `rn(1)') and distributed over USENET. Superficially resembles `awk(1)', but is much hairier (see {awk}). UNIX sysadmins, who are almost always incorrigible hackers, increasingly consider it one of the {languages of choice}. Perl has been described, in a parody of a famous remark about `lex(1)', as the "Swiss-Army chainsaw" of UNIX programming.

:pessimal: /pes'im-l/ [Latin-based antonym for `optimal'] adj. Maximally bad. "This is a pessimal situation." Also `pessimize' vt. To make as bad as possible. These words are the obvious Latin-based antonyms for `optimal' and `optimize', but for some reason they do not appear in most English dictionaries, although `pessimize' is listed in the OED.

:pessimizing compiler: /pes'*-mi:z`ing k*m-pi:l'r/ [antonym of `optimizing compiler'] n. A compiler that produces object code that is worse than the straightforward or obvious hand translation. The implication is that the compiler is actually trying to optimize the program, but through excessive cleverness is doing the opposite. A few pessimizing compilers have been written on purpose, however, as pranks or burlesques.

:peta-: /pe't*/ [SI] pref. See {{quantifiers}}.

:PETSCII: /pet'skee/ [abbreviation of PET ASCII] n. The variation (many would say perversion) of the {{ASCII}} character set used by the Commodore Business Machines PET series of personal computers and the later Commodore C64, C16, and C128 machines. The PETSCII set used left-arrow and up-arrow (as in old-style ASCII) instead of underscore and caret, placed the unshifted alphabet at positions 65--90, put the shifted alphabet at positions 193--218, and added graphics characters.

: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 and/or according to no fixed schedule. It is not uncommon to change one's phase by as much as 6 hours per day on a regular basis. "What's your phase?" "I've been getting in about 8 P.M. lately, but I'm going to {wrap 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 (but less frequently) used, meaning you're working 9 to 5 (or, more likely, 10 to 6).) The act of altering one's cycle is called `changing phase'; `phase shifting' has also been recently reported from Caltech. 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. However, some claim that either staying awake longer or sleeping longer is easy, and that it is *shortening* your day or night that's hard (see {wrap around}). The `jet lag' that afflicts travelers who cross many time-zone boundaries may be attributed to two distinct causes: the strain of travel per se, and the strain of changing phase. Hackers who suddenly find that they must change phase drastically in a short period of time, particularly the hard way, experience something very like jet lag without traveling.

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

True story: Once upon a time there was a bug that really did depend on the phase of the moon. There is a little subroutine that had traditionally been used in various programs at MIT to calculate an approximation to the moon's true phase. GLS incorporated this routine into a LISP program that, when it wrote out a file, would print a timestamp line almost 80 characters long. Very occasionally the first line of the message would be too long and would overflow onto the next line, and when the file was later read back in the program would {barf}. The length of the first line depended on both the precise date and time and the length of the phase specification when the timestamp was printed, and so the bug literally depended on the phase of the moon!

The first paper edition of the Jargon File (Steele-1983) included an example of one of the timestamp lines that exhibited this bug, but the typesetter `corrected' it. This has since been described as the phase-of-the-moon-bug bug.

:phase-wrapping: [MIT] n. Syn. {wrap around}, sense 2.

:phreaking: /freek'ing/ [from `phone phreak'] n. 1. The art and science of cracking the phone network (so as, for example, to make free long-distance calls). 2. By extension, security-cracking in any other context (especially, but not exclusively, on communications networks) (see {cracking}).