HDTenEightyP/NetNews huggingface dataset:
From: singer@ll.mit.edu (Matthew R. Singer)
Subject: Re: VME format on a PC
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Date: Thu, 28 Jan 93 14:04:11 GMT


--
In article <1993Jan27.234645.2645@phx.mcd.mot.com>, fredch@phx.mcd.mot.com (Fred Christiansen) writes:
|>Newsgroups: comp.arch.bus.vmebus
|>Path: llpost!ll.mit.edu!xn.ll.mit.edu!ames!haven.umd.edu!darwin.sura.net!spool.mu.edu!uwm.edu!linac!att!mcdchg!mcdphx!fredch
|>From: fredch@phx.mcd.mot.com (Fred Christiansen)
|>Subject: Re: VME format on a PC
|>Message-ID: <1993Jan27.234645.2645@phx.mcd.mot.com>
|>Sender: news@phx.mcd.mot.com
|>Nntp-Posting-Host: quad4-p3.phx.mcd.mot.com
|>Organization: Motorola Computer Group, RT Software
|>References: <1993Jan27.161039@axion.bt.co.uk>
|>Date: Wed, 27 Jan 93 18:46:45 EST
|>Lines: 13
|>
|>In article <1993Jan27.161039@axion.bt.co.uk> sblagdon@axion.bt.co.uk (Sean Blagdon) writes:
|>There is no such thing as VME format disks; disks formats are OS-specific
|>in terms of their file systems (below that, maybe controller specific).
|>What OS are you running on your VME system?  If Unix, there may be DOS-based
|>tools for writing Unix format file systems; conversely, there are
|>Unix-based tools for writing DOS format file systems.
|>-- 

Such as??? A MesSyDos based tool to read Sun disks could be handy...

-----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
-----------------------------------------------------------------------------
Newsgroups: comp.arch.bus.vmebus
From: izhak@ernet.in (S M Izhak)
Subject: I/O for DSP with minimum glue logic.
Organization: Giant Meterwave Radio Telescope., TIFR
Distribution: comp.arch.bus.vmebus
Date: Thu, 28 Jan 1993 06:22:13 GMT

Hi!
	As I'm not a veteran of comp.*, I am not sure whether the
issue of I/O in DSP has been discusse earlier.
	I am interested in a easy chip level solution for interfacing
the ADSP 21020 or and such DSP to standard devices like the SCSI disk,
etc. I am basically interested in getting the maximum sustained I/O
rate for dedicated appilcation in Astronomy on huge volumes of data.
	Thanks in advance to whoever takes time and effort to reply to
this. You could reply to my email address : izhak@gmrt.ernet.in. If
enough users are interested I could send a synopsis of the responses
on the network soon. 
	Hoping to hear from someone who is ready to extend a helping
hand.

Zac
(S.M.Izhak)
Newsgroups: comp.arch
From: izhak@ernet.in (S M Izhak)
Subject: I/O for DSP !!
Organization: Giant Meterwave Radio Telescope., TIFR
Distribution: comp.arch
Date: Fri, 29 Jan 1993 02:07:59 GMT

Hi!
	As I'm not a veteran of comp.arch, I am not sure whether the
issue of I/O in DSP has been discusse earlier.
	I am interested in a easy chip level solution for interfacing
the ADSP 21020 or and such DSP to standard devices like the SCSI disk,
etc. I am basically interested in getting the maximum sustained I/O
rate for dedicated appilcation in Astronomy on huge volumes of data.
	Thanks in advance to whoever takes time and effort to reply to
this. You could reply to my email address : izhak@gmrt.ernet.in. If
enough users are interested I could send a synopsis of the responses
on the network soon. 
	Hoping to hear from someone who is ready to extend a helping
hand.

