9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: [9fans] Re: Arguments concerning cross mounting /usr/local, /opt
Date: Mon, 14 May 2001 15:29:26 +0000	[thread overview]
Message-ID: <3AFFF3DF.F70434C4@null.net> (raw)
In-Reply-To: <3AFEEEEB.21387D41@p21.kiev.ua>

Alt wrote:
> > I mean using  NFS to mount /opt and/or /usr/local  across a network of
> > machines.  I have received excuses that cross mounting the file system
> > cause non specific incompatibilities.  That cross mounting a directory
> > may  cause licensing problems  for commercial  software.  Most  of the
> > excuses, I believe, are nonsense, or should not be a deterrent, but I
> > am  not an  OS  specialist.  I  am  seeking something  in writing.   I
> > thought OSs would be well beyond the stage of standardization by now.

> ! BY THE WAY, there is no such problems in PLAN-9.

Plan 9 has no problem with commercial software licensing because there
isn't any.  That's not necessarily an advantage.

The main incompatibility associated with mounting remote file systems
is that executable binary images won't work if the local and remote
architectures differ.  Similarly, application use of (database) files
has to choose either the local or remote filesystem for each file,
and different applications have different requirements, so quite often
the wrong file is accessed.  Plan 9 is more flexible in both of these
areas, but it doesn't totally eliminate such problems.

There actually *is* widespread standardization of the UNIX environment;
see POSIX, Open Group, etc.  However, even a standard ABI does not
totally eliminate all possible problems.

That said, I used a UNIX (Solaris) file server for many years quite
successfully.  

> > Without cross mounting, systems  quickly degrade into software version
> > inconsistencies,  maintenance difficulties,  lack  of standardization
> > across network nodes,  etc.  Plus it just makes  the admin's life more
> > difficult.

There were some administrative difficulties is getting the file server
and local workstations properly synchronized initially, but after that
it did make system software administration much easier (which is the
main reason we resorted to file servers; economics was secondary).

> Yea.You see, UNIX is not the best choice for the such things.
> PLAN-9 (and probably Oberon) does it much better.
> UNIX is a mainframe.

If the fellow needs to use centrally-administered UNIX-based software,
switching him to Plan 9 would only frustrate him.  Eventually he'd
have to use VNC etc. in which case Plan 9's characteristics wouldn't
offer any particular advantage.
\x01\x01\x01\x01


      reply	other threads:[~2001-05-14 15:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m3vgnbffc5.fsf@cadence.glidepath.org>
     [not found] ` <3AFD060F.29F72B32@p21.kiev.ua>
2001-05-14  8:37   ` Alt
2001-05-14 15:29     ` Douglas A. Gwyn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3AFFF3DF.F70434C4@null.net \
    --to=dagwyn@null.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).