home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / internal / 1289 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.9 KB
  1. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!rpi!newsserver.pixel.kodak.com!psinntp!npri6!murphy
  2. From: murphy@npri6.npri.com (David P. Murphy)
  3. Newsgroups: vmsnet.internals
  4. Subject: Re: PATCH on ALPHA ?
  5. Message-ID: <6131@npri6.npri.com>
  6. Date: 4 Sep 92 13:50:05 GMT
  7. References: <715362736.403197.MILLER@TGV.COM> <1992Sep1.214402.16889@eco.twg.com>
  8. Distribution: world
  9. Organization: NPRI, Alexandria VA
  10. Lines: 59
  11.  
  12.  
  13.  
  14. >>I've already worked with miles and miles of machine listings
  15. >>from both the GEM C compiler and the MACRO32 compiler.  I've even found
  16. >>several compiler optimizer bugs.  I know what I'm doing.
  17. >>
  18. >>MILLER@TGV.COM
  19.  
  20.  >And he's modest too.
  21.  >
  22.  >reece@eco.twg.com (Reece R. Pollack)
  23.  
  24. oh, bullshit.  patching and analyzing compiled code is not some arcane
  25. mysterious knowledge that mere mortals are not meant to understand;
  26. i know what _i'm_ doing, and i even know when i don't know what i'm doing.
  27. if someone wrote it, someone else can understand it.  sure, it took a while,
  28. but it's a lot easier to learn than some stuff i've had to swallow.
  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. It's much too easy for a customer to mis-
  36.  >type a patch and really screw things up, and if you provide them with a
  37.  >file to do it for them, why not provide them with an updated image?
  38.  
  39. then DON'T PATCH, if you're so scared.  NPRI has found patch files to be
  40. extremely valuable over the last decade to fix bugs without having to
  41. generate Yet Another Version of all the images we support.  it's very easy
  42. for an NPRI support rep to dialup, login, transfer the .COM file,
  43. perform the PATCH command, reINSTALL the image if necessary, and logout.
  44. our more intelligent clients --- whose existence you seem to doubt ---
  45. are perfectly capable of doing this themselves, which is nothing short
  46. of wonderful when said client is in europe; can't dialup, but the .COM
  47. file can be printed out on our laser and faxed to the client!  try to
  48. beat _that_ kind of turnaround time!  how long would it take to modify the
  49. source code, recompile, relink, *test* the new image, cut a tape, and
  50. physically send the tape across the atlantic?
  51.  
  52.  
  53. rule #1 when patching:  always REPLACE instead of DEPOSIT.  this increases
  54. your chances of actually hitting the correct location in the image.
  55.  
  56. rule #2 when patching:  always use ECO numbers.
  57.  
  58. rule #3 when patching:  always save the unpatched image for quick cutover
  59. if the patch screws up.
  60.  
  61.  
  62. in short, the benefits of patching far outweigh the risks.
  63.  
  64. ok
  65. dpm
  66. -- 
  67. murphy@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090
  68.  
  69.               When every one is dead the Great Game is finished.  Not before.
  70.                               --- Hurree Babu, "Kim"
  71.