Unix Bugs vs. VMS bugs
for...@ucsbcsl.uucp
Unix and VMS, I'd like to say a few words about how I feel when I
read the Unix Bug reports that have been coming from Vance Vaughn.
I run VMS. One of the reasons I prefer VMS to Unix is because VMS
is much easier to maintain. In essence, I don't do any maintainence
because DEC does it all for me at a fixed rate. I can plan my
budget knowing exactly how much it will cost be to run VMS. With
Unix, software maintainence requires one or more gurus who spend
lots of time on the phone, going to conferences, reading nets
like this, and hacking. The worst part of this is that so much
effort is duplicated. For example, how much time has been spent
by all the Unix users in the world to find and fix the bugs that
are now being described. I bet that each bug has been found and
worked on by more than one person. This is wasted time.
Also consider that if you buy Unix from DEC, Tektronix, Unisoft,
IBM, or even Bell that you are paying for this wasted time. All
these companies employ people to do the same thing - supporting
Unix. With VMS the longest you have to remain in uncharted
territory is until the next Software Dispatch comes out. This
at least tells you what the known bugs are so you don't have
to replicate someone else's work. Then, every 3 or 4 months you
receive an update that fixes the known bugs. One company does
all this work. With the exception of people who find the same
bug before a Software Dispatch is issued, there is no wasted
effort.
After seeing the hundreds or thousands of bugs in the list I wonder
how much wasted effort will go into fixing them. Every Unix
site will have to perform the same work to fix the bugs.
With luck, most of the fixes will work. Some probably won't, which will
result in new bug reports that will have to be resolved. When
does it stop? My guess is that DEC support of Ultrix, IBM support
of PC/IX, Tektronix support of whatever they call their version,
and Bell support of System 5 will bring down the amount of wasted
time but compared to running VMS, sites running these versions of
Unix will still be paying more.
I realize that in one sense this isn't a fair comparison because unless
you're running a Vax, you really have no choice. In spite of the
problems I see with Unix, it is far better than any other system
I have ever seen (except VMS). I'd be glad to hear what anyone
has to say about this but let's please keep away from comparing
the technical details of VMS and Unix, at lease for now. Comparing
the two technically is one of my favorite topics of discussion
but that's not what this article is about.
Jon Forrest
ucbvax!ucsbcsl!forrest
Tim Smith
> how much wasted effort will go into fixing them. Every Unix
> site will have to perform the same work to fix the bugs.
> With luck, most of the fixes will work. Some probably won't, which will
> result in new bug reports that will have to be resolved. When
> does it stop? My guess is that DEC support of Ultrix, IBM support
> of PC/IX, Tektronix support of whatever they call their version,
> and Bell support of System 5 will bring down the amount of wasted
> time but compared to running VMS, sites running these versions of
> Unix will still be paying more.
If I decide to port VMS to the Callan ( and manage to avoid the men
in white coats long enough to actually do it... ), why does this make
it cost more for you to run VMS? This seems to be what you're saying
happens with UNIX.
--
Tim Smith ihnp4!cithep!tim or ihnp4!wlbr!callan!tim
Henry Spencer
> is much easier to maintain. In essence, I don't do any maintainence
> because DEC does it all for me at a fixed rate.
> ... With VMS the longest you have to remain in uncharted
> territory is until the next Software Dispatch comes out. This
> at least tells you what the known bugs are so you don't have
> to replicate someone else's work. Then, every 3 or 4 months you
> receive an update that fixes the known bugs. ...
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.
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.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Doug Gwyn <gwyn>
whether somebody else is doing the same for another version?
The single main reason that there are so many versions of UNIX
being maintained (DEC, IBM, AT&T, etc.) is that there are SO MANY
VERSIONS OF UNIX. This is due to its popularity. VMS, on the
other hand, comes in one version from a single source for a quite
limited family of computers. No wonder it can be maintained by a
single agency. You could say the same things about Apple ProDOS;
does that mean that it is preferable to UNIX? No way! (I use both.)
This seems to be another of the many bogus VMS-vs-UNIX comparisons.
Martin Fouts
To say that the reason there are so many versions of UNIX being
maintained is that there are so many versions of UNIX is much like saying
that the reason that taxes are so high is that taxes are so high.
The real problem I see raised here isn't that there are so many
people maintaining different versions of UNIX, but that so much
duplication of effort goes into maintaining the same version of Unix.
Several times I have fixed a bug just before someone publishes a fix
for it on the net. I find this very agravating. I find it even more
agravating to hear from people: "Oh yeah, so and so fixed that awhile ago,
but I don't remember what we did. . ."
I use to run a shop full of VMS machines and I spent very little time
on software maintenance. AND, my users were getting as much work done as
the users I have now on Unix. And before you scream at me for being a VMS
bigot, let me say that I also had a handful of RSTS/E machines, and those
users were getting their work done.
In fact, with the amount of time we spend down because the system
crashed due to some flakey UNIX bug, I wonder how we get any work done at
all.
----------
Doug Gwyn <gwyn>
Oh, you say you have an unsupported copy of UNIX? Whose fault is that?
Spencer W. Thomas
> In fact, with the amount of time we spend down because the system
>crashed due to some flakey UNIX bug, I wonder how we get any work done at
>all.
>
for a total of 1:20 because of crashes. Looking at the log, most of
those were power failures, and one was a translation lookaside buffer
parity error (i.e., a hardware failure). None (repeat NONE) were Unix
software failures. I don't know what version of Unix you're running,
but I find our 4.2bsd (with many bugs fixed, admittedly), one of the
most stable operating systems I have ever used. I have seen the machine
up continuously for 3 months (and then they do PM, so it gets taken
down).
=Spencer
Dave Cohrs
> >crashed due to some flakey UNIX bug, I wonder how we get any work done at
> >all.
.
.
> I don't know what version of Unix you're running,
> but I find our 4.2bsd (with many bugs fixed, admittedly), one of the
> most stable operating systems I have ever used. I have seen the machine
> up continuously for 3 months (and then they do PM, so it gets taken
> down).
>
> =Spencer
I also think that 4.2 is a stable system. One of our instructional systems
has been down twice in the past month -- once for PMs and once again because
a couple systems hacks here decided to play with it after system saves this
weekend and accidently killed it (superusers can be such kids at times). The
average load on this machine over the past month is 5++ with a peak of 50.
Where is the flacky software?
--
(Bug? What bug? That's a feature!)
Dave Cohrs
...!{allegra,heurikon,ihnp4,seismo,uwm-evax}!uwvax!dave
da...@wisc-rsch.arpa
Martin Fouts
This is exactly the sort of thing that most upsets me. My systems
are like yoyo's, and yours which are the same software (4.2bsd) stay up
'continuously' for three months, because of the many bug fixes.
How many of those bug fixes are duplications of someone else's
work? And how many are fixes you have received from sources which
(possibly through my own fault) aren't available to me? And (worst of
all) how many fix problems in your environment which would agravate
problems in mine?
Remember - You and I are fortunate enough to be on a major network
with a 'unix-wizards' mailing list. What about Joe Doe off in the
hinterlands who doesn't have a military contract?
We need a consistent coherant system with fewer variants and
better distribution for new software and bug fixes.
----------
Geoff Kuenning
In article <46...@utzoo.UUCP> he...@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
Mike Muuss
providing Standard Vendor Support (SVS) for their software
in a manner quite comparable to all other vendors, viz:
*) Every N years ( N := {1, 2, 3} ) they come out with a new
version of the system which is much better, and only breaks a
few old programs, while delivering *substantial* new functionality.
Standard Vendor Support.
*) You can send them bug reports (SPRs, or whatever), and
Bugs Bunny comes back and says, "Yup, that's a bug".
Standard Vendor Support.
*) You can call them on the phone, and they make rude noises and
tell you to get lost. Standard Vendor Support.
And, I don't fault them for it; it's what I expect from a Research
organization.
Basicly, my feeling is that you have to be prepared to take
whatever software your vendor offers, and use it "as is",
and be content (not happy, perhaps, just content), -OR-
you have to be prepared to "roll your own", be that as
simple as adding some other vendor packages, or as
radical as cultivating one or more in-house wizards.
There are, of course, "shades of grey", nothing is ever simple.
IBM is perhaps the most responsible about giving people fixes
to things incrementally; one IBM shop I know of used to get
a DTR (distribution tape reel) of bug fixes every few days;
you never bothered installing them unless you thought you had
a bug you thought they had fixed. Just this level of activity
consumed 1/2 a systems person; installing them ALL takes
about 2 full time people (so local management claimed).
There was no assurance that IBM would be fixing YOUR bug anytime
soon; they usually moved at a majestic pace, so you could
expect quite some delay. But that's OK, you could rest assured
they would eventually fix your problem, although it may have to
wait until the fabled Next Release.
Most IBM users are content with this level of support; you get
used to working around the bugs, and waiting for the next release.
However, some IBM owners do cultivate local wizards, and you
would be AMAZED at some of the marvelous things they could
make those systems do! The power of true wizardry can be astonishing.
I've picked IBM as my example above, because the computing culture tends to
revere IBM systems as over-priced, highly reliable, and exceptionally well
supported. But somehow, tending to associate myself with systems run by
local wizards of the appropriate flavor, I have never been content with
"Standard Vendor Support". In fact, those three words have become one of
the more repulsive slogans I can call to mind. "Standard Vendor Support".
Feel your jaw muscles tighten? Feel your blood pressure rising? I do.
If you want something that's non-stock, be prepared to (a) languish,
unsatisfied, or (b) deviate from Standard Vendor Support, and break out on
your own. Generally, the question isn't whether to break out on your own at
all, but how much, and in what direction.
Onwards!
-Mike
Henry Spencer
The VMS equivalent of this is that you've been wanting to fix it, so your
users could get some work done, but you couldn't, so you have to sit on
your hands until DEC gets around to fixing it. Why do you complain about
the ability to fix bugs when *you* need them fixed?
> In fact, with the amount of time we spend down because the system
> crashed due to some flakey UNIX bug, I wonder how we get any work done at
> all.
Sounds like somebody -- either you or someone like Berkeley -- has been
doing too much meddling with your UNIX. Else why would it be down so much?
We run real UNIX (i.e., V7), and the number of times we've crashed in the
last year can be counted on one's fingers. And most of the times we *do*
crash, it's because of hardware hiccups.
bo...@anl-mcs.arpa
years (before obtaining Unix), I lived with IBM's support. Bug fixes
toke 9-18 months to receive; by that time, who cares? There were
stupid performance bugs (that sold systems, no doubt), such as the PL/I
memory allocation routine that searched the free list for an optimally
sized fragment, but didn't stop when it found an exact match!
Perhaps the worst problem was that we received the weekly bug fix tapes
Mike described, but dared not install any that didn't address problems
that we had not experienced--many, perhaps most, of the fixes broke
something else. A result of this is that several times I spent time
chasing a bug and working out a demo case, only to be told "IBM has a
fix for that, but we didn't install it". Now who's wasting time?
Finally, this supported software was not reliable. I think we averaged
at least one software-caused crash per day.
I'll take Unix, preferrably with a small vendor whom I can call on the
telephone, any day.
Jim Boyle
Math and Comp Sci Div
Argonne Nat'l Lab
Martin Fouts
You are correct. This is a good version of standard vendor
support. I fought with DEC over it, back when they were a small
company and won. At that time we got good vendor support. Now they
are too large to be responsive to small companies and they give me the
same degree of support.
You are also correct about Berkeley. I never intended to imply
that they should do software maintenance, that isn't the function of a
research organization.
However, just because that's the way it is, doesn't mean that's
the way is should remain. I still believe that there is a Better Way,
and one of these days we are going to find it. Networks like USENET
and the ARPANET which allow us to exchange ideas and bug fixes are a
start, but we still have a long way to go:
1) Berkeley shouldn't be responsible for supporting their
software, but as long as its going to be used heavily, there ought to
be some way to sprout a central `fix control` agency. The MT XINU bug
list is a start, but. . .
2) Whomever owns the trademark this week should be more responsive
to its user community.
3) There should be some kind of movement towards a center. There
are too many versions of Unix, each with only partial functionallity.
The ANSI standards efforts, and /usr/group are heading that way,
but. . .
4) Computer users should be computer users NOT computer fixers.
----------
Dave Martindale
duplicated in fixing bugs in UNIX. However, that doesn't provide
much of an argument for running VMS instead.
> With VMS the longest you have to remain in uncharted
> territory is until the next Software Dispatch comes out. This
> at least tells you what the known bugs are so you don't have
> to replicate someone else's work. Then, every 3 or 4 months you
> receive an update that fixes the known bugs. One company does
> all this work. With the exception of people who find the same
> bug before a Software Dispatch is issued, there is no wasted
> effort.
On the other hand, what if you are in an environment where bugs have
to get fixed, sometimes in a hurry? If I have source and maintain it
myself, then whatever I consider an important bug GETS FIXED. It
sometimes is just not sufficient to report the bug and wait months
for the supporting organization to decide that it is indeed a bug,
that it is important enough to be fixed in a hurry, fix it, and distribute
the fix. Lists of known bugs are pretty useless in some environments -
you can't explain to hundreds of new students each term "please don't use
this feature of the operating system in that way or you'll crash the
system".
If you are in an environment where you can work around offical Known Bugs
and don't care if stuff takes a long time to get fixed, then you can
be happy with that level of support. Please don't implicitly criticise
those of us who aren't.
As for UNIX sites "paying more" for support, that likely depends on
circumstances too. How long does it take to develop a VMS device
driver compared to a UNIX one? How much wasted programmer time is
spent working around Known Bugs?
> I realize that in one sense this isn't a fair comparison because unless
> you're running a Vax, you really have no choice.
Interesting; I never thought of it that way. We buy VAXes to run UNIX on,
not UNIX to run on our VAXes.
Dave Martindale
Dave Cohrs
> with a 'unix-wizards' mailing list. What about Joe Doe off in the
> hinterlands who doesn't have a military contract?
Say wha? I get *my* unix-wizards from USENET and this university didn't
get a military contract (spare me!) to do so. So what does John Doe
do? Why, he buys a modem and calls his nearest USENET neighbor and
gets netnews and gets the fixes as fast (or faster) than you do.
Martin Fouts
Of course, the problem that Joe Doe has is still a problem if he lives
in Montana, and the nearest USENET site is in Utah, and his management
doesn't appreciate the long distance phone bills.
By the way, about half the useful information I get doesn't appear to
get to usenet. . .
----------
Ron Natalie
fact, I was called into a conference with some regional DEC people to
explain my problems, and they admitted they were all valid and they would
try to do better in the future. So far, no improvement.
We were discussing VMS vs. UNIX. Your last statement shows that DEC's
UNIX product "Ultrix" shows the same quality of support as VMS, which
implies, that the problem is not Unix but UNIX vendors.
-Ron
Stanley Friesen
>
>doing too much meddling with your UNIX. Else why would it be down so much?
>We run real UNIX (i.e., V7), and the number of times we've crashed in the
>last year can be counted on one's fingers. And most of the times we *do*
>crash, it's because of hardware hiccups.
>--
> Henry Spencer @ U of Toronto Zoology
> {allegra,ihnp4,linus,decvax}!utzoo!henry
I must agree in principle -- only it wasn't Berkeley, we are
running BSD 4.1 and have only had *one* crash that was *not* due to
hardware in over a year, and that was when someone tried to nroff
the entire on-line manual to the line printer at one time!!
Our last down time was Preventative Maintenance and installation
of new hardware, almost a week ago.