Zac
(S.M.Izhak)
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: HOw many PC's make an Amdahl mainframe
Date: 28 Jan 93 02:56:14 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <1993Jan27.024351.17902@news.arc.nasa.gov> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
>In article <1993Jan26.215541.9957@adobe.com>, zstern@adobe.com (Zalman Stern) writes:
>|> fewer and fewer problems that require that kind of power and it becomes  
>|> harder and harder to make the machine more powerful. Cheaper is a problem  
>|> because the margins go down and a lot of a mainframe's costs are not  
>|> hardware oriented. (I.e. service, paying for the space and other central  
>|> facilities required.)
>
>Actually, though, there are plenty of problems that require the largest 
>available power, and, in the commercial world, there are an increasing
>number of really big applications (e.g. VISA-type credit cards) which,
>generally, need an increasing number of transactions-per-second.  Anyone
>tried to buy anything with a VISA card the last week before Christmas?
>The wait can be rather long.   Credit card companies, Airline Reservations, 
>banks with ATM applications, you-name-it.  All have increasing needs for
>systems with expanding transaction rates.  A system which can do 2000 
>transactions/sec may indeed be worth a *lot* more than 200 systems which 
>can do 10 trans./sec.

Amex have brought several `super'computers recently as I recall (though
it is late at night...) eg a CM-5 for doing ``promotional mailshots''
around 92Q2, and think I remember an nCUBE being mentioned too.

And they are not alone.  Much as I hate to think of all these `big'
machines being used for sending junk mail and running subscription
lists, those are big jobs that will get bigger.

Damon
-- 
Damon Hart-Davis        d@hd.org   London UK   Tel/Fax: +44 81 755 0077  [1.37]

