Chapter 6

:bondage-and-discipline language: /n./ A language (such as {{Pascal}}, {{Ada}}, APL, or Prolog) that, though ostensibly general-purpose, is designed so as to enforce an author's theory of `right programming' even though said theory is demonstrably inadequate for systems hacking or even vanilla general-purpose programming. Often abbreviated `B&D'; thus, one may speak of things "having the B&D nature". See {{Pascal}}; oppose {languages of choice}.

:bonk/oif: /bonk/, /oyf/ /interj./ In the {MUD} community, it has become traditional to express pique or censure by `bonking' the offending person. Convention holds that one should acknowledge a bonk by saying `oif!' and there is a myth to the effect that failing to do so upsets the cosmic bonk/oif balance, causing much trouble in the universe. Some MUDs have implemented special commands for bonking and oifing. See also {talk mode}.

:book titles:: There is a tradition in hackerdom of informally tagging important textbooks and standards documents with the dominant color of their covers or with some other conspicuous feature of the cover. Many of these are described in this lexicon under their own entries. See {Aluminum Book}, {Blue Book}, {Camel Book}, {Cinderella Book}, {Devil Book}, {Dragon Book}, {Green Book}, {Orange Book}, {Pink-Shirt Book}, {Purple Book}, {Red Book}, {Silver Book}, {White Book}, {Wizard Book}, {Yellow Book}, and {bible}; see also {rainbow series}. Since about 1983 this tradition has gotten a boost from the popular O'Reilly Associates line of technical books, which usually feature some kind of exotic animal on the cover.

