HDTenEightyP/NetNews huggingface dataset:
From: jon@theta.ee.ufl.edu (Jon Mellott)
Subject: Re: Def  of a workstation (a lark)
Originator: jon@theta.ee.ufl.edu
Organization: EE Dept at UF
Date: Thu, 7 Jan 93 14:35:57 GMT


In article <C0GJzC.GFJ@metaflow.com>, rschnapp@metaflow.com (Russ Schnapp) writes:
|> In article <1993Jan6.165640.2894@lsl.co.uk>, snail@lsl.co.uk writes:
|> |> On a workstation, software does not worry about how much memory it has; just
|> |> page it out to disk. Microsoft windows can release memory and re-read it from
|> |> the disk, but it can't page memory *out* to the disk (not unless it changed
|> |> recently).
|> 
|> Not terribly recently -- Windows 3.1 has fully virtual memory in
|> "enhanced mode".  (For some reason, they limit virtual memory to twice
|> the size of physical memory.)  I believe that 3.1 has been out for a
|> year or so.

Well, actually, Windows v3.0 has paged virtual memory in "386 enhanced mode". 
The "discardable segment" scheme of memory management where program and 
static resource segments are discarded to free memory and later re-read was 
there for 286 and lower machines. 

Jon Mellott
High Speed Digital Architecture Laboratory
University of Florida
(jon@alpha.ee.ufl.edu)
Newsgroups: comp.arch
From: diaz@oakhill.sps.mot.com (Rafael Diaz)
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Organization: Motorola Inc., Austin Tx.
Date: Tue, 12 Jan 1993 20:08:33 GMT

In article <1993Jan11.170917.7216@impmh.uucp> dsg@impmh.uucp (Dave Gordon) writes:
>In <RABIN.93Jan7132015@nuthatch.CS.Yale.Edu> rabin@CS.Yale.Edu (Dan Rabin) writes:
>
>>According to a book I have read that explains the Arabic alphabet,
>>numerals in Arabic documents are written most-significant-digit
>>leftmost, whereas the text itself is written from right to left.
>>Hence the native reader encounters the least-significant digit first
>>in his or her accustomed reading order.  There's no reason to believe
>>that Arabic-speaking arithmetic has suffered as a result.
>>
>> [...]
>>
>>  -- Dan Rabin (rabin-dan@cs.yale.edu)
>
>I believe that in Arabic and Hebrew (both read right to left),
>numbers are also spoken least-significant-digit first e.g. 345
>is read as five-and-four-tens-and-three-hundreds.
>
>So their system is completely consistent, *and* doesn't require
>pre-scanning the number to find which radix power to start at.
>The disadvantage, of course, is that you don't know the magnitude
>of the number until the very end of the reading process.
>
>[Imagine a phone call from your accountant in Arabic or Hebrew ...
>Accountant:	You have made pretax profits of $hekels three and forty
>		and six hundred and nine thousand.
>You:		Good!
>Accountant:	And your tax liability is $hekels nine and thirty and
>		four hundred ...
>You:		Excellent!
>Accountant:	... and eight thousand!
>-- 
>Dave | dsg@imp.co.uk | +44 753 516599 | I am not a .sig virus, I am a free bug!

CORRECTION:

Hebrew numerals are WRITTEN and SPOKEN the same as in English. Although
the text is going right to left. A simple scan will have to encounter a
number, and reconstruct it left to right. The same can be apllied to
Arabic.

In Hebrew when you pronounce e.g. 345, it will go 'three-hundred-fourty-five'
(Heb. shelosh meot, arbaim vechamesh). In Arabic it will be pronounced:
'three-hundred-five-and-fourty'! (Arb. tlata me'a, chamsa waarbaim).
Now this is confusing.

--Rafy
-- 
________________________________________________________________________
		       __        _    
  =_   __   ___    =  /  )      / )   ==========   diaz@sigi.sps.mot.com
 =  ) /_ )     )  =  /--<  _  -/-     == oakhill!sigi!diaz@cs.utexas.edu
