Some people are confused over whether this word is appropriately `UNIX' or `Unix'; both forms are common, and used interchangeably. Dennis Ritchie says that the `UNIX' spelling originally happened in CACM's 1974 paper "The UNIX Time-Sharing System" because "we had a new typesetter and {troff} had just been invented and we were intoxicated by being able to produce small caps." Later, dmr tried to get the spelling changed to `Unix' in a couple of Bell Labs papers, on the grounds that the word is not acronymic. He failed, and eventually (his words) "wimped out" on the issue. So, while the trademark today is `UNIX', both capitalizations are grounded in ancient usage; the Jargon File uses `Unix' in deference to dmr's wishes.
:Unix brain damage: /n./ Something that has to be done to break a network program (typically a mailer) on 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: /n./ [ITS] 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.)
[If there was ever such a conspiracy, it got thoroughly out of the plotters' control after 1990. AT&T sold its UNIX operation to Novell around the same time {Linux} and other free-UNIX distributions were beginning to make noise. —ESR]
:Unix weenie: /n./ [ITS] 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 as `stdio(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 never `free()'ing memory. Compare {vaxocentrism}; see also {New Jersey}.
: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 with `longjmp'/`setjmp', in LISP with `throw/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."