The Jargon File, Version 2.9.10, 01 Jul 1992. Various

{braino}, as opposed to the mental glitch which is the braino itself. E.g. typing `dir' on a UNIX box after a session with DOS.

      :brain-damaged: 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: [IBM: from the location of one of the corporation's facilities] n. Any unexpected jump in a program that produces catastrophic or just plain weird results. See {jump off into never-never land}, {hyperspace}.

      :brand brand brand: n. Humorous catch-phrase from {BartleMUD}s, in

       which players were described carrying a list of objects, the most

       common of which would usually be a brand. Often used as a joke in

       {talk mode} as in "Fred the wizard is here, carrying brand ruby

       brand brand brand kettle broadsword flamethrower". A brand is a

       torch, of course; one burns up a lot of those exploring dungeons.

       Prob. influenced by the famous Monty Python "Spam" skit.

      :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 breadcrumbs 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) or delete 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 older versions of FOOGOL to develop newer ones. This is an important milestone; see {MFTL}.

      :breath-of-life packet: [XEROX PARC] n. An Ethernet packet that contained bootstrap (see {boot}) code, periodically sent out from a working computer to infuse the `breath of life' into any computer on the network that had 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}.

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

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

      :broken arrow: [IBM] n. 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. In true {luser} fashion, the original documentation of these codes (visible on every 3270 terminal, and necessary for debugging network problems) was confined to an IBM customer engineering manual.

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

      :broket: /broh'k*t/ or /broh'ket`/ [by analogy with `bracket': a `broken bracket'] n. 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 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} does. See also {creationism}, {second-system effect}.

      :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 na"ive methods suited to small problems directly to large ones.

      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 he or she visit them 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}). 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