6 May
2002
6 May
'02
3:41 a.m.
-----Original Message-----
From: Richard Erlacher [mailto:edick@idcomm.com]
I've also got some *nix experience, and, frankly,
anything
that requires I
recompile the OS just to install a driver is too much
trouble. I've done
that, but hopefully never will again.
I thought I would mention here that Unix has had dynamically
loadable kernel modules for a while. I know from experience
that the Unix PC O/S (at least from 3.0) uses them for graphics
stuff.
IRIX has also had them, after a fashion, for a while. (Actually,
IRIX has a "sysgen," but technically it's a re-link, not a re-
compile)
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl
Hacker.")."\x08!\n");
'
6 May
6 May
6:20 a.m.
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.
Dick
----- Original Message -----
From: "Christopher Smith" <csmith(a)amdocs.com
To: <classiccmp(a)classiccmp.org
Sent: Monday, May 06, 2002 9:41 AM
Subject: RE: APPLEVISION Monitor
------------------------------------------------------------------------------
--
-----Original
Message-----
From: Richard Erlacher [mailto:edick@idcomm.com]
I've also got some *nix experience, and,
frankly, anything
that requires I
recompile the OS just to install a driver is too much
trouble. I've done
that, but hopefully never will again.
I thought I would mention here that Unix has had dynamically
loadable kernel modules for a while. I know from experience
that the Unix PC O/S (at least from 3.0) uses them for graphics
stuff.
IRIX has also had them, after a fashion, for a while. (Actually,
IRIX has a "sysgen," but technically it's a re-link, not a re-
compile)
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl
Hacker.")."\x08!\n");
'
----------------------------------------------------------------------------
---------
The information contained in this message is proprietary of Amdocs,
protected from disclosure, and may be privileged.
The information is intended to be conveyed only to the designated
recipient(s)
of the message. If the reader of this message is not
the intended recipient,
you are hereby notified that any dissemination, use, distribution or copying
of
this communication is strictly prohibited and may be
unlawful.
If you have received this communication in error, please notify us
immediately
> by replying to the message and deleting it from your computer.
> Thank you.
----------------------------------------------------------------------------
---------
8:02 a.m.
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).
8:45 a.m.
What you say makes some sense, but ...
comments below
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org To: <classiccmp(a)classiccmp.org Sent: Monday, May 06, 2002 2:02 PM
Subject: Re: APPLEVISION Monitor
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.
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.
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?"
10:22 a.m.
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!)
There certainly are enough of them if you run anything based
on NT or MS Exchange. The release of new patches is almost nonstop,
not to mention the huge service packs as well. The funny thing is,
most of them seem to be so-called 'security' fixes.
Jeff
--
Home of the TRS-80 Model 2000 FAQ File
http://www.cchaven.com
http://www.geocities.com/siliconvalley/lakes/6757
10:50 a.m.
You're right, of course. I refer to Win9x as Windows, and 'NT as 'NT. Not
everybody does that. I've applied patches to NT a couple of times, not to
mention installing extensions. Sorry to generate the confusion.
Dick
----- Original Message -----
From: "Jeff Hellige" <jhellige(a)earthlink.net>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, May 06, 2002 4:22 PM
Subject: Re: APPLEVISION Monitor
>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!)
There certainly are enough of them if you run anything based
on NT or MS Exchange. The release of new patches is almost nonstop,
not to mention the huge service packs as well. The funny thing is,
most of them seem to be so-called 'security' fixes.
Jeff
--
Home of the TRS-80 Model 2000 FAQ File
http://www.cchaven.com
http://www.geocities.com/siliconvalley/lakes/6757
3:51 p.m.
It was thus said that the Great Richard Erlacher once stated:
Sorry I used the wrong terminology here. Let me try again:
So Richarch, do you willy-nilly deploy Windows service packs before
testing? I don't know of any large company that will do such a silly thing,
as that may break critical applications.
-spc (You know, things labeled SP1, SP2, etc.)
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!)
5:23 p.m.
Aside from NT, the only service packs I've encountered have been for MSOffice
and for Internet Explorer.
There were a couple for some of the app's I use, but they installed without
even a reboot, even though some of them were pretty large.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, May 06, 2002 9:51 PM
Subject: Re: APPLEVISION Monitor
It was thus said that the Great Richard Erlacher once
stated:
>
> > 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!)
Sorry I used the wrong terminology here. Let me try again:
So Richarch, do you willy-nilly deploy Windows service packs before
testing? I don't know of any large company that will do such a silly thing,
as that may break critical applications.
-spc (You know, things labeled SP1, SP2, etc.)
8311
days inactive
8312
days old
7 comments
4 participants
participants (4)
-
csmith＠amdocs.com -
edick＠idcomm.com -
jhellige＠earthlink.net -
spc＠conman.org