aps@decwrl.UUCP (Armando P. Stettner) (12/09/85)
Path: decwrl!decvax!genrad!panda!talcott!wjh12!maynard!campbell From: maynard!campbell (Larry Campbell) Newsgroups: net.unix-wizards Subject: Re: Re: Ultrix and 4.2 and der Mouse Message-Id: <195@maynard.UUCP> Date: 8 Dec 85 06:43:24 GMT References: <1554@decwrl.UUCP> <1441@cornell.UUCP> <722@decuac.UUCP> Organization: The Boston Software Works Inc., Maynard, MA Lines: 20 Apparently-To: aps > ...But, and this is what I think Armando was getting at, if you > have no use for any of that, if you do all your own support, if > your goal is to make massive changes to the kernel (essentially > voiding the warrantee) then you might do better to go with a > non-commercial product. No commercial OS product that I know > of is set up to allow the customer to make changes to it and > still be supported by the company. > -- > Fred @ DEC Ultrix Applications Center decvax!decuac!avolio Well, maybe this is ancient history, and the product is nearing the end of its life, but TOPS-10, DEC's timesharing system for its largest machines (PDP-10s) was ALWAYS shipped in source form. There was no binary-only distribution. And the stuff was supported too (although if you wanted a bug report taken seriously, you had to be able to reproduce it on a vanilla system). -- Larry Campbell The Boston Software Works, Inc. 120 Fulton Street Boston MA 02109 ARPA: maynard.UUCP:campbell@harvard.ARPA UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Larry, One of the key phrases in your paragraph is "although if you wanted a bug report taken seriously, you had to be able to reproduce it on a vanilla system". Such is the case with Ultrix *and* VMS. If you get the sources to those systems and fiddle with them, any bugs you report will have to be demonstrable on a vanilla system. Simple. I can't imagine anybody doing support of any large software "product" (or hardware for that matter) and allow themselves to chase their tail because of something the customer did. It just makes sense to want to start debugging from a known point. As to TOPS-10 being shipped with source and "no binary-only distribution: well, we did not have to succumb to the restrictions upon the use of TOPS-10 by AT&T. aps.
barmar@mit-eddie.UUCP (Barry Margolin) (12/10/85)
Honeywell has always shipped Multics with full sources, and we also
provide full support. If a bug is reported we a person whose job it is
to try to reproduce it on our vanilla system, trying various versions of
the software (to see if it has already been fixed in a development
version). If he cannot reproduce it, and the developer cannot figure
out why the occurs, it is back in the customer's ballpark. Generally
the customer will mention that the software has a local mod; if the bug
is due to the local change then it is their problem to fix it, of
course. The customers all have accounts on our alpha development system
(it is also the bug reporting system), so they can check out the problem
before reporting it, or contact experts directly.
One great feature of shipping sources is that bug reports often include
the fixes!
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmarroger@celtics.UUCP (Roger Klorese) (12/13/85)
In article <686@mit-eddie.UUCP> barmar@mit-eddie.UUCP (Barry Margolin) writes: > >Honeywell has always shipped Multics with full sources, and we also >provide full support. If a bug is reported we a person whose job it is >to try to reproduce it on our vanilla system, trying various versions of >the software (to see if it has already been fixed in a development >version). If he cannot reproduce it, and the developer cannot figure >out why the occurs, it is back in the customer's ballpark. I can't speak for Celerity (partially because we haven't faced any source distribution/local mods issues yet, and partly because I CAN'T speak FOR Celerity!), but I can tell yuo that my previous employer's (Prime's) current policy is that the burden of proof regarding local mods is on Prime Customer Service too, i.e., Prime has to prove that the failure is not in its code. Sounds eminently fair to me. -- ... "What were you expecting, rock'n'roll?" Roger B.A. Klorese Celerity Computing, 40 Speen St., Framingham, MA 01701, (617) 872-1772 UUCP: seismo!harvard!bu-cs!celtics!roger ARPA: celtics!roger@bu-cs.ARPA