APPLEVISION Monitor

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Mon May 6 15:02:40 2002

It was thus said that the Great Richard Erlacher once stated:
>
> That stuff is irrelevant, since *nix was demonstrated to be an insufferable
> cost and pain back in '82. Someting that ugly and unfriendly, that tore down
> the system each time an application had to be patched, resulting in days of
> downtime was just not acceptable. As a result, *nix hasn't gotten much of a
> look around here since then, aside from a brief peek at Linux. ... and
> neither has SUN hardware.

  Ah yes, the Sun patches that caused three or four day outtages for your
company. Now, obviously, you *had* to use the Sun systems or otherwise you
(or your company) should have dumped such fragile systems into the nearest
river ('82? Sun was just starting at that time so if you were using them
then, they were first run boxes) [1]. Barring that, then *you* should have
convinced management to *buy* a test Sun system, to be used only for the
purposes of testing the patches from Sun (and other software vendors). It
works like this:

        Yes, everytime we apply a patch, the system is unusable for X
        days. We have E engineers at $S who are thus unable to work for
        those X days, which costs the company X*E*S for each patch. We get
        a new patch every D days, which leads to an X day outtage 356.25/D
        times a year. A new Sun system will cost $C.

  Now, if $C is less than X*E*S, then:

        That will save us X*E*S-C dollars the first outtage, and after that,
        it will save X*E*S*(D-1) dollars over the course of the year, and
        X*E*S*D every year thereafter.

  But if $C is larger than X*E*S, then:

        The system will pay for itself after C/(X*E*S) outtages, but it will
        allow the engineering staff to continue working while we test the
        patches from Sun (and other vendors).

  I am seriously surprised that you, Richard, failed to do such a simple
action as that.

  Now, I've never experienced a problem with patching an application taking
down the entire system [2]. Under Unix, an application (or a patched
application) should not take down the system. Okay, patching a kernel may
cause the system to come down, but generally, one would test such a patch on
a non-production machine before deploying it.

  So Richard, do you willy-nilly deploy Windows patches before testing? I
don't know of any large company that will do such a silly thing, as that may
break critical applications.

  Heck, *I* don't apply patches willy-nilly. I check to see what the patch
fixes and if I'm even effected by the problem being patched (Apache fixing
an EBCDIC bug? Think I'll pass ... ) and if I am effected (say, a remote
exploit) I'll test it first before deploying it, and that's for my *own*
personal machines, much less a company's.

  -spc (And for the record, I've had easier times installing RedHat Linux
        than I have had installing Windows. Faster too, as once I answer
        all the questions, it can run unattended, with one reboot to get
        a fully running system)

[1] While it may not have been the first such operating system, Unix
        was the first *popular* operating system that was portable to
        a wide variety of hardware platforms, and that could be licensed
        for a reasonable fee from AT&T and that could support sufficient
        resources to be usable to many people (could the same work be done
        under MS-DOS 1.x (maybe 2.x---I don't remember when it first came
        out) or CP/M? Compared to the hardware that Unix ran on, the IBM
        PC could be condidered a ``toy computer.'' No memory management?
        No hard drives? What is this crap?

[2] Okay, to be fair, I can count on one hand (that's missing half its
        fingers) the number of times an application took down a Unix system.
        In one case I'm not sure what exactly happened---perhaps the
        application (applications actually [3]) tickled some kernel bug. The
        other time the application consumed all virtual memory and
        technically, the system was still running but impossible to shut
        down cleanly.

[3] IRIX 4.0.5, screen (forgot the version) and an IRC client (forgot
        which one). The user would log in, run screen, run the IRC client
        under that, then hang up. Boom. Repeatable. Solved it by
        forbidding the use of the IRC client (screen was too useful to ban).
Received on Mon May 06 2002 - 15:02:40 BST