🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.security.misc
Article #711

Re: Stupid Licenses (YUCK!)

#711
From: fred j mccall 575-3539
Date: Tue, 29 Dec 1992 15:05
60 lines
3499 bytes
In <1992Dec28.002314.21233@news2.cis.umn.edu> charlie@umnstat.stat.umn.edu (Charles Geyer) writes:

>In article <1992Dec22.034142.14471@fsl.noaa.gov> bear@kestrel.fsl.noaa.gov
>(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.

Well, only if that's the only 'explanation' you're willing to look at.
However, you might want to consider that any time you change software
(even to fix a known bug), there is a possibility that you will
introduce other bugs somewhere else.  Naturally everyone TRIES to
avoid this (design for low coupling, etc.), but it is still going to
happen, particularly if performance is an issue (because all those
nice theoretical practices may have to be traded off to get enough raw
speed). 

I'd suggest you read up on this (someone else suggested _The Mythical
Man Month_, which is a good place to start), but I get the impression
that you really aren't that interested in the real reasons.

>> What about a release with significant improvements which just happened
>> to crash if you had a really obscure combination of hardware and software?
>> What if the company offered you a free upgrade (or other compensation)
>> if its software twigged on this odd combination?

They would soon go broke.  Figure that ANY program of any size is
going to have bugs.  

>>
>> Or what if the software only had problems on really old systems which
>> should have been upgraded a long time ago? ("Gee, I'm running DOS 2.8
>> on a 5 MHz XT and your program doesn't seem to work!")  How long do
>> you need to keep providing upgrades for existing platforms?

As long as that's where your market is.  If they can't upgrade their
hardware to something within that last decade, why would they update
software? 

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

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

Provided that what you have meets your requirements, of course.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Technical Details
Message-ID: <1992Dec29.150502.5631@mksol.dseg.ti.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall
References: <bhayden.724690634@teal> <1992Dec19.023609.26000@news2.cis.umn.edu> <1992Dec22.034142.14471@fsl.noaa.gov> <1992Dec28.002314.21233@news2.cis.umn.edu>

Show Full Headers
Complete Article Headers
Newsgroups: comp.security.misc,comp.org.eff.talk
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Stupid Licenses (YUCK!)
Message-ID: <1992Dec29.150502.5631@mksol.dseg.ti.com>
Organization: Texas Instruments Inc
References: <bhayden.724690634@teal> <1992Dec19.023609.26000@news2.cis.umn.edu> <1992Dec22.034142.14471@fsl.noaa.gov> <1992Dec28.002314.21233@news2.cis.umn.edu>
Date: Tue, 29 Dec 1992 15:05:02 GMT
Lines: 60