🚀 go-pugleaf

In article <1992Sep1.214402.16889@eco.twg.com>, reece@eco.twg.com (Reece R. Pollack) writes:
> In article <715362736.403197.MILLER@TGV.COM>, MILLER@TGV.COM writes:
> |>I doubt it.  I've already worked with miles and miles of machine listings
> |>from both the GEM C compiler and the MACRO32 compiler.  I've even found
> |>several compiler optimizer bugs.  I know what I'm doing.
> 
> And he's modest too.

I'm sure he is old enough to defend himself, but I'd just like to point out
that, to me, this didn't look like bragging - just pointing out former
experience in patching. Finding compiler optimization bugs is nothing
extraordinary if you have been exposed to enough compiler-generated
pseudo-assembler listings. Every time you mention "patching" or any other
machine code based maintenance technique, people will start jumping and saying
that this is too dangerous and unreliable, so one develops this sort of
reactions.

> |>Besides, a lot of patches are trivial, like constant changes.  And
> |>what if I want to patch some native M64 code?
> 
> I don't think I'd want to subject my customers to the headache of trying
> to manage patched images. DEC has been moving away from this as fast as
> they can, and for good reason.

And I don't think I'd like to subject myself to vendors who think they know
better than the customers what is good for them, or that they know why other
vendors are allocating their programming and support resources in one way or
the other. Many patches are, indeed, constant changes, and ZAP utilities have
VERIFY statements, sometimes even checksums. You can read me a zap on the phone
in 5 minutes, and I know to check everything twice and to make a backup before.
The alternative is to tell the users I have to wait for a tape, which may or
may not be acceptable. More often than not, the problem requires an immediate
solution because the dean of something is pissed off and watching the clock
tick.

A long time ago I used to be able to get patches on the phone from my vendor,
or short "updates" (basically source code patches). Now I can only get tapes
with not one but a few hundred replacement files, checksummed and
counter-checksummed and hyper-verified by a veeeeeeery slow, pseudo-AI software
service manager factory, which the vendor decided I needed. I now need hours to
do what I used to do in 5 minutes and reliability was MUCH better back then.
Boy am I glad my vendor doesn't want to subject me to the horror of patches
any longer, and for good reasons.

  Eric