home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sgi / 11331 < prev    next >
Encoding:
Text File  |  1992-07-24  |  2.1 KB  |  47 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!gatech!destroyer!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: Summary: Problem with /bin/mail...
  5. Message-ID: <nmtdnns@rhyolite.wpd.sgi.com>
  6. Keywords: /bin/mail
  7. Organization: Silicon Graphics, Inc.  Mountain View, CA
  8. References: <nkdpn0c@sgi.sgi.com> <1992Jul24.032024.22721@rata.vuw.ac.nz> <1992Jul24.034204.23207@rata.vuw.ac.nz>
  9. Date: Fri, 24 Jul 1992 15:42:39 GMT
  10. Lines: 35
  11.  
  12. In article <1992Jul24.034204.23207@rata.vuw.ac.nz>, tony@rata.vuw.ac.nz (Tony Martindale) writes:
  13. > ...
  14. > 
  15. >  There are lots of things that can cause mail to fail, are you going
  16. > to address all of them?  As I conceded above, bouncing the mail in the
  17. > context of your lost messages is the best thing to do.
  18.  
  19.  
  20. Of course, to the extent possible.  Bugs will be fixed as much as they
  21. can be fixed and improvements will be made.
  22.  
  23. Unfortunately, almost all mail failures are caused by operator errors.
  24. Mail works as the machine comes out of the box, especially with the new
  25. "auto-configuring" stuff.  Unfortunately, that configuration is often
  26. either inappropriate for the customer envirornment or is not consistent
  27. with local prejudices on how things should work.
  28.  
  29. After a few years, if you are not paid to work on the Hotline, you
  30. become very wary about helping people with mail problems in your
  31. "spare" time.  The general problem is hard, and the tools are powerful;
  32. sendmail is "Turing complete."  Solving mail problems is often like
  33. solving a random bug in a customer C or Fortran program, except that
  34.  
  35.     (1) the customer is generally completely and loudly certain the
  36.     problem is caused by a bug in the "compiler" (sendmail)
  37.     or the rest of the system.
  38.     (2) the language is less than convenient to read and understand.
  39.     (3) the requirements for the program are hard to discover and often
  40.     not understood by the customer, although the customer is often
  41.     loudly certain and wrong.
  42.     (4) the customer is often under great pressure from users with
  43.     even less interest, understanding, or patience, who "just want
  44.     email to work."
  45.  
  46. Vernon Schryver,  vjs@sgi.com
  47.