NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/security/misc/2376

Internet Message Format | 1992-12-29 | 3.7 KB

Xref: sparky comp.security.misc:2376 comp.org.eff.talk:8136
Newsgroups: comp.security.misc,comp.org.eff.talk
Path: sparky!uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall
From: [e-mail] (fred j mccall 575-3539)
Subject: Re: Stupid Licenses (YUCK!)
Message-ID: <[e-mail]>
Organization: Texas Instruments Inc
References: <bhayden.724690634@teal> <[e-mail]> <bhayden.724865911@teal> <[e-mail]> <bhayden.724947398@teal> <[e-mail]>
Date: Tue, 29 Dec 1992 14:56:49 GMT
Lines: 67

In <[e-mail]> [e-mail] (Leonard Erickson) writes:

>[e-mail] (Bruce Hayden) writes:

[Lots of good points about the impossibility of testing even a subset
of 'reasonable' configurations deleted.]

>>I also would contend that once you have serious problems with a specified
>>hardware combination (with previous releases or products) then you may
>>potentially have a duty to duplicate that hardware combination for future
>>QC testing.

>Or just list that setup as one that the software *won't* work with.

And even that may not do it, since you could easily wind up with
something the sixze of the NYC phone book on the first pass ("doesn't
work with TSR's A, B, C, and D loaded in that order on Machine X with
Video V).  In point of fact, some timing-critical software may work on
one machine and fail to work on another apparently identical machine.

>>Obviously, you have a resource problem here. IBM can afford to basically
>>test almost anything imaginable (so why didn't OS/2 work on many non-IBM
>>platforms?) A small company can probably only afford to test on a limited
>>number of platforms and combinations.

Well, you should take a look at the testing facility IBM has set up to
work on OS/2 portability problems:  hundreds of machines in various
configurations.  It just demonstrates how difficult the problem is,
and throwing resources at a problem that demands virutally infinite
resources just isn't going to be a practical answer.

[Note that there have even been problems with OS/2 and some patches on
IBM hardware.]

>>I disagree. We have the capability today to set an acceptable bug level
>>before the release, then not release until we have reached that level.
>>That isn't happening in many cases. Either we aren't setting the level,
>>or if we are, we are shipping before we get to that point.

And just how do you 'prove' that the software is at that level?  Ship
when you don't know there are any more bugs?  Personally, this is a
good policy but market forces may mitigate against it.  Then what
about that bug that you didn't find that hoses that one guy in Lower
Slobovia with his Kaputski Klone machine?

>I know of one company that is trying to do this, and you should hear
>the users scream about the fact that the new version isn't ready.

Hey, let's face it.  Users want software with zero defects, infinite
features, and such a simple interface that no manuals are required,
and they want it delivered yesterday.  And woe be unto he who gives
them software when they demand it that still has a bug in it.

The three most dangerous things in the world:

    1) a hardware type with a software patch
    2) a software type with a soldering iron
    3) a user with an idea

[And I just KNOW that somebody is going to read something into that
that isn't intended.]

--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
[e-mail] - I don't speak for others and they don't speak for me.