HDTenEightyP/NetNews huggingface dataset:
From: silvert@biome.bio.ns.ca (Bill Silvert)
Newsgroups: comp.sys.sgi
Subject: Morality (was Re: Security for the functionally illiterate)
Date: 11 Apr 92 15:47:18 GMT
Reply-To: silvert@biome.bio.dfo.ca (Bill Silvert)
Distribution: na
Organization: Habitat Ecology Div., Bedford Inst. Oceanography

In <jbsh14o@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:

>Surely you have *some* system admin folks who know something about Unix?
>You should never connect a machine to the internet unless you understand
>something about security, or have some advice (that means Iris's, PC's,
>Mac's, VAX's, or whatever).

>Almost any Unix book has a chapter on this, and as one of our folks
>said, it is covered in the system admin guide as well, so you could
>get that if you don't have it.

Although I think that Dave is correct, I also think he is unrealistic.
Even at my lab, with a staff of about 800 and computers all over the place,
it would have been lovely to answer "YES" to his question:
>Surely you have *some* system admin folks who know something about Unix?
last year when I got my PI it would have been great to have some advice,
but instead I've been the Unix resource person for the lab since 1982,
although that has fortunately changed during the past year.  But we
desperately needed to be networked so we went ahead with it, despite
Dave's injunction.  I suspect most people in our situation would do the
same thing, regardless of whether they were security gurus or not (I don't
claim to be a total novice, but it isn't my job to be a computer security
expert either).

As for the reference to the system administration guide, I checked that
last week to see how clearly they spelled things out, and the guide
doesn't really see anything in the way of a warning about network
security until page 20-something as I recall (I'm at home now and don't
have it handy).  It comes long after the discussion of things like using
crypt for privacy if I remember correctly, and doesn't really wave much
of a warning for sites connected to the Internet.

I think that the readership of this newsgroup is sending a clear message
that we feel that security against crackers should receive a higher
priority than SGI seems to feel necessary.  For example, on the much
debated lp account issue, we feel that anyone who wants to implement
remote printing should have to remove a lock from the lp account, rather
than the present position that anyone who wants a secure system should
have to lock the account.

By the way, I'll append a reply to the original poster:

>In <29978@adm.brl.mil> MIKE@scripps.edu (Mike Whittaker) writes:
>| As far as security on these machines is concerned, please don't assume 
>| anything. I am not a unix expert, but simply a lowly biologist. 

I'm not a lowly unix expert, I'm a biologist and damned proud of it!
-- 
------------------------------------------------------------------------
William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2.  Tel. (902)426-1577
InterNet Address: silvert@biome.bio.dfo.ca
Newsgroups: comp.sys.sgi
From: dellwo@calgary.scs.uiuc.edu (Martin J. Dellwo)
Subject: Re: Fortran: mixing data statements/declarations
Organization: University of Illinois (Urbana-Champaign)
Date: Thu, 9 Apr 1992 15:19:22 GMT


Oops, ignore this post and look at the other one!  I thought I
cancelled this one...

M
-- 
 \martin.j.dellwo.school.of.chemical.sciences.university.of.illinois.urbana-./
\champaign.phone.work.217.333.3944.home.217.344.7233.email.to.#uiuc.edu.where./
/#.eqs.(dellwo@[ottawa|toronto|montreal|winnipeg|halifax].scs.).or.(m-dellwo@)\
 /.quote.".Verbosity.leads.to.unclear.,.inarticulate.things.".v.p.dan.quayle.\
From: rbthomas@frogpond.rutgers.edu (Rick Thomas)
Newsgroups: comp.sys.sgi
Subject: Re: Software Packaging Tools and Doc available ?
Date: 8 Apr 92 15:46:01 GMT
Organization: Rutgers Engineering Supercomputer Lab

> I'd like to comment on Dave Olson's (personal) views about diskless vs
> diskfull configurations. 
> 
> There is an intermediate option, which SGI does not support any better
> than diskless - that is workstations with local swap/tmp disk.
> Unfortunately, the way in which the client system share-tree's (and
> installs !!)are structured make it VERY hard to support and, more
> importantly, to administer. 

I would like to add my voice to the multitudes asking for better
"dataless" client support.  We have managed to configure three
Indigo's each with a small local disk, getting all shared stuff
from a server.  But it wasn't easy! and we got very little help from
the TAC people.  (They were sympathetic, but pointed out that it was
not a supported configuration.)

Please don't ask me how we did it.  Our solution is very local-site
specific, so it wouldn't help you if I told you.

Sun has pointed the way (with "/var" and "/kvm" filesystems
respectively for local configuration specific files, and "kernel
architecture" specific files)  Their solution works well. 

Why not just do it!

Enjoy!

========================================================================
Rick Thomas, Manager
Supercomputer Remote Access Center, Rm D117
Rutgers University, College of Engineering
Brett and Bowser Roads
Piscataway, NJ 08855-0909

Phone: (908) 932-4301
Fax:   (908) 932-5313
Internet: rbthomas@jove.rutgers.edu
UUCP: {any backbone site}!rutgers!rbthomas
========================================================================
Newsgroups: comp.sys.sgi
From: Michael Steckner <steckner@lri.uwo.ca>
Subject: are there virtual window managers for SGI?
Organization: Relayed-by-Sendmail
Date: Fri, 10 Apr 1992 14:37:16 GMT
To: comp.sys.sgi@julian.uwo.ca

I am trying to install tvtwm, a virtual window manager, on my 4D20. I am
not having much success. It does not seem to be SGI specific. Is there
an SGI specific virtual window manager, or can someone tell me what needs
to be done to install tvtwm. 

For those interested in such a beast, I got tvtwm from export.lcs.mit.edu.
Sadly, I cannot remember which directory. (something with R4/untarred in
the directory list, if I remember correctly)

Thanks for any help
From: nong@mcc.com (Nong Tarlton)
Newsgroups: comp.sys.sgi
Subject: Re: Scanner Installation on Indigo (was PI)
Date: 14 Apr 92 21:28:19 GMT


>.......... do SHARP scanners come with a SCSI interface?

You can get a GPIB-SCSI interface from National Instruments.  I got
my Sharp JX-300, National Instrument GPIB-SCSI interface, and software 
as a package deal from GBA.

   National Instruments Corporation
   6504 Bridge Point Parkway
   Austin, TX 78730-5039
   (512) 794-0100

   GBA
   228 Hawthorne Ave.
   Los Altos, CA 94022
   (415) 948-4711


-------------
Nong Tarlton
nong@mcc.com, (512) 338-3344
Microelectronics and Computer Corporation
3500 Balcones Center Drive
Austin, TX 78759
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: SONY MO WOES
Date: 9 Apr 92 06:22:24 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Apr8.114735.1@vaxa.strath.ac.uk> ccas20@vaxa.strath.ac.uk writes:

| I despair of ever getting this device to work. Postings to
| comp.sys.sgi suggest that SONY mag/optical drives do bolt onto
| the average iris but this one certainly doesnt.

Not any of *my* postings!  That drive is a piece of junk, from
the SCSI interface point of view.

In 3.3.X and 4.0.X, you can make it work by disabling SCSI disconnects;
this can have some negative effects :)

See /usr/sysgen/master.d/scsi.

In 4.0, the drive *did* work, sort of, for at least one set of
firmware/PC board.  In 4.0.1, it doesn't seem to work well without
disconnect disabled (for several other drives; I no longer have the
first); I found this out 2 weeks ago when a customer loaned us a drive
for a week to track down some problems.