Two separate jobs, two employers: (1) Editor of Parallelogram, (2) Consultant
and seller of uucp news/mail feeds (UK#5 pcm, FIRST MONTH FREE) and cheap Suns.
Newsgroups: comp.arch
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: How many PC's make an Amdahl mainframe
Organization: The Backbone Cabal
	<1993Jan26.225943.21955@enterprise.rdd.lmsc.lockheed.com>
	<1993@niktow.canisius.edu> <128R02pn34lx01@JUTS.ccc.amdahl.com>
Date: Fri, 29 Jan 1993 01:42:58 GMT

In article <128R02pn34lx01@JUTS.ccc.amdahl.com> jjs40@cd.amdahl.com (John Sullivan) writes:
> 
> As far as memory and I/O are concerned, PC's in general still can't support
> more than 16MB of RAM.  A SCSI controller with DMA support provides about 
> the same functionality as a mainframe I/O channel.  In theory, you can put
> more than one in a PC, but the bus can't really support it at that point.

Hmmm...  We regularly sell pc's with 32MB of memory, and an EISA bus
can certainly handle a couple of 32bit SCSI cards.  Many motherboards
now a days support 64MB of memory, and local bus SCSI boards are going
to up the performance a lot.  FDDI and such are making connecting
hundreds of pc's together more practical.  I would say that your
numbers are already off by a factor of 2-4 and they number of PC's
needed to "match" a mainframe is closing by a factor of 1.5 per year.


This is really a battle of "economy of scale" vs "economy of
locality".  It used to be much cheaper to by one 400MB disk than ten
40MB disks, but now with disk sizes exceeding 2GB and with the
incredible volume of PC's the cheapest way to by a 40GB disk is to buy
20 2GB disks and put them in a RAID.  Likewise with CPUs.  The IBM
370/158's were around 200 times faster than an apple II, but now the
fastest mainframe cpu is barely a factor of 2 or 3 faster than the
high end RISC chips and _much_ more expensive.  (CPU power as
measured by integer or floating point code, not memory bandwidth,
multiprocessing/interrupt stuff, etc.)  The easiest way to get lots of
MIPS nowadays its to use multiple CPUs, and many of the fastest
computers are going toward using pretty much standard PC CPUs.


By the year 2000, what people call a "mainframe" and the things they
will do with a "mainframe" won't look very much like what a
"mainframe" was when the term was coined.  Mainframes aren't dead, but
they are having to fight really hard to just to stay sort of alive.



-wayne



Newsgroups: comp.arch
From: mek@hydrox.enet.dec.com (Mark Klamerus)
Subject: IEEE Mass Storage Ref Model
Date: Thu, 21 Jan 93 14:24:48 PST
X-Received: by usenet.pa.dec.com; id AA20912; Thu, 21 Jan 93 14:24:49 -0800
X-Received: by enet-gw.pa.dec.com; id AA16408; Thu, 21 Jan 93 14:24:48 -0800
X-Received: from hydrox.enet; by decwrl.enet; Thu, 21 Jan 93 14:24:48 PST
X-To: comp.arch.usenet
X-Apparently-To: comp.arch.usenet


	Can someone tell me what this is?  I recently had a question
	regarding this in a pros/cons relation to SQL/Database.

	What is this model/methodology?  Does it have a number?
	Is there documentation regarding this on the net?

	thanks,
	Mark Klamerus

Newsgroups: comp.arch
From: bob@tera.com (Bob Alverson)
Subject: Re: How many vector registers are useful?
Followup-To: comp.arch
Keywords: architecture, question
Organization: Tera Computer Company, Seattle, WA
Date: Tue, 26 Jan 1993 17:32:20 GMT

In article <93-01-174@comp.compilers> kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
>
>The Fujitsu machines with their reconfigurable register file of 32 or
>64kb, which is 4k or 8k words, being grouped from 256 register a 16/32
>words to 8 registers a 512/1024 words.
>
>Now there is the question: is such a large register file useful at all ?

Besides serving as a software cache, a register file also serves as a
prefetch area (something caches are doing now, too).  So, you might want
more registers as your memory latency increases.  Of course, more registers
only help if your processor can use them.  For a vector machine, you might
need longer vectors to cover longer memory latency.

Bob
Newsgroups: comp.arch
From: fineberg@wilbur.nas.nasa.gov (Samuel A. Fineberg)
Subject: Re: HOw many PC's make an Amdahl mainframe
Organization: CSC, NASA Ames Research Center, NAS Division
Date: Wed, 27 Jan 93 00:13:58 GMT
Reply-To: fineberg@nas.nasa.gov

In article <1993Jan26.225943.21955@enterprise.rdd.lmsc.lockheed.com>, lando@zycar.lmsc.com (Jim Landowski x45016) writes:
|> 
|> 	Considering that the mainframes last bastion of use is in the very
|> large database management (and transaction processing). I don't think a
|> gaggle of PC's can compete here BUT if you include a fileserver (data-
|> server) then the picture changes and the PC, as a smart data entry/query
|> terminal will win... the software is what's needed (if it doen't already
|> exist). IMHO.
|> 
|>   - Jim L.
|> 
Have you ever looked at the Tandem.  Granted it takes a lot of good software
and some special hardware to make it work right.

Sam
Newsgroups: comp.arch
From: sommerfeld@apollo.hp.com (Bill Sommerfeld)
Subject: Re: ANDF bogosity
Date: Wed, 27 Jan 1993 17:01:22 GMT
	<1378@taniwha.UUCP> <1993Jan20.120919.14235@infodev.cam.ac.uk>
	<barnett.727570830@convex.convex.com> <pnevmati.727648034@cs.wisc.edu>
	<1993Jan25.161034.14188@vbohub.vbo.dec.com>
	<1993Jan27.094642.1@tango.cchs.su.oz.au>
Organization: Hewlett Packard

In article <1993Jan27.094642.1@tango.cchs.su.oz.au> brennan@tango.cchs.su.oz.au (Luke Brennan) writes:

	   I can get DES sources from anywhere on the planet, yet I can't
	   re-export them once they land in USA??
	   What about all the PUBLISHED versions that have come from the
	   USA itself?

Probably the most succinct and relevant statement here is:

   "It helps a little if you review Alice in Wonderland immediately before
    examining the export regulations." - Prof. Jerry Saltzer, in 1988