From: mshute@cs.man.ac.uk (Malcolm Shute)
Newsgroups: comp.arch
Subject: Re: uniprocessor design ceiling
Date: 6 Jan 93 11:59:03 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

In article <1993Jan3.215458.7960@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:
>If (as I have been led to believe) there
>exists a linewidth which is large enough for yield to be effectively 100%,
                                                          ^^^^^^^^^^^
You quite rightly recognise that it never exactly reaches 100%...
it's just an exponential curve which at some arbitrarily defined 'knee'
you decide to treat it as being negligably close to 100%.
So... if you're going to do something drastic, like multiplying the number
of process steps by a couple of hundred, you will not be surprised to find
the position of this knee moving.
[I've never really understood how people manage to read 0.7V as the position
of the knee of the exponential function which is supposed to characterise
the IV curve for a silicon PN junction... you only need to get a magnifying
glass out, and the point at which the curve really starts to break away from
the I-axis moves :-]

>why hasn't anybody attempted to build a very tall, large line width chip?
>Is the problem a difficulty in creating monocrystaline Si above the substrate?
>Are problems with planarization cumulative such that working with too many
>levels becomes impossible?
                                                  -k
It is tempting for me to write:  Y = ( 1 + A.D/k )
where:  Y = circuit yield
        A = circuit area
        D = fault density
        k = number of process steps

It is one of those theoretically-reasoned models which abound in yield modelling.
Unfortunately, Stapper indicates that, tempting though its arguments are, it
bears no correlation with any experimental results that he has gathered.
Instead, he, and most in the industry, appear to favour the negative binomial
model, which appears:                   -a
                       Y = ( 1 + A.D/a )
Where 'a' is an empirically measured 'clustering coefficient'.  It is going to
have the effect of rising to kill your 1000-processing-step 3D process, but not
in quite the obvious linear way that the Y=(1+AD/k)^(-k) would have suggested.

[If you want to persue Stapper's excellent review paper on yield models, it is:
Stapper, C.H. (1989).
'Fact and fiction in yield modeling',
"Microelectronics Journal",
Vol. 20(1), pp 129-151.]
--

Malcolm SHUTE.         (The AM Mollusc:   v_@_ )        Disclaimer: all
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 5 Jan 93 17:15:11 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <1hquujINNmov@fido.asd.sgi.com>, pj@sam.wpd.sgi.com (Paul Jackson) writes:
> In article <28164@dog.ee.lbl.gov>, torek@horse.ee.lbl.gov (Chris Torek) writes:
> |> 01101001 may mean `105' (big-endian) or `150' (little-endian)
> 
> Big and little endian refer to the order of bytes within words,
> not to the order of bits within bytes.

That is a convention in *your* head. There is no reason why big endian can't
be made to mean to apply to bits if you want. For the purposes of his example, 
he is correct. For human interpretation of binary (at least how I was taught
at school :-) ), you are correct. For various computer architectures, who
knows? I've seen some odd boxes in my time; I'm not even sure it makes sense
at this level anyway, since the circuit designers will ensure the correct
bits get where they're going.

If you remember my post to do with date format a while back I referred to
big-endian and little-endian dates (hmmm, maybe in private email I did, maybe
not on the net). Big and little endian is just a concept.

I do think, in practice, it may be confusing to deal with different ordering
of bits in bytes, but then again in X, the XImage format can have data in
8, 16, 32 bit formats, with MSB or LSB ordering of bytes, and with LSB and MSB
ordering of bits too! Total: 3 * 2 * 2 formats = 12 possible formats for
XImage data. This is an exmaple of big and little endian byte and bit ordering.
This was provided to ensure that most (if not all) systems could represent
XImages efficiently for the particular processor used.
-- 
snail@lsl.co.uk      

