The Hacker's Dictionary, - [best reads of all time .txt] 📗

a non-UNIX system so that it will interoperate with UNIX systems. The hack may qualify as `UNIX brain damage' if the program conforms to published standards and the UNIX program in question does not. UNIX brain damage happens because it is much easier for other (minority) systems to change their ways to match non-conforming behavior than it is to change all the hundreds of thousands of UNIX systems out there.

An example of UNIX brain damage is a {kluge} in a mail server to recognize bare line feed (the UNIX newline) as an equivalent form to the Internet standard newline, which is a carriage return followed by a line feed. Such things can make even a hardened {jock} weep.

:UNIX conspiracy: [ITS] n. According to a conspiracy theory long popular among {{ITS}} and {{TOPS-20}} fans, UNIX's growth is the result of a plot, hatched during the 1970s at Bell Labs, whose intent was to hobble AT&T's competitors by making them dependent upon a system whose future evolution was to be under AT&T's control. This would be accomplished by disseminating an operating system that is apparently inexpensive and easily portable, but also relatively unreliable and insecure (so as to require continuing upgrades from AT&T). This theory was lent a substantial impetus in 1984 by the paper referenced in the {back door} entry.

In this view, UNIX was designed to be one of the first computer viruses (see {virus}) --- but a virus spread to computers indirectly by people and market forces, rather than directly through disks and networks. Adherents of this `UNIX virus' theory like to cite the fact that the well-known quotation "UNIX is snake oil" was uttered by DEC president Kenneth Olsen shortly before DEC began actively promoting its own family of UNIX workstations. (Olsen now claims to have been misquoted.)

:UNIX weenie: [ITS] n. 1. A derogatory play on `UNIX wizard', common among hackers who use UNIX by necessity but would prefer alternatives. The implication is that although the person in question may consider mastery of UNIX arcana to be a wizardly skill, the only real skill involved is the ability to tolerate (and the bad taste to wallow in) the incoherence and needless complexity that is alleged to infest many UNIX programs. "This shell script tries to parse its arguments in 69 bletcherous ways. It must have been written by a real UNIX weenie." 2. A derogatory term for anyone who engages in uncritical praise of UNIX. Often appearing in the context "stupid UNIX weenie". See {Weenix}, {UNIX

conspiracy}. See also {weenie}.

:unixism: n. A piece of code or a coding technique that depends on the protected multi-tasking environment with relatively low process-spawn overhead that exists on virtual-memory UNIX systems.

Common {unixism}s include: gratuitous use of fork(2)'; the assumption that certain undocumented but well-known features of UNIX libraries such asstdio(3)' are supported elsewhere; reliance on {obscure} side-effects of system calls (use of sleep(2)' with a 0 argument to clue the scheduler that you're willing to give up your time-slice, for example); the assumption that freshly allocated memory is zeroed; and the assumption that fragmentation problems won't arise from neverfree()'ing memory. Compare {vaxocentrism}; see also {New Jersey}.

:unleaded: adj. Said of decaffeinated coffee, diet coke, and other imitation {programming fluid}s. "Do you want regular or unleaded?". Appears to be widespread among programmers associated with the oil industry in Texas (and probably elsewhere). Usage: silly, and probably unintelligable to the next generation of hackers.

:unroll: v. To repeat the body of a loop several times in succession.

This optimization technique reduces the number of times the loop-termination test has to be executed. But it only works if the number of iterations desired is a multiple of the number of repetitions of the body. Something has to be done to take care of any leftover iterations --- such as {Duff's device}.

:unswizzle: v. See {swizzle}.

:unwind the stack: vi. 1. [techspeak] During the execution of a procedural language, one is said to unwind the stack' from a called procedure up to a caller when one discards the stack frame and any number of frames above it, popping back up to the level of the given caller. In C this is done withlongjmp'/setjmp', in LISP withthrow/catch'.

See also {smash the stack}. 2. People can unwind the stack as well, by quickly dealing with a bunch of problems: "Oh heck, let's do lunch. Just a second while I unwind my stack."

:unwind-protect: [MIT: from the name of a LISP operator] n. A task you must remember to perform before you leave a place or finish a project. "I have an unwind-protect to call my advisor."

:up: adj. 1. Working, in order. "The down escalator is up."

Oppose {down}. 2. `bring up': vt. To create a working version and start it. "They brought up a down system."

