Re: union mounts

On Sat, Nov 07, 1998 at 01:32:08PM -0800, David Jeske wrote:
> On Sat, Nov 07, 1998 at 12:18:24PM -0800, Eric Dorman wrote:
> > > I find this an interesting concept considering that modern shells walk
> > > your 'path' and bring everything into an in-memory hash table
> > > anyhow. What's the big win of doing a union bin?
> >
> > Coz then you don't have to complicate the shell with PATH and
> > caching nonsense. Plus one doesn't have to do screwy things with
> > mounts if you have clients with different architectures.
>
> 1) All modern shells (bash,tcsh,zsh) do this regardless of whether you
> use union mounts or not. I suppose the union mount lib could keep hash
> tables itself.

Um, so? These shells need such stuff for traditional unices that
have a plague of paths, particularly older systems that don't do
path caching in the kernel (if any such still exist).

Seems to me one would want to identify that a cache would solve a
performance hit rather than adding it just because legacy systems do so
or continue carrying around legacy baggage for the sake of continuity
(an unfortunate affliction vsta suffers from).

> 2) To me it's not so important whether you use union mounts or my
> scheme for adding the package to your environment. The important part
> is that you specify the package with a logical name (like
[etc]

Your solution works for end applications on unices (which is lousy
for architectural dependencies anyway), but you still do not address the
problems associated with different headers with the same name (where is
<tcl.h> this week? Which version is it? How does Joe User access it?),
dependencies on static libraries or apps you may not have source for, and
intermediate processing files or databases located outside the scope of
the filesystem. Most solutions to these problems are intrusive on the
users, complicated to administer or downright impossible to implement
in an encapsulated way.

> 3) what do you do with union mounts when you have naming collisions?

A Plan9-esque MBEFORE/MAFTER option easily resolves collisions in
a predictable fashion.

If you presume a unix platform, we always use a clean slate when
rebuilding an old version. This eliminates subtle dependencies
and is a closer representation of the field hardware.

> > [xxx 'encapsulation']
> > > This allows me to have lots of versions of the same things installed,
> > > and allows me to be more aware of command line naming conflicts.
> > This is an advantage? Seems the road to madness, with the possibilities
> > of different header, log or data file formats with misc. versions floating
> > around. Plus it gets icky quickly if multiple architectures must be
> > supported.

> The road to madness is forcing everyone to upgrade to a new version at
> the same time.

You presume we switch everyone at the same time.

As far as unix goes, we prefer to exercise 'proactive administration'.
New versions are staged outside user purview, then after major milestones
dependent applications are brought into the new tree, regression tested,
etc until we're happy, then dependencies/applications are switched around
with a symlink; there is only the 'old tree' and the 'current tree'.

This of course presumes a dependency change doesn't force changing a
database structure or somesuch; when that happens we have to
migrate data (bleh).

The milestone process archives apps with all their dependencies
simultaneously, so rebuilding older versions is trivial. I do not
recall ever having to build an older version in production (after
'stamping' masters) but the formalism is there.

Things with little dependency (ala' netscape-4.03 et al.) are
easily pulled from backup if the install is bad; I don't recall
ever having to do this, but again the formalism is there. At any
rate things are always backed up so bad builds/installs are no
big deal.

[xxx]
> Personally, I like to test the seaworthyness of my next ship before I
> sink the old one. Others clearly like to sail the ocean in a more
> risky manner.

Unfair and ill-informed slight.
 
> FWIW, UnixTools beautifully handles multiple architecutres:
> netscape-4.03.encap/sun-solaris/bin/*
> i386-linux/bin/*

Now add 20 headers, 25 libraries, 12 apps in 3 languages, a pile of
shell scripts, 3 daemon users + daemons and a 36Gb database all with
a myriad of interdependencies, for 3 architectures. Thus not
'sliced-bread', surely.

Users depend on apps, but apps and packages depend on a host of things
unrelated to /bin not nearly so easily encapsulated as you suggest.

Seems to me one would want to fully exploit the opportunities provided by
interacting local namespaces and union directories before importing legacy
concepts from architecturally (-backward?) -less-flexible systems.
Focussing strictly on 'what does union dirs buy me' ignores that unions
(and applications, for that matter) interoperate with the rest of the system
in a coherent fashion.

I'd prefer Plan9.

[xx]
> David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske_at_chat.net

Sincerely Yours,

Eric Dorman
edorman@ucsd.edu
Received on Tue Nov 10 11:04:38 1998