HDTenEightyP/NetNews huggingface dataset:
From: tal@Warren.MENTORG.COM (Tom Limoncelli)
Newsgroups: comp.misc
Subject: Re: A Paper on the Social Forces Behind the Development of Usenet
Date: 14 Dec 1992 15:02:52 -0500
Organization: Mentor Graphics -- IC Group
NNTP-Posting-Host: milk.warren.mentorg.com

In <75526@apple.apple.COM> chuq@Apple.COM (Eeyore's Evil Twin) writes:

>tal@Warren.MENTORG.COM (Tom Limoncelli) writes:

>>In article <1992Dec10.192501.181@blaze.cs.jhu.edu> arromdee@jyusenkyou.cs.jhu.edu (Ken Arromdee) writes:

>>*plonk*

>>No.    No no no.

>>Let's try this again.

>Tom, you may not have noticed. You're arguing with Ken Aroomdee. Logic won't
>work. Try hallucinatory drugs or something, it'll have a better chance.

Silly me.  I'll go flog myself immediately.

>            Chuq "IMHO" Von Rospach, ESD Support & Training (DAL/AUX)
>                      Member, SFWA =+= Editor, OtherRealms
>                chuq@apple.com | GEnie: MAC.BIGOT | ALink:CHUQ 

>                       Sterling Holloway: We'll miss you.

Fred Holloway:  We'll miss you.  (anyone else know who he is?)

Tom
-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
Reality is stranger than fiction #943247:  The IRS granted
ANS approval as a 501c3 "charity" on September 14, 1992.
Newsgroups: comp.misc
From: <MAAN-HHH@finou.oulu.fi>
Subject: Acer Power upgrade prices in the U.S.A
Organization: University of Oulu, Finland
Date: Mon, 14 Dec 1992 16:06:47 GMT

Could somebody tell the upgrade prices for Acer Power 386sx
(--> 89486). My friend is going to visit N.Y. and he could
bring one upgrade unit for me here in Finland.
Thanks, Harri
Newsgroups: comp.misc,news.misc,comp.bbs.misc,alt.amateur-comp,alt.culture.usenet
From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Subject: Re: A Paper on the Social Forces Behind the Development of Usenet
Keywords: Usenet Pioneers Democracy News grass roots
Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland
Date: Wed, 16 Dec 1992 10:53:29 GMT

In article <75525@apple.apple.COM>, chuq@Apple (Eeyore's Evil Twin) writes:
>hansm@cs.kun.nl (Hans Mulder) writes:
>
>> We all know the Death of Usenet is imminent.
>
>And has been since 1981. 
>
>>Film at 11.
>
>If it survives that long.
>
>chuq (one of these days, of course, we'll be right, too)

Only the U.S. part will die, but the U.S. people will think that it's
all dead.  Only some wild rumors will propagate, partly by the heroic
soldiers who dare to visit the Great Satanic Unknown to defend the One
True God's Way of Vaterland - and partly by a few oldtimers who will
remember how once upon a time there was a way to freely communicate
with the Great Unknown which had intelligent life and nice people
similar to the ones in Vaterland.  In vain the oldtimers will try to
convince others that once the people behind the oceans were nice and
it was good to share one's ideas with them, but no one under 50 will
believe them and if they keep talking too much about it they'll find
themselves in a camp, in grave, or in a mental hospital.

//Jyrki
Newsgroups: comp.misc
From: tfj@apusapus.demon.co.uk (Trevor Jenkins)
Subject: Specifications for image formats
Distribution: world
Organization: Job hunters use Parachute
Date: Fri, 18 Dec 1992 20:28:33 +0000

I'm looking for the ``formal'' specifications for common image formats, eg
TIFF; JPEG and any other format in common usage. I have the GIF formats
(both 87 and 89) but I need the others as well.

Any pointers to as to where to get (machine-readable) copies of defining
documents from would be much appreciated.

Regards, Trevor.

---------------------------------------------------------------------------
Trevor Jenkins                                                Re: "deemed!"
134 Frankland Rd, Croxley Green, Rickmansworth, WD3 3AU, England
email: tfj@apusapus.demon.co.uk                               radio: G6AJG  
phone: +44 (0)923 776436
From: rob@phavl.UUCP (Robert Ransbottom)
Newsgroups: comp.misc
Subject: Literate Programming
Summary: Help! Info on tools.
Keywords: cweb web weave tex c++ literate unix 386ix
Date: 18 Dec 92 20:47:19 GMT
Distribution: na
Organization: erehton

I'm not finding the right Readme, Faq, etc. files.  So:

I have heard stray bits about cweb, literate programming.  
There are web versions suitable for c++ (funnelweb & spiderweb).
My understanding is that a web is a conceptual 
advancement upon the folding editor.

I'm interested in trying it.  This would be a shoestring
project, i.e. a book or two & ftp'able files.

What would I need to run *web on a Sys V rel. 3.2 (386ix) system?
Software? -- is tex required, X, etc?
Difficulty level to get this up?
Hardware?
Recommended reading? 

Thanks for any advice.

-- 
--
rob   Robert Ransbottom
"It is extremely important to maintain correct attributions." -- anonymous
From: CIR_TLW@VAX1.UTULSA.EDU (Tristia Watson)
Newsgroups: comp.misc
Subject: Problem, need ideas...
Date: 15 Dec 1992 11:19:04 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

Greetings!

We have a problem that has exhausted our local resources, any ideas from
the Internet community would be greatly appreciated!  We have a 386 Clone
that was configured to load DEC Pathworks and then launch Microsoft Windows
3.0.  The person who was on the computer was trying to clean up the PC by
using the File Manager. While moving some files, the PC locked up.  She
rebooted the machine.  When the machine came back up, the Pathworks
software was loaded and Windows was called.  The Windows banner page came
up and then a DOS prompt showed up in the upper left-hand corner of the
screen.

We have reinstalled Windows, copied all INI files from another machine to
this one with the same result.


Ideas/Suggestions/Comments/HELP!

    +---------------------------------------------------------------------+
    | Tristia Watson                              CIR_TLW@VAX1.UTULSA.EDU |
    | Client Support Coordinator                     HELP@VAX1.UTULSA.EDU |
    | Computing & Information Resources Help Desk        Phone:  631-3500 |
    +---------------------------------------------------------------------+

Xref: sparky comp.misc:4559 news.misc:2014 comp.bbs.misc:1500 alt.amateur-comp:309 alt.culture.usenet:954
From: c23st@kocrsv01.delcoelect.com (Spiros Triantafyllopoulos)
Newsgroups: comp.misc,news.misc,comp.bbs.misc,alt.amateur-comp,alt.culture.usenet
Subject: Re: A Paper on the Social Forces Behind the Development of Usenet
Date: 11 Dec 92 19:08:11 GMT
Organization: Delco Electronics Corp.

In article <landers.122.724097300@comm.mgmt.purdue.edu> landers@comm.mgmt.purdue.edu (Hazard Class Mage) writes:
>Bill Clinton was not elected by the will of the majority.  He was elected 
>according to rules designed to _prevent_ the popular will of the people from 
>determining our national leader.  

Ouch. Too much Rush Limbaugh there?

>Usenet is as much a representation of democracy as is the United States.

Hey, let's take this a step further. Let's form the FIRST EVER USENET CABINET, 
with cabinet positions assigned to various Usenet personalities...

Then we can do away with Congress (replace with RFD, CFV, etc), voting,
(vote-yes@congress.org / vote-no@congress.org), etc, etc.

:-)

Spiros (Clear Choice for USENET Ambassador to Greece)
-- 
Spiros Triantafyllopoulos                    c23st@kocrsv01.delcoelect.com
Software Technology, Delco Electronics       (317) 451-0815
GM Hughes Electronics, Kokomo, IN 46904      [A Different Kind of Disclaimer]
Xref: sparky comp.misc:4635 news.misc:2055 comp.bbs.misc:1571
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.misc,news.misc,comp.bbs.misc
Subject: Re: A Paper on the Social Forces Behind the Development of Usenet
Date: 18 Dec 92 01:01:26 GMT
Followup-To: comp.misc,news.misc,comp.bbs.misc,alt.amateur-comp,alt.culture.usenet
Organization: negligable

In article <1992Dec13.235743.29851@blaze.cs.jhu.edu> arromdee@jyusenkyou.cs.jhu.edu (Ken Arromdee) writes:
>In article <19921213.003@erik.naggum.no> Erik Naggum <enag@ifi.uio.no> writes:
>>[Tom Limoncelli]
>>|   I think the author of this paper should go back and re-read the FAQ
>>|   on what Usenet is NOT.
>>[Ken Arromdee]
>>|   Your own argument betrays you here.  Since Usenet is an anarchy,
>>|   there's no real reason he should accept that FAQ as an authoritative
>>|   description of Usenet.
>>Sorry, but you've got "anarchy" all wrong.  Anarchy means "no ruler", or
>>"no ruling power".  It does _not_ mean "no rules", or "no authorities".
>>All it means is "absence of a legally sanctioned force to make people
>>obey rules or authorities".  However, people living in an anarchy like
>>order and strive to create it as much as anywhere else, i.e., they will
>>obey rules and authorities when they find them to be productive to their
>>ends.  The neat thing with an anarchy is that its members can _choose_
>>the rules and authorities, on an individual basis.
>
>Then: there is no real reason why he should _choose_ to accept that FAQ as
>authoritative.  At least, no a priori reason.

Correct.  Except for the practical: that it makes life on the net
easier since many people DO use the FAQ as a reference/guideline.

>I personally am somewhat skeptical about the use of FAQ's to give definitive
>answers to disputed issues.

Also true.  Since FAQ posters are a self-selected bunch, there is 
nobody to prevent someone writing a conflicting FAQ and posting
it on a regular basis.  Except that an unpopular FAQ would probably
be quickly discredited, and someone would set up an automatic poster
that would always follow up the "bogus FAQ" with nasty messages.

Of course, there is nothing to stop such an automatic reaction to
the "real" FAQ either....

(I hope I'm not giving any new ideas to anybody......)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lazy day, Sunday afternoon.			|
Like to get your feet up, watch TV.		|	-Richard Hartman	
Sunday roast is something good to eat,		|	hartman@uLogic.COM
must be lamb to day 'cause beef was last week!	|
Xref: sparky comp.benchmarks:1871 vmsnet.alpha:47
From: jl@geoblue.gcn.uoknor.edu (Jay Liang)
Newsgroups: comp.benchmarks,vmsnet.alpha
Subject: DEC 7000-610 Alpha AXP LINPACK benchmark anomaly
Date: 15 Dec 92 22:48:33 GMT
Article-I.D.: constell.BzBooy.6w2
Reply-To: jay@alliant.backbone.uoknor.edu
Organization: University of Oklahoma, Norman OK
Originator: usenet@midway.ecn.uoknor.edu

Earlier I posted an observation concerning DEC 7000-610 Alpha AXP
LINPACK benchmark anomaly.  Here is what I just received from Jack
Dongarra.

> From dongarra@cs.utk.edu Tue Dec 15 16:18:32 1992
> Received: from thud.cs.utk.edu by alliant.backbone.uoknor.edu (Concentrix 6.0/1.35/jl-2.1)
> 	id AA22773; Tue, 15 Dec 92 16:18:28 CST
> Received:  by thud.cs.utk.edu (5.61++/2.7c-UTK)
> 	id AA16656; Tue, 15 Dec 92 17:17:45 -0500
> Date: Tue, 15 Dec 92 17:17:45 -0500
> From: dongarra@cs.utk.edu
> Message-Id: <9212152217.AA16656@thud.cs.utk.edu>
> To: jay@alliant.backbone.uoknor.edu
> Subject: Re: LINPACK benchmark question
> In-Reply-To: Mail from 'Jay Liang <jay@alliant.backbone.uoknor.edu>'
>       dated: Mon, 14 Dec 1992 17:30:53 -0600 (CST)
> Status: OR
> 
> Thanks for pointing that out. The correct number should be:
> DEC 7000-610 Alpha AXP(182 MHz)&3.2 inl=daxpy,ur=4,ur2=240&  39 &  102 &  182 \\
> It was a typo.
> Regards,
> Jack


-- 
Jay Liang
jay@alliant.uoknor.edu
Newsgroups: comp.benchmarks,comp.arch,comp.misc
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: Who wants faster machines?
Organization: Keith's Computer, Hope Mills, NC
Date: Thu, 17 Dec 92 03:59:31 GMT
Followup-To: comp.misc

In article <1992Dec4.103129.524@fasttech.com> zeke@fasttech.com (Bohdan Tashchuk) writes:
>In <1f2qefINNfaq@uranium.sto.pdb.sni.de> mollers.pad@sni.de (Josef Moellers) writes:
>
>>I'd say that 60% of all added performance is easily
>>souped up by improvements in the man-machine interaction.
>
>>THAT's what we need fast machines for!
>
>About 20% is useful improvement and about 80% counteracts software bloat.
>
>The architects and h/w guys keep making machines faster and faster and the
>software keeps getting less and less efficient.

Sofware bloat, software bloat, naa, naa, 'naa, naa, ..., naa.

Jeez.

I look at some of the code I wrote for my Z80 in assembler.  Zillions of
hours, for not much of a program.  Spaghetti code to the max. 
Commented, and I STILL can't follow what I was doing.  With the current
cost of cheap storage, and CPU cycles, I'll gladly take a little
software bloat, for simple readability, and maintainability, along with
avoiding alot of hand coding in assembler for speed & size.

I'll also disagree with the 20/80 ratio you have come up with, as it
relates to performance.  What we are seeing today in the business world
are *STABLE* *RELIABLE* database systems that run on commodity hardware,
in a flexable enviroment.  This same functionality 15 years ago would
have required an IBM 34/36 style equivilance, with comperable amounts of
fixed storage. Indeed, I replaced same with a 33Mhz 32 bit "pee cee", as
opposed to a 16Mhz 32 bit Midrange.  The performance was *FAR* in excess
of doubled, and yet the storage requirements, and program sizes actually
SHRUNK.

As the software that runs more complicated systems get's more
complicated (multi-user, multi-task, journaling filesystems, graphical
interfaces, real-time processing ...) the programs *HAVE* to increase in
complexity at a similar expotential rate.  The number of interactions
between different software modules will increase expotentially also, as
you add on new modules to handle ever more complex tasks, as each task
that gets effected will increase in size.

Writing spaghetti code that weaves thru 50 sections of code blind fast
is great, and you can probably follow it.  Writing same thru 1000
sections of code is simply idiotic to consider.  In turn the code in
each section will swell, as it handles more function in order to
insulate itself from a breakdown elsewhere, then splits, etc.  Is it
bloat?  Yes.  Is it bad? No, simply a neccessary part of software
evolution IMHO.  Does it affect performance?  Sure!  Now we can run the
machines all day without reseting it 5 times ...
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Newsgroups: comp.benchmarks
From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
Subject: [l/m 3/17/92] Measurement environments		(12/28) c.be FAQ
Keywords: who, what, where, when, why, how
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Sat, 12 Dec 92 12:25:15 GMT
Reply-To: eugene@amelia.nas.nasa.gov (Eugene N. Miya)

12	Measurement environments			<This panel>
13	SLALOM
14
15	12 Ways to Fool the Masses with Benchmarks
16	SPEC
17	Benchmark invalidation methods
18
19	WPI Benchmark
20	Equivalence
21	TPC
22
23
24
25	Ridiculously short benchmarks
26	Other miscellaneous benchmarks
27
28	References
1	Introduction to FAQ chain and netiquette
2
3	PERFECT
4
5	Performance Metrics
6	Temporary scaffold of New FAQ material
7	Music to benchmark by
8	Benchmark types
9	Linpack
10
11	NIST source and .orgs

Benchmarking environments
Taxonomy described by: A, B, C, D, E
Examples:
	A Cray Y-MP or better with integrated hardware performance monitor
	B Cray-2, Convex C-1/C-2...
	C VAX-11/780, IBM PC, IBM 370-class
	D Apple II, Timex Sinclair
	E Incomplete hardware, chip, module, board-level

An A environment should have state of the art hardware and
software to aid benchmarking.  Hardware should be minimally or non-intrusive.
This category should change with time.  The SS-1 should have a
more programmable HPM, this would lower the Y-MP down into
a B environment (can stay A if no other HPM type hardware becomes
predominant).  This is akin to high-precision Cesium clocks.

A B environment is a "good" environment to do benchmarking.
It has as a minimal, a near cycle-time clock, profiling software,
etc.  The environment at this level or higher may also be more hostile
for measurement.  Good performance is likely to be an issue, so the
compilers will have good optimizers.

A C environment is an "average" benchmarking environment.
This is just typical: a 60 or 100 Hz clock.  Some profiling software.

A D environment is a difficult environment to do benchmarking.
This environment may not have a clock or software to help the poor
benchmarker.  Timing by wrist watch or maybe oscilliscope.
Software? What software?

An E environment:
Another difficult environment to do benchmarking.  It might have software.
It might be an incomplete computer: a processing using of a larger
multiprocessor: it touches on the issue of composition.

If dealing with a simulator:
there maybe an F category for simulated timing.

                   ^ A  
                s / \ r                
               m /   \ c              
              h /     \ h            
             t /       \ i          
            i /         \ t        
           r /           \ e      
          o /             \ c    
         g /               \ t  
        l /                 \ u
       A /                   \ r
        <_____________________> e   
                Language
 
Xref: sparky comp.benchmarks:1874 comp.sys.hp:14120
From: sbchanin@ai.mit.edu (Steve Chanin)
Newsgroups: comp.benchmarks,comp.sys.hp
Subject: Performance of HP 800 series verses 7xx series
Date: 16 Dec 92 03:27:09
Organization: MIT Artificial Intelligence Laboratory
Distribution: world
Reply-To: sbchanin@ai.mit.edu
NNTP-Posting-Host: raisin-nut.ai.mit.edu

I was wondering how the 800 series machines perform compared to the
700 series machines.  Which would be a better choice for a mid size
database?  For a small team of people developing an application (using
emacs, gcc, gdb, maybe Centerline-C)?

Thanks,
Steve
--
===============================================================================
DOMAIN: sbchanin@ai.mit.edu                                       Steven Chanin
Newsgroups: comp.benchmarks
From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
Subject: [l/m 3/17/91] Ways to fool the masses with benchmarks	(15/28) c.be. FAQ
Keywords: who, what, where, when, why, how
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Tue, 15 Dec 92 12:25:10 GMT
Reply-To: eugene@amelia.nas.nasa.gov (Eugene N. Miya)

15	12 Ways to Fool the Masses with Benchmarks	<This panel>
16	SPEC
17	Benchmark invalidation methods
18
19	WPI Benchmark
20	Equivalence
21	TPC
22
23
24
25	Ridiculously short benchmarks
26	Other miscellaneous benchmarks
27
28	References
1	Introduction to the FAQ chain and netiquette
2
3	PERFECT Club
4
5	Performance Metrics
6
7	Music to benchmark by
8	Benchmark types
9	Linpack
10
11	NIST source and .orgs
12	Measurement Environments
13	SLALOM
14

From David Bailey et al.

Quote only 32-bit performance results, not 64-bit results.

Present performance figures for an inner kernel as the performance of the
entire application.

Quietly employ assembly code and other low-level language constructs.

Scale up the problem size with the number of processors, but omit any
mention of this fact.

Quote performance results projected to a full system.

Compare your results against scalar, unoptimized code on Crays.

When direct run time comparisons are required, compare with an old code
on an obsolete system.

If megaFLOPS rates must be quoted, base the operation count on the parallel
implementation, not on the best sequential implementation.

Quote performance in terms of processor utilization, parallel speedup or
megaFLOPS per dollar.

Multilate the algorithm used in the parallel implementation to match
the architecture.

Measure parallel run times on a dedicated system, but measure conventional
run times in a busy environment.

If all else fails, show pretty pictures and animated videos, and don't talk
about performance.

Ref. 1
NAS TR #

Ref. 2
%A David Bailey
%T Twelve Ways to Fool the Masses when Giving Performance Results on
Parallel Computers
%J Supercomputing Review
%V 4
%N 8
%D August 1991
%P 54-55

References
Darrell Huff, How to Lie with Statistics
	How to Lie with Maps

Gordon Bell's 11 rules of supercomputer design:

1) Performance, performance, performance.
2) Everything matters.
3) Scalar matter most.
4) Provide vectors as price allows.
5) Avoid holes in performance.
6) Place peaks in performance.

7) Provide a decade of addressing.
8) Make it easy to use.
9) Build on others work.
10) Design for the next one (and do it again) [three times]
11) Have slack resources.

                   ^ A  
                s / \ r                
               m /   \ c              
              h /     \ h            
             t /       \ i          
            i /         \ t        
           r /           \ e      
          o /             \ c    
         g /               \ t  
        l /                 \ u
       A /                   \ r
        <_____________________> e   
                Language
 
Newsgroups: comp.benchmarks
From: omar@malena.crs4.it (Omar G. Stradella)
Subject: Benchmarks on CM-5
Date: Fri, 18 Dec 1992 16:19:37 GMT
Organization: CRS4, Center for Adv.Studies, Research and Development in Sardinia

Hi there!

Does anybody know of benchmarks on the CM-5 ?. I'm more interested in those
related to quantum chemistry, but anything else will be appreciated. If there
are enough responses, I'll summarize to the net.

Thanks,

Omar
-- 
****************************************************************************
* Dr. Omar G. Stradella    -    Omar.Stradella@crs4.it                     *
* CRS4 - Centre for Advanced Studies, Research and Development in Sardinia *
* Casella Postale 488, 09100 Cagliari CA, Italy                            *
* Phone: +39 70 27 96 415       FAX: +39 70 27 96 400                      *
****************************************************************************
From: jl@geoblue.gcn.uoknor.edu (Jay Liang)
Newsgroups: comp.benchmarks
Subject: DEC7000-610 Alpha AXP LINPACK TPP result anomaly
Date: 15 Dec 92 17:13:51 GMT
Article-I.D.: constell.BzB975.L5u
Reply-To: jay@alliant.backbone.uoknor.edu
Organization: University of Oklahoma, Norman OK
Originator: usenet@midway.ecn.uoknor.edu

