ugh.book

(singke) #1

224 System Administration


far from their maternal sysadmin, who frequently dials up the system from
home in the evening to burp it.

Unix Systems Become Senile in Weeks, Not Years

Unix was developed in a research environment where systems rarely
stayed up for several days. It was not designed to stay up for weeks at a
time, let alone continuously. Compounding the problem is how Unix utili-
ties and applications (especially those from Berkeley) are seemingly devel-
oped: a programmer types in some code, compiles it, runs it, and waits for
it to crash. Programs that don’t crash are presumed to be running correctly.
Production-style quality assurance, so vital for third-party application
developers, wasn’t part of the development culture.

While this approach suffices for a term project in an operating systems
course, it simply doesn’t catch code-cancers that appear in production code
that has to remain running for days, weeks, or months at a time. It’s not sur-
prising that most major Unix systems suffer from memory leaks, garbage
accumulation, and slow corruption of their address space—problems that
typically only show themselves after a program has been running for a few
days.

The difficulty of attaching a debugger to a running program (and the
impossibility of attaching a debugger to a crashed program) prevents inter-
rogating a program that has been running for days, and then suddenly fails.
As a result, bugs usually don’t get fixed (or even tracked down), and peri-
odically rebooting Unix is the most reliable way to keep it from exhibiting
Alzheimer’s disease.

Date: Sat, 29 Feb 1992 17:30:41 PST
From: Richard Mlynarik <[email protected]>
To: UNIX-HATERS
Subject: And I thought it was the leap-year

So here I am, losing with Unix on the 29th of February:

% make -k xds
sh: Bus error
make: Fatal error: The command `date "+19%y 13
* %m + 32 * %d + 24 * %H + 60 * %M + p" | dc'
returned status `19200'
Free download pdf