Furthermore, I introduced a bug in 4.0.1 fx that interacts with the
lousy SCSI interface on the Sony, so the block size is 'random', due to
an uninitialized variable (I've seen no other devices with such a poor
interface, and therefore haven't seen any other affected devices).
That is fixed in IRIX 4.0.5.  You may be able to work around that
particular bug by using dvhtool, although I usually recommend against
using dvhtool for device params.

--
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
From: mcdonald@aedc-vax.af.mil
Newsgroups: comp.sys.sgi
Subject: X forms generator?
Date: 14 Apr 92 21:16:41 GMT

Is anyone aware of a public domain interactive forms generator/handler?
I am looking for something similar to FORMS for GL.

Thanks for the info.

  vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  | Kenneth M. McDonald * OAO Corp * Arnold Engineering Development Center |
  |             MS-120 * Arnold AFB, TN 37389 * (615) 454-3413             |
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  INTERNET:                                                    LOCAL:
  mcdonald@aedc-vax.af.mil                                     c60244@mannix
Newsgroups: comp.sys.sgi
From: song@cds855 (Song-Yu Yang)
Subject: need help to use CDseek()?
Organization: Cadence Design Systems, Inc.
Date: Fri, 10 Apr 1992 17:20:55 GMT

I am developing a CD player program on Indigo to play the audio CD
music. I try to use CDseek() to do fast foreward/backward searching. 
Unfortunately, every time I issue CDseek() function call will bring 
me to the very start of the CD. I need help about the use of this
function. I'll appreciate for your help.

Best Regards,

Song

--
----------
Song-Yu Yang				E-mail: song@cadence.com
Cadence Design Systems, Inc.		Tel:	(408)944-7995
555 River Oaks Parkway, Bldg. 4, San Jose, CA 95134
Newsgroups: comp.sys.sgi
From: rck@fangio.asd.sgi.com (Robert Keller)
Subject: Re: Indigo: X-session abort via 'xprop'
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: Wed, 8 Apr 1992 17:19:27 GMT

rainer@sfb256.iam.uni-bonn.de ( Rainer Kleinrensing) writes:
>Simply denying access to the X display from our Convex won't work, because
>the users need that (for displaying Convex X applications).
>I think this is a security hole.

I'm not sure this increasing any security hole(s).  If you allow a host 
access to "your" X server, you are leaving your X session prone to 
lots of external fiddling.  For example:

	- that host can easily acquire a screen dump of what is 
	  currently going on your screen. (big brother!)

	- that host can queue thousands of time consuming tasks, thus 
	  reducing the X servers capacity to service your requests.

	- that host can draw random graphics all over "your" work
	  (remember meltdown ?)

	- that host can cause untold thousands of hostile override 
	  redirect windows to appear on your screen, making it impossible
	  for you to do any work.

	etc...

...robert
Newsgroups: comp.sys.sgi
From: sullivan@gojira.gsfc.nasa.gov (dan sullivan)
Subject: How to move internal disk into top slot 4D/20 ?
Reply-To: sullivan@gojira.gsfc.nasa.gov (dan sullivan)
Organization: NASA/GSFC Hydrospheric Sciences Branch
Date: Fri, 10 Apr 1992 13:30:02 GMT

	I want to move an internally mounted 380 mb hard disk in an
Iris File in a 4D20 into the top slot of another 4D20. Can I just remove
the disk and slide it into the slot, or do I need special mounting brackets?
The Iris file's front cover does not come off, so you have to tear it
apart to get at the disk so I assume it does not just slide in there.
	I would rather not have the Iris file in my office, since it takes
up more room, and adds the extra fan noise, and I have the top slot in  my
4D20 empty.
	If I need mounting brackets, where can I buy them, and at what cost?
           	Thanks,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Sullivan                   #  Laboratory for Terrestrial Physics (STX) 
                               #  Code 920.2
sullivan@gojira.gsfc.nasa.gov  #  NASA-Goddard Space Flight Center
                               #  Greenbelt, MD 20771
                               #  voice: (301) 286-2484
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Newsgroups: comp.sys.sgi
From: paul@manray.asd.sgi.com (Paul Haeberli)
Subject: toutah - convert an IRIS image to UTAH rle format
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 13 Apr 1992 08:06:41 GMT

/*
 * 	toutah - 
 *		Convert a IRIS image to Utah raster toolkit format.
 *
 *	To Compile do something like:
 *
 *		cc toutah.c -o toutah -I/usr/include/gl librle.a -limage
 *
 * 				Paul Haeberli - 1990
 */
#include "stdio.h"
#include "image.h"
#include "rle.h"

short rbuf[8192]; 
short gbuf[8192]; 
short bbuf[8192]; 

rle_hdr	hdr;

main(argc,argv)
int argc;
char **argv;
{
    IMAGE *image;
    int i, y, z;
    int xsize, ysize, zsize;
    unsigned char *rows[3];

/* get args */
    if(argc != 3) {
	fprintf(stderr,"usage: toutah inimage.rgb outimage.rgb\n");
	exit(1);
    } 

/* open the input file */
    image=iopen(argv[1],"r");
    if(!image) {
	fprintf(stderr,"toutah: can't open input file %s\n",argv[1]);
	exit(1);
    }
    xsize = image->xsize;
    ysize = image->ysize;
    zsize = image->zsize;

/* open the output file */
    hdr.rle_file = fopen(argv[2],"w");
    if(!hdr.rle_file) {
	fprintf(stderr,"toutah: can't open output file %s\n",argv[2]);
	exit(1);
    }

/* allocate row buffers */
    rows[0] = (unsigned char *)malloc(xsize*sizeof(unsigned char));
    rows[1] = (unsigned char *)malloc(xsize*sizeof(unsigned char));
    rows[2] = (unsigned char *)malloc(xsize*sizeof(unsigned char));

/* set up the header */
    hdr.xmin = 0;
    hdr.xmax = xsize - 1;
    hdr.ymin = 0;
    hdr.ymax = ysize - 1;
    hdr.ncolors = 3;
    hdr.background = 0;
    hdr.alpha = 0;
    hdr.ncmap = 0;
    RLE_SET_BIT(hdr,RLE_RED);
    RLE_SET_BIT(hdr,RLE_GREEN);
    RLE_SET_BIT(hdr,RLE_BLUE);
    rle_put_setup(&hdr);

/* copy image data */
    for(y=0; y<ysize; y++) {
	if(image->zsize<3) {
	    getrow(image,rbuf,y,0);
	    stoc(rbuf,rows[0],xsize);
	    stoc(rbuf,rows[1],xsize);
	    stoc(rbuf,rows[2],xsize);
	} else {
	    getrow(image,rbuf,y,0);
	    getrow(image,gbuf,y,1);
	    getrow(image,bbuf,y,2);
	    stoc(rbuf,rows[0],xsize);
	    stoc(gbuf,rows[1],xsize);
	    stoc(bbuf,rows[2],xsize);
	}
	rle_putrow(rows,xsize,&hdr);
    }

/* close the output file */
    rle_puteof(&hdr);
    exit(0);
}

stoc(sptr,cptr,n)
register unsigned short *sptr;
register unsigned char *cptr;
register int n;
{
    while(n--) {
	if(n>=8) {
	    cptr[0] = sptr[0];
	    cptr[1] = sptr[1];
	    cptr[2] = sptr[2];
	    cptr[3] = sptr[3];
	    cptr[4] = sptr[4];
	    cptr[5] = sptr[5];
	    cptr[6] = sptr[6];
	    cptr[7] = sptr[7];
	    sptr+=8; 
	    cptr+=8;
	    n -= 7;
	} else {
	    *cptr++ = *sptr++;
	}
    }
}



Newsgroups: comp.sys.sgi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: physical security
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 11 Apr 1992 04:05:45 GMT

In article <1992Apr11.005429.15869@odin.corp.sgi.com>, raolson@cornflower.wpd.sgi.com (Robert Olson) writes:
> In article <1992Apr6.225850.6451@odin.corp.sgi.com>, zursch@whizkid.corp.sgi.com (Jeff Zurschmeide) writes:
> |> David,
> |> 
>|>   Physical security is a tough issue. The conventional wisdom is that it's 
> |> next to impossible to stop a determined hacker if that person has access to
> |> the hardware....
> 
>All machines in current production are shipped capable of having the boot prom
> passworded as a standard feature.  ...


Given physical access to the machine and a screw driver, the determined bad
guy can use the method often discussed for disabling the PROM password.
(Don't ask me what it is, not because I wouldn't tell, but because I don't
know.  It involves a jumper or a shorting wire or removing a chip from a
socket.)


There is never going to be a satisfactory solution to this problem.

I have no doubt there is a market for machines costing from $10,000 to
$500,000 which become so much useless trash if you forget the password.
It is a small market and one that I personally don't want much to do with.

In the larger markets there will always be a way for a field service
technician to fix lost password problems.  That means there will always
be a way for bad guys to subvert machines.

For an IRIS, a lazy bad guy need not go to the trouble of fiddling with
jumpers.  Simply remove the root disk, install it in a nearby machine which
has already been corrupted, add a line to /etc/passwd on the target disk,
return the target disk to the target machine, let the target boot normally,
log in using the extra /etc/passwd line, and then remove the PROM
password.


Vernon Schryver,  vjs@sgi.com
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: stdio write limit
Date: 8 Apr 92 07:12:28 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Apr8.051146.22013@ml.csiro.au> peter@ml.csiro.au (Peter Campbell) writes:

| A really easy one.  When I try to write a buffer of more than 3072 characters 
| in length it hangs.  I am still running 3.3.2 (through no fault of my own).
| I originally found the problem when I couldn't cat a file of that size.
| Rebooting will no doubt fix the problem for now but there must be a way
| to prevent it happening again.

You need to provide a lot more detail than this.

Why do you think cat has anything to do with it?  Unless you use
the -v flag, cat does (stripped down) while(read>0) write;
At least, in IRIX.  cat is amazingly different on different systems.

Perhaps you are writing to a pipe, and nobody is reading the pipe?

--
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.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: /etc/savecore wish list...
Keywords: savecore memory disk
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 10 Apr 92 19:36:05 GMT

In <acas.702887846@godzilla> acas@ (Andrew Cassin) writes:

| Why cant savecore write large core files in a "compressed" format. We have
| a 64meg VGX with no available filesystem with that much space. It would
| be great if it could compress core files in such a way so that
| we have a chance of passing useful files onto sgi...

I doubt we will build compress into the kernel, but we could do it
as part of running savecore.  Not a bad idea.
--
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
From: suhonen@jalka.jyu.fi (Timo Suhonen)
Newsgroups: comp.sys.sgi
Subject: cc version 3.10
Date: 7 Apr 92 10:02:28 GMT
Distribution: comp
Organization: University of Jyvaskyla, Department of Biology of Physical
	Activity


I have heard, that there is a new cc version (3.10?) for SGI machines.
Would someone (at SGI?) post some results from a comparision between
versions 2.10 and 3.10 (in a R3000 based machine). My interest is in
float/double calculations performance, but any other info is also mostly
welcome.

thnx,
--
Timo                 "I am logged in, therefore I am"                 Suhonen
  It is left as an easy exercise to the reader to correct all typos. (-me)
   Opinions(?) are mine (if not stolen), NOT those of Univ. of Jyvaskyla.
From: renggli@masg1.epfl.ch (loris renggli)
Newsgroups: comp.sys.sgi
Subject: Re: log function bug ok in 'C'
Date: 17 Apr 92 14:45:44 GMT
Organization: Math. Dept., Swiss Institute of Technology

In article <30050@adm.brl.mil>, lsr-vax!lmo@uunet.uu.net (Lance M. Optican - LMO) writes:
|> 
|>         I am also interested in mathematical integrity on the
|> irises!  I tested your reciprocal log bug under Irix 4.0.1.
|> I found no problems under "C":
|> 
|> #include <math.h>
|> main()
|> {
|>        float x;
|> 
|>        x = 1.5 * pow(2.0, 126.0);
|>        printf("x = %20.16g\n", x);
|>        printf("ln(x) = %20.16g\n", log(x));
|>        printf("ln(1/x) = %20.16 g\n", log(1.0/x));
|> }
|> 
|> produces:
|> 
|> x = 1.276058875953519e+38
|> ln(x) =    87.74200985866128
|> ln(1/x) =   -87.74200985866128
|> 

That's because log is
double   log(double);

Try to use the float version logf in your above example
float    logf(float);

and you will get (under 4.0.1 or 4.0.3) :

x = 1.276058875953519e+38
ln(x) =    87.74201202392578
ln(1/x) =   -87.51886749267578

------------------------------------------------------------------------
Loris RENGGLI
Swiss Federal Institute of Technology
Math. Dept                             e-mail : renggli@masg1.epfl.ch
CH-1015 Lausanne (Switzerland)
--
Newsgroups: comp.sys.sgi
From: pj@sam.wpd.sgi.com (Paul Jackson)
Subject: Re: memory and disk space from a C program
Reply-To: pj@sgi.com
Organization: Silicon Graphics, Research & Development
Date: Wed, 15 Apr 92 23:57:49 GMT

In article <1992Apr15.102811.25628@jarvis.csri.toronto.edu>, corkum@csri.toronto.edu (Brent Thomas Corkum) writes:
|> 
|> Can anyone tell me how to go about getting the amount of disk space and
|> main memory that I have installed from within a C program. 

I use the following C code to report main memory size (feel free
to change the 8 MB default, depending on your needs):

#include <invent.h>
/* Return size of main memory in bytes */
memsize(){
  inventory_t *getinvent(void);
  inventory_t *sp;
  static int sz = 0;

  if (sz != 0)
      return sz;

  while ((sp = getinvent()) != 0) {
      if (sp->class == INV_MEMORY && sp->type == INV_MAIN) {
          sz = sp->state;
          break;
      }
  }

  if (sz == 0)
      sz = 8*1024*1024;	/* 8 MByte default main memory size */

  return sz;
}

The getinvent(3) routine will also report disks recognized at boot,
which is not the same as what is mounted or what free space is
left on what is mounted.

-- 

				I won't rest till it's the best ...
				Software Production Engineer
				Paul Jackson (pj@sgi.com), x1373
From: rlafolle@duchamp.nswc.navy.mil (Robert D. LaFollette)
Newsgroups: comp.sys.sgi
Subject: Information Request
Date: 6 Apr 92 14:21:13 GMT

Sorry to have to repeat this message but my email address has changed
and I wanted to update that information.  Thanks !



	I am working on a scene synthesis program in support of a
Tomahawk Missile simulation.  We are now trying to add 3D objects
(man-made and natural) to our scenes.  We are currently in the 
process of attaining BRL-CAD for building some of these models. 
Models that have already been produced would of course accelerate
our program.  If anyone knows of model libraries that are available
for public use I would certainly appreciate you sharing this 
knowledge with me.  Also, if anyone knows of software, papers, ...
concerning building natural objects with mathematical functions,
fractals, or some other method this too would be helpful.  

	I already know about the library of models at 
cs.uoregon.edu.  

	Have a nice day !




		Attn: Code N40MP   Robert LaFollette 
		Dahlgren Division, Naval Surface Warfare Center
		Dahlgren, VA 22448-5000

		(703)663-4749   autovon 249-4749
		FAX (703)663-4749
		Email   rlafoll@see.nswc.navy.mil
			rlafoll@128.38.15.54
From: senseman@lonestar.utsa.edu (David M. Senseman)
Newsgroups: comp.sys.sgi
Subject: Help! I Can't See The Screen!
Date: 14 Apr 92 23:35:03 GMT
Organization: University of Texas at San Antonio

As a biologist, I was trained to experiment -- this particular
experiment didn't work as planned and now I can't see the screen
on a PI 4D/20 (8-bit graphics). The experiment was to see if
I could save diskspace by NFS mounting /usr/lib. OK it was a 
dumb idea. Anyway, I restored /usr/lib from an Indigo XS24
(i.e. rcp -r indigo:/usr/lib pi:/usr). Now when the PI goes
into Pandora the screen goes completely BLACK! (It looks
normal before that). Is there something simple I can do
to restore the screen or must I reload the operating system?

Thanks.
-- 
              David Senseman (senseman@lonestar.utsa.edu)