"Washing one's hands of the conflict between the powerful and the powerless
 means to side with the powerful, not to be Neutral."
                                                     Quote by Freire.
                                                     Poster by OXFAM.
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: NeXTstep not running on Cyrix 486DLC (was Re: Apple IIGS...)
Date: 11 Jan 93 18:35:08 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <C0Gznx.JCK@wimsey.bc.ca>, bhenning@wimsey.bc.ca (Bill Henning) writes:
>>It should.  A 486 is much faster than a 386 of the same speed.  Case in
>>point: The 486SX/25 (like the one I'm using now) is a little faster than
>>an AMD 386/40, but the 486SX is upgradeable for $450.
>>
>>-- 
>>aj923@cleveland.freenet.edu (So now you listen, 'cause I'm omniscient)
> 
> I am not sure that is the case. Did Byte not run some benchmarks about a
> year ago that showed that a 386/40 consistently beat a 486SX25 on almost
> every bencmark?
> 
> I have an Amd386/40, 64k cache, Cyrix FasMath 387 based machine at home,
> and I don't really notice a speed difference between it and the 486/33
> 256k cache machine I have at work.

Yup, my parents bought a no-name 386/40, roughly same spec as an Evesham Micros
(that is a name in the UK) 486/33 owned by a friend. Both systems had same
memory (4MB) and IDE drives, SVGA 1024x768x256 etc. This friend came round to
see the 386/40 and some software I was developing, he was amazed and reckoned
the difference in speed was negligible (sp?). No major floating point happening
tho!

Get a 386/40 if you can, give your money to non-Intel (ie non monopolisers).
I've got nothing against Intel, but you only see Intel drop their prices to
reasonable levels when they have competition in that market, hence 486 still
being a considerable hike.
-- 
snail@lsl.co.uk      

"Washing one's hands of the conflict between the powerful and the powerless
 means to side with the powerful, not to be Neutral."
                                                     Quote by Freire.
                                                     Poster by OXFAM.
Newsgroups: comp.arch
From: sundaram@birds.eng.uiowa.edu (Subbiah Sundaram)
Subject: Is it posible to implement lock on variables on i860 processors
Date: Mon, 4 Jan 1993 18:20:46 GMT
Organization: Department of Elect. and Comp. Engr., University of Iowa, USA.

Hi,
	I wanted to know whether it is possible to implement shared 
primitives in i860. I am interested in locks implementation on i860.
Is it possible to implement locks on variables? Will it be efficient?
Is there a simulator for the i860 or similar architecture CPU's 
available via public domain facilities.

Thanks,
Subbiah.
From: toon@moene.indiv.nluug.nl (Toon Moene)
Newsgroups: comp.arch
Subject: Re: Def of a workstation (a lark)
Date: 6 Jan 93 21:19:03 GMT
Organization: Moene Computational Physics, Amsterdam, The Netherlands

In article <7114@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute)  
writes:

[ .. much needed: a definition of what comprises a WorkStation :-) ]

> In article <WAYNE.93Jan3184216@backbone.uucp> wayne@backbone.uucp (Wayne 
> Schlitt) writes:
> >* A workstation must be network ready.
> >  This doesn't mean that you can't have one workstation sitting
> >  somewhere, but you must be able to add additional workstations 
> >  easily.

You might say. My workstation is only connected to the mains :-) and its  
own phone connection - the (thin) ethernet and 10T twisted pair ethernet  
connectors are idle ...

> For me, you've hit the nail on the head, here... as did a later poster
> by observing, rather flippantly, that you are more likely to have to 
> login on a workstation than on a PC.

Of course you have to log in to a workstation - it's valuable equipment. A  
PC is for everyone strolling into your room ...

> A personal computer, it would seem to me, is a computer that is for one 
> person's personal use.  A workstation is a station which is available 
> for doing work, presumably by anyone who can demand it.

Almost. A workstation is a computer you'd buy for yourself. A PC is a  
'computer' management buys for you.

