The Jargon File, Eric S. Raymond [speld decodable readers txt] 📗

send a break -- how brain-dead!"

Node:braino, Next:[1914]branch to Fishkill, Previous:[1915]brain-dead,

Up:[1916]= B =

braino /bray'no/ n.

Syn. for [1917]thinko. See also [1918]brain fart.

Node:branch to Fishkill, Next:[1919]bread crumbs,

Previous:[1920]braino, Up:[1921]= B =

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 [1922]jump off into never-never land,

[1923]hyperspace.

Node:bread crumbs, Next:[1924]break, Previous:[1925]branch to

Fishkill, Up:[1926]= B =

bread crumbs n.

Debugging statements inserted into a program that emit output or

log indicators of the program's [1927]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 or the older French folktale of Thumbelina; in several

variants of these, a character leaves a trail of bread crumbs so as

not to get lost in the woods. 2. In user-interface design, any feature

that allows some tracking of where you've been, like coloring visited

links purple rather than blue in Netscape (also called `footrinting').

Node:break, Next:[1928]break-even point, Previous:[1929]bread crumbs,

Up:[1930]= B =

break

vt. To cause to be [1931]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

[1932]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.

Node:break-even point, Next:[1933]breath-of-life packet,

Previous:[1934]break, Up:[1935]= B =

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 [1936]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 [1937]VAXen in the

early and mid-1980s. A FOOGOL implementation is available at the

Retrocomputing Museum [1938]http://www.ccil.org/retro.

Node:breath-of-life packet, Next:[1939]breedle,

Previous:[1940]break-even point, Up:[1941]= B =

breath-of-life packet n.

[XEROX PARC] An Ethernet packet that contains bootstrap (see

[1942]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 [1943]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.

Node:breedle, Next:[1944]Breidbart Index,

Previous:[1945]breath-of-life packet, Up:[1946]= B =

breedle n.

See [1947]feep.

Node:Breidbart Index, Next:[1948]bring X to its knees,

Previous:[1949]breedle, Up:[1950]= B =

Breidbart Index /bri:d'bart ind*ks/

A measurement of the severity of spam invented by long-time hacker

Seth Breidbart, used for programming cancelbots. The Breidbart Index

takes into account the fact that excessive multi-posting [1951]EMP is

worse than excessive cross-posting [1952]ECP. The Breidbart Index is

computed as follows: For each article in a spam, take the square-root

of the number of newsgroups to which the article is posted. The

Breidbart Index is the sum of the square roots of all of the posts in

the spam. For example, one article posted to nine newsgroups and again

to sixteen would have BI = sqrt(9) + sqrt(16) = 7. It is generally

agreed that a spam is cancelable if the Breidbart Index exceeds 20.

The Breidbart Index accumulates over a 45-day window. Ten articles

yesterday and ten articles today and ten articles tomorrow add up to a

30-article spam. Spam fighters will often reset the count if you can

convince them that the spam was accidental and/or you have seen the

error of your ways and won't repeat it. Breidbart Index can accumulate

over multiple authors. For example, the "Make Money Fast" pyramid

scheme exceeded a BI of 20 a long time ago, and is now considered

"cancel on sight".

Node:bring X to its knees, Next:[1953]brittle,

Previous:[1954]Breidbart Index, Up:[1955]= B =

bring X to its knees v.

[common] To present a machine, operating system, piece of software, or

algorithm with a load so extreme or [1956]pathological that it grinds

to a halt. "To bring a MicroVAX to its knees, try twenty users running

[1957]vi -- or four running [1958]EMACS." Compare [1959]hog.

Node:brittle, Next:[1960]broadcast storm, Previous:[1961]bring X to

its knees, Up:[1962]= B =

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 commercial software, which (due to closed-source

development) displays the quality far more often than it ought to.

Oppose [1963]robust.

Node:broadcast storm, Next:[1964]brochureware, Previous:[1965]brittle,

Up:[1966]= B =

broadcast storm n.

[common] 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 [1967]network meltdown; compare [1968]mail

storm.

Node:brochureware, Next:[1969]broken, Previous:[1970]broadcast storm,

Up:[1971]= B =

brochureware n.

Planned but non-existent product like [1972]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.

Node:broken, Next:[1973]broken arrow, Previous:[1974]brochureware,

Up:[1975]= B =

broken adj.

Not working properly (of programs). 2. Behaving strangely;

especially (when used of people) exhibiting extreme depression.

Node:broken arrow, Next:[1976]BrokenWindows, Previous:[1977]broken,

Up:[1978]= B =

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 [1979]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....

Node:BrokenWindows, Next:[1980]broket, Previous:[1981]broken arrow,

Up:[1982]= B =

BrokenWindows n.

Abusive hackerism for the [1983]crufty and [1984]elephantine [1985]X

environment on Sun machines; properly called `OpenWindows'.

Node:broket, Next:[1986]Brooks's Law, Previous:[1987]BrokenWindows,

Up:[1988]= B =

broket /broh'k*t/ or /broh'ket`/ n.

[rare; by analogy with bracket': abroken 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 [1989]Real World as well, these are usually called [1990]angle

brackets.)

Node:Brooks's Law, Next:[1991]brown-paper-bag bug,

Previous:[1992]broket, Up:[1993]= B =

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

development 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

(though it's not the whole story; see [1994]bazaar); too often,

[1995]management still does. See also [1996]creationism,

[1997]second-system effect, [1998]optimism.

Node:brown-paper-bag bug, Next:[1999]browser, Previous:[2000]Brooks's

Law, Up:[2001]= B =

brown-paper-bag bug n.

A bug in a public software release that is so embarrassing that the

author notionally wears a brown paper bag over his head for a while so

he won't be recognized on the net. Entered popular usage after the

early-1999 release of the first Linux 2.2, which had one. The phrase

was used in Linus Torvalds's apology posting.

Node:browser, Next:[2002]BRS, Previous:[2003]brown-paper-bag bug,

Up:[2004]= B =

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 techspeak 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.

Node:BRS, Next:[2005]brute force, Previous:[2006]browser, Up:[2007]= B

=

BRS /B-R-S/ n.

Syn. [2008]Big Red Switch. This abbreviation is fairly common on-line.

Node:brute force, Next:[2009]brute force and ignorance,

Previous:[2010]BRS, Up:[2011]= B =

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 [2012]brute force and ignorance).

The [2013]canonical example of a brute-force algorithm is associated

with the `traveling salesman problem' (TSP), a classical [2014]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 [2015]bignum). Sometimes, unfortunately, there is no better

general solution than brute force. See also [2016]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