Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.unix-wizards
Subject: Re: Unix Bugs vs. VMS bugs
Message-ID: <227@desint.UUCP>
Date: Mon, 19-Nov-84 19:53:29 EST
Article-I.D.: desint.227
Posted: Mon Nov 19 19:53:29 1984
Date-Received: Wed, 21-Nov-84 01:30:24 EST
References: <194@ucsbcsl.UUCP> <4652@utzoo.UUCP>
Organization: his home computer, Manhattan Beach, CA
Lines: 60

Okay, I admit it:  I'm an old DECcie, and I'm a bit wounded.

In article <4652@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:

>This assumes that (a) you can get DEC to agree that problem X really is
>a bug, and (b) you can get them to fix it.  From what I hear from my
>friends using VMS, neither of these assumptions is necessarily true.

As to (a), the "is it a bug or a feature?" argument plagues all OS
maintainers;  DEC is no exception.  There is always a temptation,
especially among the younger types who tend to be assigned to maintenance,
to declare it a feature to avoid thinking about how to fix it.
Nevertheless, the DEC _p_o_l_i_c_y is to be reasonable, even if it sometimes gets
violated.  I have found DEC quite a bit more reasonable on these grounds
than, for example, UniSoft.

As to (b), DEC will _a_l_w_a_y_s answer a reported SPR.  Period.  (OK, so a few
get lost in the paperwork shuffle;  this is an unfortunate reality of big
companies.)  But they can be _a_m_a_z_i_n_g_l_y slow.  When I worked for DEC, I
personally answered an SPR that was over a year old.  (It had not been my
responsibility for all that time, but I took longer than I wish I had).  For
fairness, I might add that this was on RSX-11M, where the customer had all
the sources that I used in fixing the problem.  (The 11M kernel is shipped in
source form;  you have to compile it to get a usable system.)

>Having DEC do all your software maintenance has the obvious advantage
>that you don't have to do the work.  It has the obvious disadvantage
>that you can't do the work even if you want to and need to.  Your degree
>of satisfaction is clearly a function of how responsive DEC is, and you
>have no input in deciding that.  Since you run VMS, you have no viable
>alternative if you come to dislike their service; they know this.

This implies that, since DEC has you by the gonads, they don't care how you
feel.  This is manifestly untrue.  That sale may be certain, but a lot of
future sales aren't.  A happy customer will by an 8600 with a load of
peripherals when they need more compute power.  An angry customer will be
out looking at Pyramids, Ridges, and Eclipses.  A happy customer will use
the Vax a lot and buy more memory when it gets overloaded;  an angry one
will buy a different brand of computer for those users, or buy a Vax but put
Unix on it.

How much time do you spend fixing bugs, Henry?  (Assuming you are the system
administrator, of course).  Before Larry Wall wrote "patch", every context
diff meant 10-30 minutes in the editor.  Under VMS or RSX-11, 30 fixes can be
installed in the same time frame, and you can be having a cup of coffee in
the meantime.  Yes, you have to wait for fixes, and sometimes it takes a
long time.  But if the system is stable you can afford to wait a couple of
months for a fix because it's probably minor.  And when somebody in Atlanta
finds a bug, the procedure that fixes it for them will fix it for me.  By
contrast, Mt. Xinu's bug list explicitly states that they do not follow
net.bugs.4bsd, despite the fact that their advertising would have you
believe that Unix support was their No. 1 product.

Didn't somebody recently say that when they brought up Ultrix they found
all the stuff from net.bugs fixed?  That's DEC support.
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff