APPLEVISION Monitor

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon May 6 15:45:08 2002

What you say makes some sense, but ...

comments below

Dick

----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc_at_conman.org>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, May 06, 2002 2:02 PM
Subject: Re: APPLEVISION Monitor


> 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:
>
The patches weren't generally SUN-patches, but had to go into the SUN system.
They were patches to software from application vendors whom our client had
directed us to use because that's what they used or intended to use.
Fortunately, they ultimately bought the system in question at our cost, plus,
so we didn't have to "eat" the associated problems. I didn't like the costs,
because they were larger than what I thought should be spent on this job. We
were, of course, reimbursed because we were working on time and materials, and
the hardware/software we utilized were, in the end, deliverable materials.
This didn't make me like the situation, though.

I WAS the mangement, and the 68K-based SUN system WAS a test system acquired
on behalf of our client.

I was still using CP/M to do the work more directly associated with running
the business, BTW. That didn't give us as much trouble.

Back then, '82-'83 thre wasn't much of any use that was available for UNIX,
and there were few justifications for using it in our environment. It gave me
a lot of grief, even though it was, in the end, a wash, and I've disliked it
ever since. I have had no clients since then who've used UNIX exclusively,
and in the time since then, I've painstakingly avoided contact with it.

Unix and Linux are both in extensive use at the POP, where Linux offers a way
around the costs associated with lots of user licenses for terminal (modem)
servers, and other such mundane problems. It works fine for managing the
telecom and, while the file system is rather slow, there are Unix versions for
the x86's that are considerably fast enough. News is served with a Unix
server with a pretty large and fast RAID and mail is done with LINUX. The
ISDN and persistent connection clients all come in through a LINUX server. I
don't get close to the POP as much as I once did, but I know it's out there.
I'm glad I don't have to fiddle with the terrible documentation and sloppy
code I waded through back when we were setting up.


>
> 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.
>
Windows patches??? We don't need no stinkin' patches. There aren't any ...
you have to buy the next version ... OTOH, when MS distributes new DLL's, they
come with the app's that require them and, if you choose to install such an
app, the updated files are automatically installed for you, whether you like
it or not. (Backup recommended in case you don't like the outcome!)
>
> 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).
>
remember what I previously said about "red herrings?"
>
Received on Mon May 06 2002 - 15:45:08 BST