forrest@ucsbcsl.UUCP ( ) (11/16/84)
Without trying to get involved with the technical differences between 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@cithep.UucP (Tim Smith ) (11/17/84)
> 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. 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@utzoo.UUCP (Henry Spencer) (11/18/84)
> 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. > ... 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
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/18/84)
So long as your OS vendor is maintaining your OS, what do you care 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.
fouts@orville (Martin Fouts) (11/18/84)
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.
----------Mark Crispin <MRC@SU-SCORE.ARPA> (11/18/84)
This sort of issue comes up whenever people get the
impression that there are any absolutes. Just about any system
can benefit from having an on-site wizard, even if the operating
system is manufacturer-supported (e.g. VMS, TOPS-20, VM/370).
While the cost of ownership of a wizard is non-trivial (yes, they
do "spend lots of time on the phone, going to conferences,
reading nets like this, and hacking"), consider the alternative.
You are either stuck with the product as it comes from the
manufacturer or you find yourself forced to rent a wizard -- that
is, you must hire a consultant.
Now I have nothing against consultants! I'm a full-time
rental wizard (tr: independent consultant) and I find the
business quite lucrative. I hope that attitudes such as Jon
Forrest's continue -- customers with that attitude comprise most
of my business.
The "people problem" with Unix is not the wizards, but
rather the groupies. I define a "Unix groupie" as any individual
who (1) considers Unix in its present state to be software
perfection, (2) refuses to believe that other operating systems
have features too, (3) makes noises of disgust whenever some
other operating system is mentioned, (4) makes noises of disgust
whenever some programming language other than C is mentioned.
It's reminiscent of the APL\360 groupies of 15 years ago.
Unix does have a software maturity problem. I for one would
love to see a standard Unix. It unnerves me when I must relearn
"how to do X" just because I'm using somebody else's Unix system.
Many of these incompatibilities seem to be completely gratuitous.
Also, Unix lacks some very basic facilities which are only now
starting to appear: process-to-process memory mapping (for both
read and write), process-to-file memory mapping, file interlocks,
long file names, user-friendly command interfaces (sh, csh, ksh,
etc. are many things, but user-friendly is not one of them), etc.
I wish that these things would all appear in all places in the
same way, but I fear that in just about every minor version of
Unix it'll be completely different.
Unix is clearly not for the fainthearted. If you really
don't care all that much what the operating system does for you
-- e.g. all you want is a FORTRAN engine -- then Unix may not be
your answer. You can use a "throwaway" operating system such as
VMS. If you actually start USING some special feature of your
operating system, you may start caring about what happens when
you have to change computer vendors.
Finally, I cannot let the comment about "Unix being better
than any other operating system (except VMS)" go by unchallenged.
I can't see how anybody can possibly make such grand claims about
VMS. It's the manufacturer-supplied operating system for a
superminicomputer which is now (with the 8600) selling at (high)
mainframe prices. It's an upgrade from an earlier minicomputer
operating system from that manufacturer, but still some years(!)
away from achieving the level of functionality of other operating
systems from that manufacturer's other product lines! It's still
a dinosaur.
Mark Crispin
MRC@SU-SCORE.ARPA
-------gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/18/84)
Sounds like your UNIX vendor is not doing his job. Oh, you say you have an unsupported copy of UNIX? Whose fault is that?
tihor@cmcl2.UUCP (11/19/84)
>Sounds like your UNIX vendor is not doing his job. >Oh, you say you have an unsupported copy of UNIX? Whose fault is that? Do you see many people supporting UNIX with virtual address spaces and IP/TCP around? The fact that there are a few who may be able to offer this in the near term future (one, two, three years tops) is heartening. But nothing to get too carried away about.
thomas@utah-gr.UUCP (Spencer W. Thomas) (11/19/84)
In article <5870@brl-tgr.ARPA> fouts@orville (Martin Fouts) writes: > 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. > Let me see, it looks like so far this month, our machine has been down 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@uwvax.UUCP (Dave Cohrs) (11/19/84)
> > 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. . . . > 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 dave@wisc-rsch.arpa
fouts@orville (Martin Fouts) (11/20/84)
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@desint.UUCP (Geoff Kuenning) (11/20/84)
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
tihor@cmcl2.UUCP (11/20/84)
>From net.unix-wizards / gwyn@brl-tgr / 11:43 am Nov 19, 1984*/ >> Do you see many people supporting UNIX with virtual address spaces >> and IP/TCP around? >Yes. Neat. We could use someone who will provide Unix support, including IP/TCP, full virtual memory, the usual bunch of programs written to run on 4.2 BSD on about 4 or 5 VAXen for prices comperable or lower than DEC's in the Basic and "Self-Maintenance" categories of Software Support for the comperable service levels. Of course they should be a major company committed to the field for at least the next five to ten years. What are the names of all these support providers?
Mike Muuss <mike@brl-tgr> (11/20/84)
Well, from my perspective, Berkeley (without trying to) has been
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!
-MikeRon Natalie <ron@BRL-TGR> (11/20/84)
Both Gould and DEC offer UNIX versions with both TCP/IP and Virtual Memory support NOW. -Ron
Ron Natalie <ron@BRL-TGR> (11/20/84)
Gould meets all of the criteria you set with the exception that if you by their system today you get 4.1c. 4.2 will be available after the new year. We've ordered their computers primarily since their performance beats the hell out of anything DEC offers and the price is lower. -Ron
henry@utzoo.UUCP (Henry Spencer) (11/20/84)
> Several times I have fixed a bug just before someone publishes a fix > for it on the net. I find this very agravating. ... 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. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
boyle@ANL-MCS.ARPA (11/20/84)
Let me second Mike Muuss's comments about Standard Vendor Support. For 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
thomas@utah-gr.UUCP (Spencer W. Thomas) (11/20/84)
In article <5938@brl-tgr.ARPA> Ron Natalie <ron@BRL-TGR> writes: >Gould meets all of the criteria you set with the exception that if you >by their system today you get 4.1c. 4.2 will be available after the new >year. We've ordered their computers primarily since their performance beats >the hell out of anything DEC offers and the price is lower. > Yep, I just went down to Ft Lauderdale to run some benchmarks on the Gould 97/32. I was mucho impressed with the speed. I also got to run on a pre-release version of their 4.2, and it seems to work, anyway. Didn't try the virtual memory version, though. Unfortunately for them, the new DEC 8600 comes in at about the same performance, and about the same price. We have decided that we probably won't buy an "off brand" unless it offers significantly better price/performance than a VAX. This is to reduce the need for producing multiple versions of software - currently, we can compile once and distribute binaries (except the Suns, and they are always behind the rest of the world here). To offset this hassle, a competitor must provide some definite advantage. 6 months ago, Gould had the advantage - you couldn't get a VAX with that performance. Now, it isn't true. Sigh. =Spencer
fouts@orville (Martin Fouts) (11/20/84)
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.
----------dmmartindale@watcgl.UUCP (Dave Martindale) (11/20/84)
First, let me say that it is indeed unfortunate that much work is 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@uwvax.UUCP (Dave Cohrs) (11/21/84)
> 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? 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. -- (Bug? What bug? That's a feature!) Dave Cohrs ...!{allegra,heurikon,ihnp4,seismo,uwm-evax}!uwvax!dave dave@wisc-rsch.arpa
Ron Natalie <ron@BRL-TGR> (11/21/84)
Sorry, but the Gould PN9000 is about 10 times a 780 for about $400K. Certainly beats the DEC entry. -Ron
ted@usceast.UUCP (Ted Nolan) (11/21/84)
In article <24300004@cmcl2.UUCP> tihor@cmcl2.UUCP writes: > >Neat. We could use someone who will provide Unix support, including IP/TCP, >full virtual memory, the usual bunch of programs written to run on 4.2 BSD >on about 4 or 5 VAXen for prices comperable or lower than DEC's in the Basic >and "Self-Maintenance" categories of Software Support for the comperable >service levels. Of course they should be a major company committed to the field >for at least the next five to ten years. > >What are the names of all these support providers? Isn't this what DEC is doing with Ultrix? (I would certainly expect their prices to be comparable with DEC's :-) ) Ted Nolan ..usceast!ted -- ------------------------------------------------------------------------------- Ted Nolan ...decvax!mcnc!ncsu!ncrcae!usceast!ted 6536 Brookside Circle ...akgua!usceast!ted Columbia, SC 29206 ("Deep space is my dwelling place, the stars my destination") -------------------------------------------------------------------------------
fouts@orville (Martin Fouts) (11/21/84)
Whoops, I guess I should have looked more closely at Dave's address. 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 <ron@BRL-TGR> (11/21/84)
I am an Unhappy customer of DEC and I won't by an 8600. As a matter of 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
Mike Muuss <mike@brl-tgr> (11/22/84)
Spencer, Spencer. Since when does 4 MIPS ?= 10 MIPS. I have benchmarked the Gould 8780 at 9.9 x a VAX 780 doing double precision & heavy pointer math. All claims I have heard for the DEC 8600 rate it as 3 - 4 x a VAX 780. Has this changed? -Mike
gnu@sun.uucp (John Gilmore) (11/22/84)
> Do you see many people supporting UNIX with virtual address spaces > and IP/TCP around? Yes.
avolio@grendel.UUCP (Frederick M. Avolio) (11/23/84)
> Gould meets all of the criteria you set with the exception that if you > by their system today you get 4.1c. 4.2 will be available after the new > year. We've ordered their computers primarily since their performance beats > the hell out of anything DEC offers and the price is lower. .... >Sorry, but the Gould PN9000 is about 10 times a 780 for about $400K. >Certainly beats the DEC entry. > >-Ron Now, do you believe that stuff? I didn't say it wasn't true... I asked if you believed it! I won't, aside from that, comment on Ron's observation as it pains me to do so. (By the way, Ultrix-32 is 4.2BSD based...) But yes, such support is available through the companies mentioned (and others I am sure). Ultrix-32, for example, is a *supported* Digital S/W product. That means manuals, training, bug fixes, newsletters, updates, an 800 number hot line for customer help (already in use), a large group of UNIX experts, and software services (driver writing, for example). I know something about this as I work in a group which provides such services. But that's what's neat about UNIX (oh I mean the UNIX OPERATING SYSTEM (tm). Go ahead and use Ultrix as a noun for now... :-) ) -- it is an operating system which can be held together by one or two so-called gurus. And, as I would guess most of us have seen, a system which stays up for long periods of times w/o problems. But, if you want to pay to have someone else do these things (including updates, fixes, etc.) there are people who handle such things. Fred -- Fred Avolio, DEC -- U{LTR,N}IX Support 301/731-4100 x4227 UUCP: {seismo,decvax}!grendel!avolio ARPA: grendel!avolio@seismo.ARPA
friesen@psivax.UUCP (Stanley Friesen) (11/27/84)
In article <4659@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >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. >-- > 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.
bsa@ncoast.UUCP (Brandon Allbery) (11/29/84)
Ditto. We run Xenix; the last two crashes we had were fairly recent,
but before that, the last one was about a year ago. One happened when
a visitor to the site decided to pull the fuse out of the system power
supply while it was running (!); the other was a result of ``meddling
with the unix'' (the latest release of Xenix apparently had a format-
without-erase built into it; it also had a bug whereby if you selected
the option to have system shutdown position the hard disk head(s) over
blank disk space, it'd bash the head against the stop until it broke,
so we tried to switch back to the old Xenix, which couldn't read the
1.3.3 format and promptly barfed all over the i-list). Other than these,
and a disk error that managed to change an instruction in swap into a
TRAP #2 instruction, causing a panic, we have had NO crashes since about
this time last year. And the one that happened then was a result of
some bad programming by a local programmer; not a true crash, just that
everyone including the owner was running a very recursive shell script
that would eventually use up all system and user process slots...
Only hacked Unixes have software errors; V7 is great, and Xenix on here
is great for the most part unless they rush the next version in too soon,
as with version 1.3.3 .
--bsa
--
Brandon Allbery @ North Coast Xenix | the.world!ucbvax!decvax!cwruecmp!
6504 Chestnut Road, Independence, Ohio | {atvax!}ncoast!{tdi1!}bsa
(216) 524-1416 \ 44131 | E1439@CSUOHIO.BITNET (friend's acct.)
| BALLBERY (161-7070) on MCI Mail
---------------------------------------+---------------------------------------
Keeping the Galaxies safe for Civilization... :-)Mike Gallaher <Gallaher@RU-BLUE.ARPA> (12/05/84)
From: John Gilmore <gnu@sun.uucp> > Do you see many people supporting UNIX with virtual address spaces > and IP/TCP around? Yes. Well put! Changing the subject: I got your Emacs sources a couple of days ago, thanks. I'll put the mouse support in our version for the next release, hopefully in a couple of months. Mike Gallaher Unipress sun!sunrise!unipress!mg -------