:boot: /v.,n./ [techspeak; from `by one's bootstraps'] To load and initialize the operating system on a machine. This usage is no longer jargon (having passed into techspeak) but has given rise to some derivatives that are still jargon.

The derivative `reboot' implies that the machine hasn't been down for long, or that the boot is a {bounce} (sense 4) intended to clear some state of {wedgitude}. This is sometimes used of human thought processes, as in the following exchange: "You've lost me." "OK, reboot. Here's the theory...."

This term is also found in the variants `cold boot' (from power-off condition) and `warm boot' (with the CPU and all devices already powered up, as after a hardware reset or software crash).

Another variant: `soft boot', reinitialization of only part of a system, under control of other software still running: "If you're running the {mess-dos} emulator, control-alt-insert will cause a soft-boot of the emulator, while leaving the rest of the system running."

Opposed to this there is `hard boot', which connotes hostility towards or frustration with the machine being booted: "I'll have to hard-boot this losing Sun." "I recommend booting it hard." One often hard-boots by performing a {power cycle}.

Historical note: this term derives from `bootstrap loader', a short program that was read in from cards or paper tape, or toggled in from the front panel switches. This program was always very short (great efforts were expended on making it short in order to minimize the labor and chance of error involved in toggling it in), but was just smart enough to read in a slightly more complex program (usually from a card or paper tape reader), to which it handed control; this program in turn was smart enough to read the application or operating system from a magnetic tape drive or disk drive. Thus, in successive steps, the computer `pulled itself up by its bootstraps' to a useful operating state. Nowadays the bootstrap is usually found in ROM or EPROM, and reads the first stage in from a fixed location on the disk, called the `boot block'. When this program gains control, it is powerful enough to load the actual OS and hand control over to it.

:bottom feeder: /n./ Syn. for {slopsucker}, derived from the fishermen's and naturalists' term for finny creatures who subsist on the primordial ooze.

:bottom-up implementation: /n./ Hackish opposite of the techspeak term `top-down design'. It is now received wisdom in most programming cultures that it is best to design from higher levels of abstraction down to lower, specifying sequences of action in increasing detail until you get to actual code. Hackers often find (especially in exploratory designs that cannot be closely specified in advance) that it works best to *build* things in the opposite order, by writing and testing a clean set of primitive operations and then knitting them together.

:bounce: /v./ 1. [perhaps by analogy to a bouncing check] An electronic mail message that is undeliverable and returns an error notification to the sender is said to `bounce'. See also {bounce message}. 2. [Stanford] To play volleyball. The now-demolished {D. C. Power Lab} building used by the Stanford AI Lab in the 1970s had a volleyball court on the front lawn. From 5 P.M. to 7 P.M. was the scheduled maintenance time for the computer, so every afternoon at 5 would come over the intercom the cry: "Now hear this: bounce, bounce!", followed by Brian McCune loudly bouncing a volleyball on the floor outside the offices of known volleyballers. 3. To engage in sexual intercourse; prob. from the expression `bouncing the mattress', but influenced by Roo's psychosexually loaded "Try bouncing me, Tigger!" from the "Winnie-the-Pooh" books. Compare {boink}. 4. To casually reboot a system in order to clear up a transient problem. Reported primarily among {VMS} users. 5. [VM/CMS programmers] *Automatic* warm-start of a machine after an error. "I logged on this morning and found it had bounced 7 times during the night" 6. [IBM] To {power cycle} a peripheral in order to reset it.

:bounce message: /n./ [Unix] Notification message returned to sender by a site unable to relay {email} to the intended {{Internet address}} recipient or the next link in a {bang path} (see {bounce}, sense 1). Reasons might include a nonexistent or misspelled username or a {down} relay site. Bounce messages can themselves fail, with occasionally ugly results; see {sorcerer's apprentice mode} and {software laser}. The terms `bounce mail' and `barfmail' are also common.

:boustrophedon: /n./ [from a Greek word for turning like an ox while plowing] An ancient method of writing using alternate left-to-right and right-to-left lines. This term is actually philologists' techspeak and typesetters' jargon. Erudite hackers use it for an optimization performed by some computer typesetting software and moving-head printers. The adverbial form `boustrophedonically' is also found (hackers purely love constructions like this).

:box: /n./ 1. A computer; esp. in the construction `foo box' where foo is some functional qualifier, like `graphics', or the name of an OS (thus, `Unix box', `MS-DOS box', etc.) "We preprocess the data on Unix boxes before handing it up to the mainframe." 2. [IBM] Without qualification but within an SNA-using site, this refers specifically to an IBM front-end processor or FEP /F-E-P/. An FEP is a small computer necessary to enable an IBM {mainframe} to communicate beyond the limits of the {dinosaur pen}. Typically used in expressions like the cry that goes up when an SNA network goes down: "Looks like the {box} has fallen over." (See {fall over}.) See also {IBM}, {fear and loathing}, {fepped out}, {Blue Glue}.

:boxed comments: /n./ Comments (explanatory notes attached to program instructions) that occupy several lines by themselves; so called because in assembler and C code they are often surrounded by a box in a style something like this:

/************************************************* * * This is a boxed comment in C style * *************************************************/

Common variants of this style omit the asterisks in column 2 or add a matching row of asterisks closing the right side of the box. The sparest variant omits all but the comment delimiters themselves; the `box' is implied. Oppose {winged comments}.

:boxen: /bok'sn/ /pl.n./ [by analogy with {VAXen}] Fanciful plural of {box} often encountered in the phrase `Unix boxen', used to describe commodity {{Unix}} hardware. The connotation is that any two Unix boxen are interchangeable.

:boxology: /bok-sol'*-jee/ /n./ Syn. {ASCII art}. This term implies a more restricted domain, that of box-and-arrow drawings. "His report has a lot of boxology in it." Compare {macrology}.

:bozotic: /boh-zoh'tik/ or /boh-zo'tik/ /adj./ [from the name of a TV clown even more losing than Ronald McDonald] Resembling or having the quality of a bozo; that is, clownish, ludicrously wrong, unintentionally humorous. Compare {wonky}, {demented}. Note that the noun `bozo' occurs in slang, but the mainstream adjectival form would be `bozo-like' or (in New England) `bozoish'.

:BQS: /B-Q-S/ /adj./ Syn. {Berkeley Quality Software}.

:brain dump: /n./ The act of telling someone everything one knows about a particular topic or project. Typically used when someone is going to let a new party maintain a piece of code. Conceptually analogous to an operating system {core dump} in that it saves a lot of useful {state} before an exit. "You'll have to give me a brain dump on FOOBAR before you start your new job at HackerCorp." See {core dump} (sense 4). At Sun, this is also known as `TOI' (transfer of information).

:brain fart: /n./ The actual result of a {braino}, as opposed to the mental glitch that is the braino itself. E.g., typing `dir' on a Unix box after a session with DOS.

:brain-damaged: /adj./ 1. [generalization of `Honeywell Brain Damage' (HBD), a theoretical disease invented to explain certain utter cretinisms in Honeywell {{Multics}}] /adj./ Obviously wrong; {cretinous}; {demented}. There is an implication that the person responsible must have suffered brain damage, because he should have known better. Calling something brain-damaged is really bad; it also implies it is unusable, and that its failure to work is due to poor design rather than some accident. "Only six monocase characters per file name? Now *that's* brain-damaged!" 2. [esp. in the Mac world] May refer to free demonstration software that has been deliberately crippled in some way so as not to compete with the commercial product it is intended to sell. Syn. {crippleware}.

:brain-dead: /adj./ Brain-damaged in the extreme. It tends to imply terminal design failure rather than malfunction or simple stupidity. "This comm program doesn't know how to send a break -- how brain-dead!"

:braino: /bray'no/ /n./ Syn. for {thinko}. See also {brain fart}.

:branch to Fishkill: /n./ [IBM: from the location of one of the corporation's facilities] Any unexpected jump in a program that produces catastrophic or just plain weird results. See {jump off into never-never land}, {hyperspace}.

:bread crumbs: /n./ Debugging statements inserted into a program that emit output or log indicators of the program's {state} to a file so you can see where it dies or pin down the cause of surprising behavior. The term is probably a reference to the Hansel and Gretel story from the Brothers Grimm; in several variants, a character leaves a trail of bread crumbs so as not to get lost in the woods.

:break: 1. /vt./ To cause to be {broken} (in any sense). "Your latest patch to the editor broke the paragraph commands." 2. /v./ (of a program) To stop temporarily, so that it may debugged. The place where it stops is a `breakpoint'. 3. [techspeak] /vi./ To send an RS-232 break (two character widths of line high) over a serial comm line. 4. [Unix] /vi./ To strike whatever key currently causes the tty driver to send SIGINT to the current process. Normally, break (sense 3), delete or {control-C} does this. 5. `break break' may be said to interrupt a conversation (this is an example of verb doubling). This usage comes from radio communications, which in turn probably came from landline telegraph/teleprinter usage, as badly abused in the Citizen's Band craze a few years ago.

:break-even point: /n./ In the process of implementing a new computer language, the point at which the language is sufficiently effective that one can implement the language in itself. That is, for a new language called, hypothetically, FOOGOL, one has reached break-even when one can write a demonstration compiler for FOOGOL in FOOGOL, discard the original implementation language, and thereafter use working versions of FOOGOL to develop newer ones. This is an important milestone; see {MFTL}.

Since this entry was first written, several correspondents have reported that there actually was a compiler for a tiny Algol-like language called Foogol floating around on various {VAXen} in the early and mid-1980s. A FOOGOL implementation is available at the Retrocomputing Museum http://www.ccil.org/retro.

:breath-of-life packet: /n./ [XEROX PARC] An Ethernet packet that contains bootstrap (see {boot}) code, periodically sent out from a working computer to infuse the `breath of life' into any computer on the network that has happened to crash. Machines depending on such packets have sufficient hardware or firmware code to wait for (or request) such a packet during the reboot process. See also {dickless workstation}.

The notional `kiss-of-death packet', with a function complementary to that of a breath-of-life packet, is recommended for dealing with hosts that consume too many network resources. Though `kiss-of-death packet' is usually used in jest, there is at least one documented instance of an Internet subnet with limited address-table slots in a gateway machine in which such packets were routinely used to compete for slots, rather like Christmas shoppers competing for scarce parking spaces.

:breedle: /n./ See {feep}.

:bring X to its knees: /v./ To present a machine, operating system, piece of software, or algorithm with a load so extreme or {pathological} that it grinds to a halt. "To bring a MicroVAX to its knees, try twenty users running {vi} -- or four running {EMACS}." Compare {hog}.

:brittle: /adj./ Said of software that is functional but easily broken by changes in operating environment or configuration, or by any minor tweak to the software itself. Also, any system that responds inappropriately and disastrously to abnormal but expected external stimuli; e.g., a file system that is usually totally scrambled by a power failure is said to be brittle. This term is often used to describe the results of a research effort that were never intended to be robust, but it can be applied to commercially developed software, which displays the quality far more often than it ought to. Oppose {robust}.

:broadcast storm: /n./ An incorrect packet broadcast on a network that causes most hosts to respond all at once, typically with wrong answers that start the process over again. See {network meltdown}; compare {mail storm}.

:brochureware: /n./ Planned but non-existent product like {vaporware}, but with the added implication that marketing is actively selling and promoting it (they've printed brochures). Brochureware is often deployed as a strategic weapon; the idea is to con customers into not committing to an existing product of the competition's. It is a safe bet that when a brochureware product finally becomes real, it will be more expensive than and inferior to the alternatives that had been available for years.

:broken: /adj./ 1. Not working properly (of programs). 2. Behaving strangely; especially (when used of people) exhibiting extreme depression.

:broken arrow: /n./ [IBM] The error code displayed on line 25 of a 3270 terminal (or a PC emulating a 3270) for various kinds of protocol violations and "unexpected" error conditions (including connection to a {down} computer). On a PC, simulated with `->/_', with the two center characters overstruck.

Note: to appreciate this term fully, it helps to know that `broken arrow' is also military jargon for an accident involving nuclear weapons....

:BrokenWindows: /n./ Abusive hackerism for the {crufty} and {elephantine} {X} environment on Sun machines; properly called `OpenWindows'.

:broket: /broh'k*t/ or /broh'ket`/ /n./ [by analogy with `bracket': a `broken bracket'] Either of the characters `<' and `>', when used as paired enclosing delimiters. This word originated as a contraction of the phrase `broken bracket', that is, a bracket that is bent in the middle. (At MIT, and apparently in the {Real World} as well, these are usually called {angle brackets}.)

:Brooks's Law: /prov./ "Adding manpower to a late software project makes it later" -- a result of the fact that the expected advantage from splitting work among N programmers is O(N) (that is, proportional to N), but the complexity and communications cost associated with coordinating and then merging their work is O(N^2) (that is, proportional to the square of N). The quote is from Fred Brooks, a manager of IBM's OS/360 project and author of "The Mythical Man-Month" (Addison-Wesley, 1975, ISBN 0-201-00650-2), an excellent early book on software engineering. The myth in question has been most tersely expressed as "Programmer time is fungible" and Brooks established conclusively that it is not. Hackers have never forgotten his advice; too often, {management} still does. See also {creationism}, {second-system effect}, {optimism}.

:browser: /n./ A program specifically designed to help users view and navigate hypertext, on-line documentation, or a database. While this general sense has been present in jargon for a long time, the proliferation of browsers for the World Wide Web after 1992 has made it much more popular and provided a central or default meaning of the word previously lacking in hacker usage. Nowadays, if someone mentions using a `browser' without qualification, one may assume it is a Web browser.

:BRS: /B-R-S/ /n./ Syn. {Big Red Switch}. This abbreviation is fairly common on-line.

:brute force: /adj./ Describes a primitive programming style, one in which the programmer relies on the computer's processing power instead of using his or her own intelligence to simplify the problem, often ignoring problems of scale and applying naive methods suited to small problems directly to large ones. The term can also be used in reference to programming style: brute-force programs are written in a heavyhanded, tedious way, full of repetition and devoid of any elegance or useful abstraction (see also {brute force and ignorance}).

The {canonical} example of a brute-force algorithm is associated with the `traveling salesman problem' (TSP), a classical {NP-}hard problem: Suppose a person is in, say, Boston, and wishes to drive to N other cities. In what order should the cities be visited in order to minimize the distance travelled? The brute-force method is to simply generate all possible routes and compare the distances; while guaranteed to work and simple to implement, this algorithm is clearly very stupid in that it considers even obviously absurd routes (like going from Boston to Houston via San Francisco and New York, in that order). For very small N it works well, but it rapidly becomes absurdly inefficient when N increases (for N = 15, there are already 1,307,674,368,000 possible routes to consider, and for N = 1000 -- well, see {bignum}). Sometimes, unfortunately, there is no better general solution than brute force. See also {NP-}.

A more simple-minded example of brute-force programming is finding the smallest number in a large list by first using an existing program to sort the list in ascending order, and then picking the first number off the front.

Whether brute-force programming should actually be considered stupid or not depends on the context; if the problem is not terribly big, the extra CPU time spent on a brute-force solution may cost less than the programmer time it would take to develop a more `intelligent' algorithm. Additionally, a more intelligent algorithm may imply more long-term complexity cost and bug-chasing than are justified by the speed improvement.

Ken Thompson, co-inventor of Unix, is reported to have uttered the epigram "When in doubt, use brute force". He probably intended this as a {ha ha only serious}, but the original Unix kernel's preference for simple, robust, and portable algorithms over {brittle} `smart' ones does seem to have been a significant factor in the success of that OS. Like so many other tradeoffs in software design, the choice between brute force and complex, finely-tuned cleverness is often a difficult one that requires both engineering savvy and delicate esthetic judgment.

:brute force and ignorance: /n./ A popular design technique at many software houses -- {brute force} coding unrelieved by any knowledge of how problems have been previously solved in elegant ways. Dogmatic adherence to design methodologies tends to encourage this sort of thing. Characteristic of early {larval stage} programming; unfortunately, many never outgrow it. Often abbreviated BFI: "Gak, they used a {bubble sort}! That's strictly from BFI." Compare {bogosity}.

:BSD: /B-S-D/ /n./ [abbreviation for `Berkeley Software Distribution'] a family of {{Unix}} versions for the {DEC} {VAX} and PDP-11 developed by Bill Joy and others at {Berzerkeley} starting around 1980, incorporating paged virtual memory, TCP/IP networking enhancements, and many other features. The BSD versions (4.1, 4.2, and 4.3) and the commercial versions derived from them (SunOS, ULTRIX, and Mt. Xinu) held the technical lead in the Unix world until AT&T's successful standardization efforts after about 1986, and are still widely popular. Note that BSD versions going back to 2.9 are often referred to by their version numbers, without the BSD prefix. See {4.2}, {{Unix}}, {USG Unix}.

:BUAF: // /n./ [abbreviation, from alt.fan.warlord] Big Ugly ASCII Font -- a special form of {ASCII art}. Various programs exist for rendering text strings into block, bloob, and pseudo-script fonts in cells between four and six character cells on a side; this is smaller than the letters generated by older {banner} (sense 2) programs. These are sometimes used to render one's name in a {sig block}, and are critically referred to as `BUAF's. See {warlording}.

:BUAG: // /n./ [abbreviation, from alt.fan.warlord] Big Ugly ASCII Graphic. Pejorative term for ugly {ASCII art}, especially as found in {sig block}s. For some reason, mutations of the head of Bart Simpson are particularly common in the least imaginative {sig block}s. See {warlording}.