Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!zdenko
From: zdenko@csd4.milw.wisc.edu (Zdenko Tomasic)
Newsgroups: comp.sys.next
Subject: Re: source code
Summary: How about validating the standard release?
Keywords: don't do it, it's a trap...
Message-ID: <972@csd4.milw.wisc.edu>
Date: 14 Feb 89 15:59:57 GMT
References: <490@nanovx.UUCP> <89474@sun.uucp> <1234@dukeac.UUCP> <445@garcon.cso.uiuc.edu>
Sender: news@csd4.milw.wisc.edu
Reply-To: zdenko@csd4.milw.wisc.edu (Zdenko Tomasic)
Organization: University of Wisconsin-Milwaukee
Lines: 24

If the ever-changing software status is the problem, why would Next not
provide a test that will prove no changes in the software environment
relative to the standard release? That way they'll be sure that the
problem/bug is related to the genuine stuff as opposed to modified.
Of course, anybody that modified the standard programs is on their own.

Naturally, the fool-proof test suit may not be easy or cheep to provide,
but it is really a necessity. Even AT&T had to do something (SVID, SVVS, etc.)
to that effect regardless how incomplete or buggy their test suit
is/was. To do otherwise would be just hiding their head in the sand.
The changing nature of software will not go away, and sweeping the
problem under a rug would not do anybody any good. As a matter of fact
one of the secrets, in my opinion, of success of UNIX and UNIX-like systems 
is the ability to change with time. Please, NeXT do not kill MACH-BSD
success for your own convenience!

As for the living proof that software system can be successful even
with constant changes just look at FSF. After all, you NeXT guys
use their software as well!
--
___________________________________________________________________
Zdenko Tomasic, UWM, Chem. Dept., P.O. Box 413, Milwaukee, WI 53201
UUCP: uwvax!uwmcsd1!uwmcsd4!zdenko
ARPA: zdenko@csd4.milw.wisc.edu