SCSI n.
[Small Computer System Interface] A bus-independent standard
for system-level interfacing between a computer and intelligent
devices. Typically annotated in literature with `sexy'
(/sek'see/), `sissy' (/sis'ee/), and `scuzzy' (/skuh'zee/) as
pronunciation guides -- the last being the overwhelmingly
predominant form, much to the dismay of the designers and their
marketing people. One can usually assume that a person who
pronounces it /S-C-S-I/ is clueless.
Node:ScumOS, Next:search-and-destroy mode,
Previous:SCSI, Up:= S =
ScumOS /skuhm'os/ or /skuhm'O-S/ n.
Unflattering hackerism for SunOS, the BSD Unix variant
supported on Sun Microsystems's Unix workstations (see also sun-stools), and compare AIDX, Macintrash, Nominal Semidestructor, HP-SUX. Despite what this term might
suggest, Sun was founded by hackers and still enjoys excellent
relations with hackerdom; usage is more often in exasperation
than outright loathing.
Node:search-and-destroy
mode, Next:second-system effect, Previous:ScumOS, Up:= S =
search-and-destroy mode n.
Hackerism for a noninteractive search-and-replace facility in
an editor, so called because an incautiously chosen match pattern
can cause infinite damage.
Node:second-system effect,
Next:secondary
damage, Previous:search-and-destroy mode, Up:= S =
second-system effect n.
(sometimes, more euphoniously, `second-system syndrome') When
one is designing the successor to a relatively small, elegant,
and successful system, there is a tendency to become grandiose in
one's success and design an elephantine feature-laden monstrosity. The
term was first used by Fred Brooks in his classic "The Mythical
Man-Month: Essays on Software Engineering" (Addison-Wesley, 1975;
ISBN 0-201-00650-2). It described the jump from a set of nice,
simple operating systems on the IBM 70xx series to OS/360 on the
360 series. A similar effect can also happen in an evolving
system; see Brooks's Law,
creeping elegance,
creeping featurism.
See also Multics, OS/2, X, software bloat.
This version of the jargon lexicon has been described (with
altogether too much truth for comfort) as an example of
second-system effect run amok on jargon-1....
Node:secondary damage, Next:security
through obscurity, Previous:second-system effect, Up:= S =
secondary damage n.
When a fatal error occurs (esp. a segfault) the immediate cause may be that a
pointer has been trashed due to a previous fandango on core. However, this
fandango may have been due to an earlier fandango, so no
amount of analysis will reveal (directly) how the damage
occurred. "The data structure was clobbered, but it was secondary
damage."
By extension, the corruption resulting from N cascaded
fandangoes on core is `Nth-level damage'. There is at least one
case on record in which 17 hours of grovelling with adb actually dug
up the underlying bug behind an instance of seventh-level damage!
The hacker who accomplished this near-superhuman feat was
presented with an award by his fellows.
Node:security through
obscurity, Next:SED,
Previous:secondary
damage, Up:= S =
security through obscurity
(alt. `security by obscurity') A term applied by hackers to
most OS vendors' favorite way of coping with security holes --
namely, ignoring them, documenting neither any known holes nor
the underlying security algorithms, trusting that nobody will
find out about them and that people who do find out about them
won't exploit them. This "strategy" never works for long and
occasionally sets the world up for debacles like the RTM worm of 1988 (see Great Worm), but once the brief moments
of panic created by such events subside most vendors are all too
willing to turn over and go back to sleep. After all, actually
fixing the bugs would siphon off the resources needed to
implement the next user-interface frill on marketing's wish list
-- and besides, if they started fixing security bugs customers
might begin to expect it and imagine that their
warranties of merchantability gave them some sort of
right to a system with fewer holes in it than a
shotgunned Swiss cheese, and then where would we be?
Historical note: There are conflicting stories about the
origin of this term. It has been claimed that it was first used
in the Usenet newsgroup in _comp.sys.apollo_ during a
campaign to get HP/Apollo to fix security problems in its
Unix-clone Aegis/DomainOS (they
didn't change a thing). ITS fans, on
the other hand, say it was coined years earlier in opposition to
the incredibly paranoid Multics
people down the hall, for whom security was everything. In the
ITS culture it referred to (1) the fact that by the time a
tourist figured out how to make trouble he'd generally gotten
over the urge to make it, because he felt part of the community;
and (2) (self-mockingly) the poor coverage of the documentation
and obscurity of many commands. One instance of
deliberate security through obscurity is recorded; the
command to allow patching the running ITS system (escape escape
control-R) echoed as $$^D. If you actually typed alt alt ^D, that
set a flag that would prevent patching the system even if you
later got it right.
Node:SED, Next:segfault, Previous:security through obscurity,
Up:= S =
SED /S-E-D/ n.
[TMRC, from `Light-Emitting Diode'] Smoke-emitting diode. A
friode that lost the war. See also
LER.