home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1253 < prev    next >
Encoding:
Text File  |  1992-09-01  |  2.9 KB  |  58 lines
  1. Newsgroups: vmsnet.internals
  2. Path: sparky!uunet!mcsun!sunic!sejnet.sunet.se!eric
  3. From: eric@sejnet.sunet.se (Eric Thomas)
  4. Subject: re: PATCH on ALPHA ?
  5. Message-ID: <1992Sep2.022201.1@sejnet.sunet.se>
  6. Lines: 45
  7. Sender: news@sunic.sunet.se
  8. Reply-To: ERIC@SEARN.SUNET.SE
  9. Organization: SUNET, Stockholm, Sweden
  10. References:  <715362736.403197.MILLER@TGV.COM> <1992Sep1.214402.16889@eco.twg.com>
  11. Date: Wed, 2 Sep 1992 02:22:01 GMT
  12.  
  13. In article <1992Sep1.214402.16889@eco.twg.com>, reece@eco.twg.com (Reece R. Pollack) writes:
  14. > In article <715362736.403197.MILLER@TGV.COM>, MILLER@TGV.COM writes:
  15. > |>I doubt it.  I've already worked with miles and miles of machine listings
  16. > |>from both the GEM C compiler and the MACRO32 compiler.  I've even found
  17. > |>several compiler optimizer bugs.  I know what I'm doing.
  18. > 
  19. > And he's modest too.
  20.  
  21. I'm sure he is old enough to defend himself, but I'd just like to point out
  22. that, to me, this didn't look like bragging - just pointing out former
  23. experience in patching. Finding compiler optimization bugs is nothing
  24. extraordinary if you have been exposed to enough compiler-generated
  25. pseudo-assembler listings. Every time you mention "patching" or any other
  26. machine code based maintenance technique, people will start jumping and saying
  27. that this is too dangerous and unreliable, so one develops this sort of
  28. reactions.
  29.  
  30. > |>Besides, a lot of patches are trivial, like constant changes.  And
  31. > |>what if I want to patch some native M64 code?
  32. > 
  33. > I don't think I'd want to subject my customers to the headache of trying
  34. > to manage patched images. DEC has been moving away from this as fast as
  35. > they can, and for good reason.
  36.  
  37. And I don't think I'd like to subject myself to vendors who think they know
  38. better than the customers what is good for them, or that they know why other
  39. vendors are allocating their programming and support resources in one way or
  40. the other. Many patches are, indeed, constant changes, and ZAP utilities have
  41. VERIFY statements, sometimes even checksums. You can read me a zap on the phone
  42. in 5 minutes, and I know to check everything twice and to make a backup before.
  43. The alternative is to tell the users I have to wait for a tape, which may or
  44. may not be acceptable. More often than not, the problem requires an immediate
  45. solution because the dean of something is pissed off and watching the clock
  46. tick.
  47.  
  48. A long time ago I used to be able to get patches on the phone from my vendor,
  49. or short "updates" (basically source code patches). Now I can only get tapes
  50. with not one but a few hundred replacement files, checksummed and
  51. counter-checksummed and hyper-verified by a veeeeeeery slow, pseudo-AI software
  52. service manager factory, which the vendor decided I needed. I now need hours to
  53. do what I used to do in 5 minutes and reliability was MUCH better back then.
  54. Boy am I glad my vendor doesn't want to subject me to the horror of patches
  55. any longer, and for good reasons.
  56.  
  57.   Eric
  58.