> My workstation here is in a locked office... but anyone on the network
> can send work to it, or even remotely login to it.  I would say that if 
> it weren't for this property, that I would have a PC connected to a 
> network. Similary, as Wayne points out, it is equally possible to have a 
> WS which is not (yet) connected to a network... but is ready to be so.

And even if it's not (directly) connected to the network, you still can  
use it for network-like services: I'm perfectly capable of running  
crayperf (Cray Inc.'s system performance monitor) from the C90 of the  
European Centre for Medium Range Weather Forecasts over a SLIP link to the  
X-Window implementation on my home system - It just works. Now try to do  
THAT with a Personal Computer :-)

--
Toon Moene (toon@moene.indiv.nluug.nl)
Kantershof 269, 1104 GN  Amsterdam, The Netherlands
Tel.: + 31 20 6982029; Fax: + 31 20 6003411
No Disclaimers; a NeXT at home protects against this occupational hazard.
Xref: sparky comp.arch:12134 comp.sys.intel:2922
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.arch,comp.sys.intel
Subject: RFI: Fiber Channel OPEN, Holics (repost)
Keywords: fiber, optical, holics, sun, hp
Date: 7 Jan 93 20:12:36 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

Does anyone know if there is a newsgroup and/or distribution list
forum in which there are discussions about the Holics fiber optic
backplane efforts in the EC?  

Also... the Fiber Channel OPEN drive interface which is headed by IBM,
Sun, and HP?

If so, please email or post here.  Thanks!

-- 
|Tom Barrett (TDBear), Sr. Engineer|tom.barrett@amd.com|v:512-462-6856 |
|AMD PCD MS-520 | 5900 E. Ben White|Austin, TX  78741  |f:512-462-5155 |
|"No is yes, And we're all free" ---Tracy Chapman, "Why?"              |
|My views are my own and may not be the same as the company of origin  |
Newsgroups: comp.arch
From: NetCmmnd@boole.uucp (System Administrator)
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Organization: Boole & Babbage, Inc.
Date: Tue, 12 Jan 1993 17:53:48 GMT

There are those of us to this day who call 
the disk scheduling algorithm sometimes called
elevator, bustrophedon.

John Ahlstrom      
Boole & Babbage

I can neither confirm nor deny
that these opinoins are or are not
held by anyone else.

Newsgroups: comp.arch
From: dsg@impmh.uucp (Dave Gordon)
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Organization: Integrated Micro Products Ltd
Date: Mon, 11 Jan 1993 17:09:17 GMT

In <RABIN.93Jan7132015@nuthatch.CS.Yale.Edu> rabin@CS.Yale.Edu (Dan Rabin) writes:

>According to a book I have read that explains the Arabic alphabet,
>numerals in Arabic documents are written most-significant-digit
>leftmost, whereas the text itself is written from right to left.
>Hence the native reader encounters the least-significant digit first
>in his or her accustomed reading order.  There's no reason to believe
>that Arabic-speaking arithmetic has suffered as a result.
>
> [...]
>
>  -- Dan Rabin (rabin-dan@cs.yale.edu)

I believe that in Arabic and Hebrew (both read right to left),
numbers are also spoken least-significant-digit first e.g. 345
is read as five-and-four-tens-and-three-hundreds.

So their system is completely consistent, *and* doesn't require
pre-scanning the number to find which radix power to start at.
The disadvantage, of course, is that you don't know the magnitude
of the number until the very end of the reading process.