In the letest LINPACK benchmark dated December 7, 1992, the TPP result
for DEC 7000-610 Alpha AXP (182 MHz) is listed as 43 MFLOPS, however,
similar benchmark results for DEC 10000-610 (200 MHz) and 4000-610 (160 MHz)
are listed as 112 MFLOPS and 86 MFLOPS, respectively.  Was 43MFLOPS a
typo or was it caused by insufficient memory?

-- 
Jay Liang
jay@alliant.uoknor.edu
Xref: sparky comp.benchmarks:1872 comp.arch:11682
From: martelli@cadlab.sublink.org (Alex Martelli)
Newsgroups: comp.benchmarks,comp.arch
Subject: Re: DEC ALPHA Performance Claims
Date: 14 Dec 92 09:45:08 GMT
Organization: CAD.LAB S.p.A., Bologna, Italia

wilson@moonshine.llnl.gov (Mike Wilson ) writes:
:martelli@cadlab.sublink.org (Alex Martelli) writes:
:>wayne@backbone.uucp (Wayne Schlitt) writes:
:>	...
:>:This I see has the fatal problem with just providing the cheapest unix
:>:boxes around.  You end up having to compete against PC's and that's
:
:>The cheapest unix box around tend to BE PC's.  I just bought a no-name 
	...
:>What significant plus can one envisage, if not speed?
:
:uh, how about an integrated system that has fewer overall bugs & much
:better product support?  A system that you don't spend dozens (if not
:hundreds) of man hours doing hardware debugging trying to get your latest
:card to work with?  For "real" work, I'd stick with a stable system.

Compaq hw + SCO sw, or Dell hw+sw, &tc, can offer you integration and
support, but, yes, the prices do tend to edge up a bit higher (not so
much for the hw, high-end PCmakers are having to shave down their
prices a lot too, but for the "branded" Unix sw).  So, ok, plug-and-play
CAN be an arena for WS manufacturers to compete in against PC's in
ways not purely speed-related...
-- 
Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 
Newsgroups: comp.benchmarks