From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by hawkwind.utcs.toronto.edu with SMTP id <2749>; Sat, 27 Mar 1993 19:54:23 -0500
Received: from mystix.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP id AA02352
  (5.65/IDA-1.4.2 for sam-fans@hawkwind.utcs.toronto.edu); Sat, 27 Mar 93 16:53:33 -0800
Received: from localhost.cs.uoregon.edu by mystix.cs.uoregon.edu
	(4.1/UofO CS 27-Mar-91) id AA01929; Sat, 27 Mar 93 16:53:28 PST
Message-Id: <9303280053.AA01929@mystix.cs.uoregon.edu>
To:	sam-fans@hawkwind.utcs.toronto.edu
Subject: Re: 9fans? 
Date:	Sat, 27 Mar 1993 19:53:27 -0500
From:	mike@mystix.cs.uoregon.edu

I'd be interested in such a mailing list.

I at least have had some, er, "exciting" times setting up Plan 9.
The CS department cannot afford to dedicate a machine as a full time
Plan 9 file server.  Thus I've been running the terminal kernels off
the Unix based file server u9fs.  The version of u9fs that was distributed
has lots of deficiencies (it doesn't even fully implement Plan 9 file
system semantics), which I've been gradually correcting.  In the long
run I'm either going to have to write a completely new file server, or
talk the department into dedicating a couple of machines to run the
Plan 9 file server and CPU server kernels.  Right now I can use Plan 9
quite comfortably, but non-experts would quickly get hopelessly stuck.

I would be very interested in hearing about other peoples' experiences.

Rob, if you're reading this, two simple improvements to u9fs that
you can easily make are:
1) set the Qid version from the file's mtime
   this makes executable caching do the right thing when
   you recompile something
2) honor the ORCLOSE open flag
   then temp files created by, e.g., sam, go away properly.