home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / security / misc / 2350 next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.0 KB
  1. Xref: sparky comp.security.misc:2350 comp.org.eff.talk:7863
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!dsinc!ub!csn!teal!bhayden
  3. From: bhayden@teal.csn.org (Bruce Hayden)
  4. Newsgroups: comp.security.misc,comp.org.eff.talk
  5. Subject: Re: Stupid Licenses (YUCK!)
  6. Message-ID: <bhayden.724947398@teal>
  7. Date: 21 Dec 92 14:16:38 GMT
  8. References: <bhayden.724690634@teal> <1992Dec19.023609.26000@news2.cis.umn.edu> <bhayden.724865911@teal> <TDRVB3JX@cc.swarthmore.edu>
  9. Sender: news@csn.org (news)
  10. Organization: Colorado SuperNet, Inc.
  11. Lines: 50
  12. Nntp-Posting-Host: teal.csn.org
  13.  
  14. eoliver@ralph.cs.haverford.edu (Erik Oliver) writes:
  15.  
  16. >Proving software correct is extremely difficult to do, and making sure
  17. >that there are no "bugs" is even harder.  For example, in the
  18. >IBM-Compatible world, it is very hards to anticipate all of the possible
  19. >setups that might have an incompatibility with your software.  If my new
  20. >product XYZ-Works doesn't work on a SuperDuper486DX/2 is that
  21. >necessarily reflective of a bug in my software or a glitch in some part
  22. >of the SuperDuper product?
  23.  
  24. Agreed - you can't get all of the bugs out. You can however get the major
  25. ones out, and the minor ones down below a certain, prespecified level.
  26. I am not advocating proving all software correct. I am just advocating
  27. somewhat well documented software quality control/assurance procedures.
  28.  
  29. >Because of the variety of IBM-Compatible products out there testing for
  30. >every configuration is unrealistic, if not impossible.  Even in the Mac
  31. >world, there are problems that occur because of interactions between
  32. >INITs and CDEVs with applications.  Are these bugs?
  33.  
  34. I think that depends on how common the hardware and hardware combination
  35. is. If the hardware is anywhere close to common, then I would contend
  36. that it is a reasonable to test a major product on all of the common
  37. hardware. 
  38.  
  39. I also would contend that once you have serious problems with a specified
  40. hardware combination (with previous releases or products) then you may
  41. potentially have a duty to duplicate that hardware combination for future
  42. QC testing.
  43.  
  44. Obviously, you have a resource problem here. IBM can afford to basically
  45. test almost anything imaginable (so why didn't OS/2 work on many non-IBM
  46. platforms?) A small company can probably only afford to test on a limited
  47. number of platforms and combinations.
  48.  
  49. >I think that if the manufacturers make good faith efforts to keep their
  50. >product working and put out bug releases that is about as much as we can
  51. >expect.  Personally I think that the software produced by organizations
  52. >like the FSF is better than a lot of commerical stuff because they are
  53. >not afraid to keep updating their product and release slews of fixes as
  54. >necessary.
  55.  
  56. I disagree. We have the capability today to set an acceptable bug level
  57. before the release, then not release until we have reached that level.
  58. That isn't happening in many cases. Either we aren't setting the level,
  59. or if we are, we are shipping before we get to that point.
  60.  
  61. Bruce E. Hayden
  62. (303) 758-8400
  63. bhayden@csn.org
  64.