gripes about .grassrc/env vars/locks/permissions

[Darrell McCauley]

I've run into a problem where if I run (concurrently) grass on two
separate machines and separate databases, things get screwed up ($HOME
and my data are both on the same filesystem, which is NFS mounted on both
machines).  For example, programs like g.list seem to consult the
.grassrc file and not the environment variables.  Should this be
happening? The grass4.1 startup script didn't prevent me from
running concurrent sessions.

I thought that (in the past) programs got information from your
shell's environment (e.g, $LOCATION). If the (current) design
philosophy is that GRASS should not be run concurrently anywhere by
any one user, then the current system does not work. (Are these
environment variables still needed if ~/.grassrc is always
consulted?)

Something about this whole locking scheme with world writable
directories doesn't sit so well with me. :-( 
It doesn't go over too well with system administrators here
(where any one of 10000+ users could write to these directories!!!)

Comments?  

If data integrity is the primary concern, WHAT ARE THE DRAWBACKS TO
INCORPORATING A NETWORK LICENSING SCHEME with only one license per
mapset? Concurrent grass sessions could be allowed by the same users,
but noone would be allowed to work on the same MAPSET at the same
time. Granted, sometimes these things are a pain to keep running, but
if it was designed so that it was fileserver dependent, that is, ask
the daemon from which the data is mounted for permission, problems
would be minimized.  (After all, if that server is down, you cannot
get to your data anyway). Only one daemon per server should be needed
to keep track of which mapsets were being used.  Just as long as it
was dependable.

Sorry to rattle on, but just a little tired of having
to justify some of these things (to others and myself).

--Darrell