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

Internet Message Format | 1992-12-22 | 5.5 KB

Xref: sparky comp.security.misc:2384 comp.org.eff.talk:8172
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]> <[e-mail]> <[e-mail]> <bhayden.725514513@teal>
Date: Wed, 30 Dec 1992 13:08:05 GMT
Lines: 101

In <bhayden.725514513@teal> [e-mail] (Bruce Hayden) writes:

>[e-mail] (Charles Geyer) writes:

>>In article <[e-mail]> [e-mail]
>>(Bear Giles) asks:

>>> Would you postpone a release with known bugs (documented in a 'here there
>>> be dragons' addendum) which would replace a previous, more buggy version?

>>Why can't they just provide a release that fixes the old bugs without
>>introducing (known) new ones?  Featurality first is the only explanation.

>That is what is known at regression testing. First, many don't do it,
>and second, even those that do often miss things. However, I would
>contend that regression testing is a minimum requirement when upgrading
>a product. .

All true, but it still won't find all the bugs.  It won't find any of
the ones that got through your initial tests and it won't necessarily
find new ones that are introduced by the fixes you've put in.  What
you seem to be arguing for is exhaustive testing (an impossibility) to
be repeated each time a change is made.

You want it WHEN???

>>A customer can't really complain if software doesn't work on hardware the
>>vendor doesn't claim it works on.

>Well, if the vendor says that it will only work on a limited configuration
>you may be right. However, I think that it is suicide to write software
>(at least for a PC) that runs on a limited range of machines. I ask what
>is wrong with a company if they can't get their product to run on a
>generic PC (or if they won't even try).

Define 'generic PC'.  Most people define it as "what is on my desk".
Unfortunately for software producers, that's not the same for
everyone.

>In my case, the only program that won't run on my 486 machine is OS/2.
>Does that mean that I get a new box? No - I use windows 3.1 instead.

I suspect you would have similar problems with loading UNIX on you
machine.  The more a piece of software 'pushes' the hardware, the more
likely it is to fail on marginal machines.

>(besides, IBM said it would work. I just refuse to pay them to figure
>out their problems, after I already paid them for the software).

One of us appears to be misinformed.  What did IBM want to make you
pay?  Last I knew, support for OS/2 was free through installation (on
a supported machine), and all the patches (so far) are also free.

>My experience is that few software vendors spend much time defining
>what their software will not run on (except maybe to say it requires
>at least DOS 3.10, or Windows 3.1). My feeling is that if they don't
>tell me before I buy a piece of software (i.e. on the box) that it
>won't run on my machine, I expect it to run.

They don't spend a lot of time doing it for a number of reasons.  1)
We're back to that problem of exhaustive test.  There are just too may
possible combinations of hardware and software to try them all.  2)
DOS typically doesn't stress the hardware all that much, and will let
hardware with sloppy timing happily run.  Software that is more
efficient and makes better use of the hardware will require tighter
timings on it, and will fail on some machines.  Windows 3.1 fails on
some machines with marginal memory that Windows 3.0 runs on, for
example.  OS/2 fails on even more, in part because it tries to really
use the whole machine instead of only using the bottom 640k of memory
and then getting to the rest of it via kludges.  3) Software can
interact with other software.  What TSRs you have loaded AND THE ORDER
THEY ARE LOADED IN can make a big difference, but this will vary with
what kind of hardware you have, what memory manager you use, etc.

>>But the "should have been upgraded a long time ago" reminds me of another
>>consequence of the software industry's abysmal quality level.  Only a fool
>>"upgrades" unnecessarily.  Most "upgrades" turn out to be degrades that
>>needlessly break lots of working applications and only provide bells and
>>whistles in compensation.  This forces sensible customers to fall behind
>>"current" versions of operating systems.  It's sound defensive computer
>>usage.

>Unfortunately, software vendors invariably figure out a way to force
>you to upgrade. One classic approach is to refuse to maintain (or
>answer questions) about older versions.

Just how many version would you have them support, and for how long?
On how many different machines in how many different configurations?

>Again, if the vendor did legitimate regression testing before releasing
>the upgrade, you wouldn't have this problem.

Well, you wouldn't have it AS MUCH.  However, from reading your
comments, it just doesn't seem that you've considered what kind of
real-world problems you're talking about.

--
"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.