`come up' vi. To become ready for production use.

:upload: /uhp'lohd/ v. 1. [techspeak] To transfer programs or data over a digital communications link from a smaller or peripheral client' system to a larger or centralhost' one. A transfer in the other direction is, of course, called a {download} (but see the note about ground-to-space comm under that entry).

[speculatively] To move the essential patterns and algorithms that make up one's mind from one's brain into a computer. Only those who are convinced that such patterns and algorithms capture the complete essence of the self view this prospect with gusto.

:upthread: adv. Earlier in the discussion (see {thread}), i.e., `above'. "As Joe pointed out upthread, ..." See also {followup}.

:urchin: n. See {munchkin}.

:USENET: /yoos'net/ or /yooz'net/ [from `Users' Network'] n.

A distributed {bboard} (bulletin board) system supported mainly by UNIX machines. Originally implemented in 1979-1980 by Steve Bellovin, Jim Ellis, Tom Truscott, and Steve Daniel at Duke University, it has swiftly grown to become international in scope and is now probably the largest decentralized information utility in existence. As of early 1991, it hosts well over 700 {newsgroup}s and an average of 16 megabytes (the equivalent of several thousand paper pages) of new technical articles, news, discussion, chatter, and {flamage} every day.

:user: n. 1. Someone doing `real work' with the computer, using it as a means rather than an end. Someone who pays to use a computer. See {real user}. 2. A programmer who will believe anything you tell him. One who asks silly questions. [GLS

observes: This is slightly unfair. It is true that users ask questions (of necessity). Sometimes they are thoughtful or deep.

Very often they are annoying or downright stupid, apparently because the user failed to think for two seconds or look in the documentation before bothering the maintainer.] See {luser}.

Someone who uses a program from the outside, however skillfully, without getting into the internals of the program. One who reports bugs instead of just going ahead and fixing them.

The general theory behind this term is that there are two classes of people who work with a program: there are implementors (hackers) and {luser}s. The users are looked down on by hackers to some extent because they don't understand the full ramifications of the system in all its glory. (The few users who do are known as `real winners'.) The term is a relative one: a skilled hacker may be a user with respect to some program he himself does not hack. A LISP hacker might be one who maintains LISP or one who uses LISP (but with the skill of a hacker). A LISP user is one who uses LISP, whether skillfully or not. Thus there is some overlap between the two terms; the subtle distinctions must be resolved by context.

:user-friendly: adj. Programmer-hostile. Generally used by hackers in a critical tone, to describe systems that hold the user's hand so obsessively that they make it painful for the more experienced and knowledgeable to get any work done. See {menuitis}, {drool-proof paper}, {Macintrash}, {user-obsequious}.

:user-obsequious: adj. Emphatic form of {user-friendly}. Connotes a system so verbose, inflexible, and determinedly simple-minded that it is nearly unusable. "Design a system any fool can use and only a fool will want to use it." See {WIMP environment}, {Macintrash}.

:USG UNIX: /U-S-G yoo'niks/ n. Refers to AT&T UNIX

commercial versions after {Version 7}, especially System III and System V releases 1, 2, and 3. So called because during most of the life-span of those versions AT&T's support crew was called the `UNIX Support Group'. See {BSD}, {{UNIX}}.

:UTSL: // [UNIX] n. On-line acronym for Use the Source, Luke' (a pun on Obi-Wan Kenobi's "Use the Force, Luke!" inStar Wars') --- analogous to {RTFM} but more polite. This is a common way of suggesting that someone would be best off reading the source code that supports whatever feature is causing confusion, rather than making yet another futile pass through the manuals or broadcasting questions that haven't attracted {wizard}s to answer them. In theory, this is appropriately directed only at associates of some outfit with a UNIX source license; in practice, bootlegs of UNIX source code (made precisely for reference purposes) are so ubiquitous that one may utter this at almost anyone on the network without concern. In the near future (this written in 1991) source licenses may become even less important; after the recent release of the Mach 3.0 microkernel, given the continuing efforts of the {GNU} project, and with