Keeping Unix Running and Tuned 223 Paying someone $40,000 a year to maintain 20 machines translates into $2000 per machine-year. Typical low-end Unix workstations cost between $3000 and $5000 and are replaced about every two years. Combine these costs with the cost of the machines and software, it becomes clear that the allegedly cost-effective “solution” of “open systems” isn’t really cost- effective at all. Keeping Unix Running and Tuned Sysadmins are highly paid baby sitters. Just as a baby transforms perfectly good input into excrement, which it then drops in its diapers, Unix drops excrement all over its file system and the network in the form of core dumps from crashing programs, temporary files that aren’t, cancerous log files, and illegitimate network rebroadcasts. But unlike the baby, who may smear his nuggets around but generally keeps them in his diapers, Unix plays hide and seek with its waste. Without an experienced sysadmin to ferret them out, the system slowly runs out of space, starts to stink, gets uncomfortable, and complains or just dies. Some systems have so much diarrhea that the diapers are changed automat- ically: Date: 20 Sep 90 04:22:36 GMT From: alan@mq.com (Alan H. Mintz) Subject: Re: uucp cores Newsgroups: comp.unix.xenix.sco In article 2495@polari.UUCP, corwin@polari.UUCP (Don Glover) writes: For quite some time now I have been getting the message from uucp cores in /usr/spool/uucp, sure enough I go there and there is a core, I rm it and it comes back… Yup. The release notes for SCO HDB uucp indicate that “uucico will normally dump core.” This is normal. In fact, the default SCO instal- lation includes a cron script that removes cores from /usr/spool/uucp. Baby sitters waste time by watching TV when the baby isn’t actively upset (some of them do homework) a sysadmin sits in front of a TV reading net- news while watching for warnings, errors, and user complaints (some of them also do homework). Large networks of Unix systems don’t like to be
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 mly@lcs.mit.edu 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'
Previous Page Next Page