No more need be said.
Newsgroups: comp.arch,comp.sys.hp
From: pdg@cup.hp.com (Paul Gootherts)
Subject: Re: HP-PA softw. virtual addr. translation HOW ?
Date: Thu, 28 Jan 1993 19:52:42 GMT
Organization: Hewlett-Packard
X-Newsreader: TIN [version 1.1.8 PL6]

> Each entry in the hash table points to the FIRST PPN in a linked list of all
> physical pages whose VPN hash to the same value.  Thus, you walk
> the linked list in the PDIR, examining each entry to see if its VPN matches
> the one you are looking for (presumably, the one you got a TLB miss on).
> If a match is found, you found it! (And the physical address is
> the PPN (which is based on the PDIR index as you noticed) plus the original
> bottom 11 or so bits (i.e.: virtual pages are aligned on physical page
> boundaries).
> 
> (I emailed a little more to him)

I hope you included a note that the format of the PDIR can differ from
release to release.  As new boxes are released, the factory occasionally
changes the PDIR to keep take advantage of new features and performance
opportunities.

--

Paul Gootherts, pdg@cup.hp.com
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: IEEE Mass Storage Ref Model
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Fri, 22 Jan 1993 13:23:19 GMT

In article <9301212224.AA16408@enet-gw.pa.dec.com> mek@hydrox.enet.dec.com (Mark Klamerus) writes:
>
>	Can someone tell me what this is?  I recently had a question
>	regarding this in a pros/cons relation to SQL/Database.
>
>	What is this model/methodology?  Does it have a number?
>	Is there documentation regarding this on the net?

We featured this in the mass-storage survey we did in Parallelogram
May/June 1992; the contact numbers and email address are still in our
contact list in this (Dec/Jan) issue.

Tel: +1 510 422 4323
Fax: +1 510 423 8715
Email: ieee-mss-request@nas.nasa.gov

To quote from the opening para:

``To help promote the interchangability and interoperability that users
expect in the increasingly `open' computing environment, the IEEE is
putting together a reference model describing the philosophy and detail
of mass storage.  Most manufacturers in this market are using it as a
standard.''

Damon
-- 
Damon Hart-Davis        London, UK        Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.36] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Newsgroups: comp.arch
From: reyniers@prl.philips.nl (reijnierse p)
Subject: Re: MFLOP for some old machines.
Organization: Philips Research Laboratories, Eindhoven, The Netherlands
Date: Thu, 21 Jan 1993 11:46:35 GMT

In article <1993Jan20.225851.1@cc.curtin.edu.au> zrepachol@cc.curtin.edu.au writes:
>In article <1993Jan19.180916.19186@qucis.queensu.ca>, wong@qucis.queensu.ca (Tak Shing Wong) writes:
>> Hi, 
>> 	Please forgive me if the following question is already is
>> any FAQ. 
>> 	Can someone please tell me the performance for the
>> following machines in terms of MFLOP,
>> 1) uVax
>
>About .3. Hard to stick a good number on it, as many instruction are emulated.
>
>> 2)Sun3/75
>> 3)Vax 780
>
>1. give or take eta. If its SPEC, its is DEFINED to be 1
>
>> 4) Sun3/16/FPA
>> 5)Dec 8600
>
>3 or so. The numbers will differ from 3x a 780, acording to which instruction
>mix you use for the measurement.
>
>~Paul
>
If you mean Linpack MFLOPS the numbers are:

uVAX II      .13
SUN 3/50     .087 (with 68881 fp processor)
SUN 3/160    .10    "     "    "   "
VAX 780 FPA  .11
DEC 8600     .48

Piet Reijnierse

-- 
Piet Reijnierse                      Philips Research Laboratories
tel. +31 40 743972                   Building WYp room 4
fax  +31 40 744810                   Prof Holstlaan 4
email: reyniers@prl.philips.nl       5656AA Eindhoven
From: pries@mti.sgi.com (Paul Ries)
Newsgroups: comp.arch
Subject: Re: Harvard Architecture
Date: 26 Jan 93 01:36:49 GMT
Organization: Silicon Graphics, Inc.
NNTP-Posting-Host: meter.mti.sgi.com

savel@hal.COM (Bharat Baliga-Savel) writes:

>hmmm! i was under the impression that it was specifically a separate 
>Instruction Cache and Data Cache. 
>-- 

I think a lot of people use it that way now, but the term predated the
use of caches.  For example, when I was back at Intel many of the
microcontrollers had a EPROM instruction store and a data RAM array...
neither memory could be used for another purpose. This was called a
Harvard architecture at the time (though I'm sure by that time caches
existed).
-- 
-Paul Ries DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	pries@mti.sgi.com                 Phone:	415-390-4481 
USPS: 	Silicon Graphics Computer Systems, MS 10L-135 2011 N. Shoreline Blvd,
	Mountain View, CA 94039-7311
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: HOw many PC's make an Amdahl mainframe
Date: 27 Jan 93 19:32:25 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1993Jan27.024351.17902@news.arc.nasa.gov>, lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:

| Actually, though, there are plenty of problems that require the largest 
| available power, and, in the commercial world, there are an increasing
| number of really big applications (e.g. VISA-type credit cards) which,
| generally, need an increasing number of transactions-per-second.  Anyone
| tried to buy anything with a VISA card the last week before Christmas?
| The wait can be rather long.   Credit card companies, Airline Reservations, 
| banks with ATM applications, you-name-it.  All have increasing needs for
| systems with expanding transaction rates.  A system which can do 2000 
| transactions/sec may indeed be worth a *lot* more than 200 systems which 
| can do 10 trans./sec.

  So who's doing the research on this? Obviously there will always be
problems which need a lot of peak TPS, and I doubt that making bigger
machines will prove practical for long.

  Just as scientific calculation has gone parallel, I would expect some
distributed TPS to be coming, but I sure see a lot of bigger and bigger
iron rather than cheap solutions you can put on a network of smaller
systems. I count vector processors as parallel for this discussion,
because they bypass the limitation that N operations take N times
longer than one operation.

  Recently we have seen PVM running here, a program which allows a user
to spread a problem over many machines while flooding the network and
bringing all the machines in question to a grinding halt. Has someone
done a similar program for TPS which I've missed? 

  The solutions I've seen are not seamless, don't scale well, and fail
to provide database consistency able to meet the standards I see met
with single machine systems.


-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	A terible poker player can have a great hand,
	A obnoxious fool can have a good idea.
	Both are winners, regardless of who has them.
From: limes@straylight.eng.sun.com (Greg Limes)
Newsgroups: comp.arch
Subject: Re: Want Sun 2000 info
Date: 21 Jan 93 17:02:55
Organization: Sun Microsystems Computer Corporation (Mountain View, California,
	USA)
NNTP-Posting-Host: straylight
In-reply-to: pas@jupitercmc.ca's message of 19 Jan 93 21:20:26 GMT

In article <1993Jan19.212026.11480@venus.ic.cmc.ca> pas@jupitercmc.ca (Peter Stokes) writes:

|   Hi.  I'm looking for technical (read non-sales) info
|   on the Sun 2000 machine.   I'm looking for a description
|   of the architecture, including processor and memory 
|   organization, the new Sun bus (whatever its called) and
|   the like. 

Wander over to ftp.uu.net:/systems/sun/papers/SunPerfOv+references
via anonymous ftp, lots of good stuff there. In particular, the
directory "SPARCcenter2000_Arch.Z-split" probably has what you want.

I'm just starting to read it myself, but so far it looks like it
has quite a bit of good solid detail.
--
   Greg Limes						[limes@eng.sun.com]
Not speaking for Sun Microsystems Computer Corp., Mountain View, California
Newsgroups: comp.arch
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Subject: Alpha 21064-AA chip manual
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group
Date: Thu, 21 Jan 1993 17:02:28 GMT


The "DECchip 21064-AA Microprocessor Hardware Reference Manual" just arrived
on my desk, so it's evidently now available.  Order number EC-N0079-72.

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97, FAX +33 92.95.52.00
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: HOw many PC's make an Amdahl mainframe
Date: 28 Jan 93 18:28:41 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

To answer the question someone asked, a large database is one with more
than 2^32 bytes. Addressing becomes a major ugly mess at that point.
For the end user, perhaps actually at 2^31 if you C, since the offset
is signed.

I doubt that faking offsets in BCD, or as extents, or whatever is
consistent with high performance and bug-free code.

Our RAM and disk have outgrown the word size in a decade. The original
XT had 10MB, today servers with multiple 2.3G drives, or even RAIDs of
1.3 or 2.3G units are not unheard of.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	A terible poker player can have a great hand,
	A obnoxious fool can have a good idea.
	Both are winners, regardless of who has them.
Newsgroups: comp.arch
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: HOw many PC's make an Amdahl mainframe
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL8]
Date: Thu, 28 Jan 1993 04:10:39 GMT

John R. Levine (johnl@iecc.cambridge.ma.us) wrote:

: Maybe and maybe not.  I've seen plausible claims that when you're handing
: data bases, 10 systems of capacity N are no substitute for one system of
: capacity 10N, mostly because the slower systems hold each lock 10 times as
: long so you get considerably more lock contention.

How about interrupt processing ability? Shouldn't PCs be able to handle more
interrupts than a mainframe?
	My initial rough study do not indicate a clear lead but my gut feelings
tell me that this should be.
	Anyone had done a more concerete study on this?

: Is there any reason to think this isn't true?  I realize that for slowly
: changing data, e.g. schedules and fares in an airline system, you can
: replicate and partition the data, but they do that on mainframes, too.


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Want Sun 2000 info
Date: 26 Jan 93 21:48:26 GMT
Organization: Auspex Systems, Santa Clara

>actually, I've another question.  Why doesn't sun sell an MBUS card 
>with the Ross CY7C620???

Because, as far as I know, there are no production Mbus cards with
7C620's on them.

They might also have to do a new PROM release *and* a new OS release to
support the 620/625, unless the SS690 and/or SS10 PROMs, and the current
OS releases, already know about Pinnacles^H^H^H^H^H^H^H^H^HhyperSPARCs.
I don't know if those PROMs, or if the 4.1.3 or 5.1 releases, know about
them.

If your question was intended not to be read as "why don't Sun currently
sell ...?", but as a suggestion that Sun sell them when they come out,
well, they might, or they might not; you'd have to ask them.
Newsgroups: comp.arch
From: phr@telebit.com (Paul Rubin)
Subject: Re: How many PC's make an Amdahl mainframe
Organization: Telebit Corporation; Sunnyvale, CA, USA
	<1993@niktow.canisius.edu> <128R02pn34lx01@JUTS.ccc.amdahl.com>
	<1993Jan28.222537.15330@chpc.utexas.edu>
Date: Fri, 29 Jan 1993 03:56:29 GMT

In article <1993Jan28.222537.15330@chpc.utexas.edu> apas611@chpc.utexas.edu (David Boles) writes:

   It is Friday afternoon, 5:30 pm Central time and your system jocks notice
   a problem on your central system.  This system _is_ your business (10Billion
   a year, lets say) and you can tolerate essentially _no_ downtime.

   Your sys jocks isolate the problem to a particular process, but don't know
   whether resetting will solve the problem.  You call the company and they
   [go to great lengths to fix the problem]

   Suppose you have PC's:
   you call Microsoft (not even toll-free) and get told that the next upgrade
   might fix that...

   You have workstations:

   you call your Sun support group etc...


You have PC's or workstations but run a system that you have source
code for, like GNU or BSDI:

Your system jocks fix the problem without needing to depend on
the mercy of some vendor!