[Imagine a phone call from your accountant in Arabic or Hebrew ...
Accountant:	You have made pretax profits of $hekels three and forty
		and six hundred and nine thousand.
You:		Good!
Accountant:	And your tax liability is $hekels nine and thirty and
		four hundred ...
You:		Excellent!
Accountant:	... and eight thousand!
-- 

===============================================================================
Dave | dsg@imp.co.uk | +44 753 516599 | I am not a .sig virus, I am a free bug!
===============================================================================
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Newsgroups: comp.arch
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 11 Jan 93 15:30:13 GMT
Reply-To: vhs@rhein-main.de

In article <CARLTON.93Jan7171924@scws1.harvard.edu> carlton@scws1.harvard.edu  
(david carlton) writes:
> In article <FY.93Jan7111925@hardwick.lucid.com>, fy@lucid.com (Frank Yellin)  
writes:
> 
> > Of course, how were numbers done in ancient Greek.  It was written in
> > boustrophedon:  the lines alternated left-to-right and right-to-left.
> 
> Some rather old writings were written boustrophedon, but I wouldn't
> present it as the norm.

Why not? IMHO the boustrophedonicity of a written document has nothing
ni egaugnal yna etirw nac ouy .e.i , egaugnal eht htiw reveostahw od ot
a boustrophedonic way. More than that, one might even put composed glyphs
                                                          (-: yaw siht

	Volker

--
Volker Herminghaus-Shirai (vhs@qb.rhein-main.de), NeXTmail welcome

Looks good on the outside, but -
	intel inside
From: ssurawls@susssys1.reading.ac.uk (Ian Rawlings)
Newsgroups: comp.arch.storage
Subject: Cleaning tape streamers
Date: 11 Jan 93 18:17:29 GMT
Organization: University of Reading

I have an Archive Viper 150 meg tape streamer (DC6150 tapes, SCSI) and am
wondering if I will need to clean the thing, if so, how often and how!

Does anyone know?

If so, I would appreciate a bit of info on it!

Thanks in advance...

Ian

-- 

=+=+=+=+=+ 8< =+=+=+=+=+=+=+=+=+=+=+=+ 8< =+=+=+=+=+=+=+=+=+ 8< =+=+=+=+=+=+=+
Mr Ian Rawlings, Telephone Reading (0734) 661431
	EMAIL ssurawls@susssys1.rdg.ac.uk
From: edb@hpgrla.gr.hp.com (Ed Beshore)
Date: Tue, 5 Jan 1993 00:13:32 GMT
Subject: DIS 13346 Conformance Testing
Organization: Hewlett-Packard, Greeley, CO
From: IMAGING.CLUB@OFFICE.WANG.COM ("Imaging Club")
Newsgroups: comp.arch.storage
Subject: Experiences With Alphatronix Optical Jukeboxes?
Date: 11 Jan 93 21:22:55 GMT
Organization: Mail to News Gateway at Wang Labs

Would anyone have any experiences with those Alphatronix optical
jukeboxes?

Michael.Willett@OFFICE.Wang.com
Newsgroups: comp.arch.storage,comp.databases
From: johnson@trwacs.fp.trw.com (Steve Johnson)
Subject: CD-ROM jukeboxes
Summary: Looking for CD-ROM jukebox specifications and experience.
Keywords: CD-ROM jukebox optical robotics
Organization: TRW Systems Division, Fairfax VA
Date: Tue, 12 Jan 1993 19:53:04 GMT

  I'm looking for information on CD-ROM jukeboxes with a capacity of
+50GB, is (preferably) rack mounted, can be equipped with more than
one drive (without throwing any equipment away) in an incremental
manner, and (here it comes) will run in an IBM LanServer (NetBIOS
and all that) environment.  Thanks in advance.

------- Any views expressed are those of myself and not my employer. --------
Steven C. Johnson, WB3IRU / VK2GDS      |
TRW                                     | johnson@trwacs.fp.trw.com
FP1 / 3133                              |         [129.193.172.90]
1 Federal Systems Park Drive            | Phone:        +1 (703) 968.1000
Fairfax, Virginia  22033-4412  U.S.A.   | Fax:          +1 (703) 803.5189
-- 
------- Any views expressed are those of myself and not my employer. --------
Steven C. Johnson, WB3IRU / VK2GDS      |
TRW                                     | johnson@trwacs.fp.trw.com
FP1 / 3133                              |         [129.193.172.90]
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.arch.storage
Subject: Re: Cleaning tape streamers
Date: 12 Jan 93 07:30:19 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <ssurawls.726776249@reading> ssurawls@susssys1.reading.ac.uk (Ian Rawlings) writes:

| I have an Archive Viper 150 meg tape streamer (DC6150 tapes, SCSI) and am
| wondering if I will need to clean the thing, if so, how often and how!

Archive's recommendation is every 30 hours of tape motion, but most
people go way past that.  There are cleaning cartridge that you
can buy, but most people use a quality isopropyl alcohol (*not*
rubbing alcohol!) or 'head cleaning solution' and a cleaning
swab that doesn't shed lint.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.arch.storage,comp.misc,comp.periphs
From: sieber@fraser.sfu.ca
Subject: How to hook up a HSMD drive...
Summary: Any way to hook it to SCSI/MFM?
Originator: sieber@fraser.sfu.ca
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Tue, 12 Jan 1993 19:07:39 GMT


Hi there,
  I have an opportunity to get a hold of a Fujitsu 345 MB HSMD drive
out of an old mainframe, and was wondering if there is any cheap and
easy way to hook up one of these drives to a PC.  Are there any
protocol conversion cards out there to allow you to hook one up to
either a ST-506 or SCSI type interface? (SCSI would be preferred).
Any idea who to talk to about such a thing, or better places to ask
this question?
   E-Mail responses would be preferred, but I'll try to keep an eye on
these newsgroups.

	Thanks in advance,

		-=<Dirk>=-
From: gideony@microsoft.com (Gideon Yuval)
Subject: branch-prediction
Date: 12 Jan 93 00:27:42 GMT
Organization: Microsoft Corporation

How is branch-prediction handled on currently-documented chips?

Thanks
-- 
Gideon Yuval, gideony@microsoft.com, 206-882-8080 (fax:-883-8101;TWX:160520)
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: mike@gordian.com (Michael A. Thomas)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Gordian; Costa Mesa, CA
Date: Fri, 8 Jan 1993 22:25:19 GMT

In article <C0K3HC.A8B@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
> In article <3623363@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
> |>I personally believe VAXCRTL is a serious impediment to DEC's claims of 
> |>"openness" in VMS.  Life's too short to have to go re-implementing half
> |>the RTL whenever you try to get anything done because the standard stuff
> |>is too slow, too buggy or more often than not, both.
> 
> Has anyone any idea what the DECC RTL is like? Has anyone tried it on a VAX? (is
> it avaliable for VAX??) Comparing DECC on Alpha to VAXC is not really on...
> anything running on the alpha tends to look fast.

  Yes. The previous author is 100% correct IMHO. I basically gave up
on them ever getting the standard library routines (such as read(2) and 
write(2)) being anything other than disgustingly slow (on the order
of 10-100 times slower then using RMS directly). Worse, it could
easily write files than *nothing* else could read. That and the early
coverage of library routines was pretty grim. And another thing is 
that the damn linker isn't case specific which breaks a lot of ports.
What is worst part of this entire brain dead situation is that there
is *no* reason for it. 
  Don't get me started on this...
-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)
Xref: sparky comp.arch:12143 comp.graphics:13543 comp.graphics.research:419 comp.os.research:1160 comp.sys.sgi:18583 comp.unix.wizards:5385
From: gsk@khaki.esd.sgi.com (George S. Kong)
Newsgroups: comp.arch,comp.graphics,comp.graphics.research,comp.os.research,comp.sys.sgi,comp.unix.wizards
Subject: Silicon Graphics - need excellent systems person
Date: 8 Jan 93 02:17:16 GMT
Followup-To: comp.arch
Organization: Silicon Graphics, Inc.  Mountain View, CA
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu


I need a systems person to work on our next-generation high-end desktop
graphics system. See my recent posting on misc.jobs.offered for details.

George S. Kong,  Silicon Graphics, Inc.,  (415)390-3281  gsk@sgi.com



--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu