[erlang-questions] Stuff that breaks when you move it

[Richard O'Keefe]

What we have here is essentially the debate between
static libraries and dynamically linked ones.

To this day I remain hopping mad that Sun stopped
providing a statically linked libc with Solaris 10.
The argument for this was that customer programs
would _certainly_ never need to be relinked when a
new version of the operating system or library was
installed.

The downside was that profiling (cc -p / prof) became
useless to me, because libc functions were no longer
reported.  There's also the extra cost of run-time
loading, &c &c &c.

Before Solaris 10, it was *my* choice whether I wanted
the "complete self-contained fast starting" virtues of
static linking or the "invisible updates to fix things
like security bugs" virtues of dynamic linking.  Now it
isn't.

Since much of the software I use is open source, and since
new releases are comparatively frequent, and since I'm
recompiling my own stuff all the time, for *me* the benefits
of static linking are preponderant.  For many commercial
enterprises, I imagine the benefits of dynamic linking are
preponderant.

I note that Macintosh applications *behave* like single
"objects", but they *are* directories containing a lot of
files.  I note that the technique Joe mentioned, where an
HTML page can have "links" that point _without_ the single
block of data transmitted in an HTTP message "behaves like"
a collection of linked objects but "is" a single thing.
And then you have things like .iso and .dmg files where
one and the same thing "is" a single object and also "is"
an entire file system.

We've got the classic distinction between hard links and
symbolic links:  if I have a hard link from A to B and B
is moved, A will still point to whatever B is, while if
I have a symbolic link from A to B, B is renamed to C, and
D is renamed to B, A will now point to D.  When "something"
is moved, what is "it", and do we always want the same thing
to happen?

It seems to me that the answer is that sometimes we want one
kind of behaviour and sometimes we want another.  There is a
complete spectrum of behaviour from
	- install and work in one place only
	- install anywhere but it must stay there
	- install and move a subtree anywhere
	- be able to keep working if parts are moved
	- be able to keep working if some parts are
	  translated into Russian and some into Swahili
	  with components running on machines with
	  randomly chosen byte sex and word size

Last year, our system administrators moved all my files on
my desktop Mac.  Needless to say, a whole lot of software
I'd installed stopped working.  I completely bitterly and
was solemnly assured it would never happen again.  I still
hadn't got everything back working when, guess what, they
did it again.  They forcibly amalgamated my Mac files and
my Linux files into a single file system.  (So ~/Desktop
is now ~/MacDrive/ok/Desktop, except that there is now a
_new_ ~/Desktop as well.)  Again all of my paths and most
of my installed software broke.  What could be worse?  I'll
have to wait to next year to find out.

There were good motives.  The reason for forcibly amalgamating
the file systems (without my advance knowledge, let alone
permission) was so that everyone's files would be on the same
file servers, available on any machine in the department, and
with everything backed up the same way.  The problem is that
the file servers go down far more often than the isolated Mac
used to, so the net result was *less* availability.

Thank goodness for the sysadmin who looks after my SunBlade 100;
she didn't touch my files and everything just works.

What's the point of the story?

Unexpected consequences.

"Packaging" changes designed to improve things can not only
make other things worse, they can even end up making the
things they were intended to help with worse.  One approach
DOESN'T suit every need, and what looks like the obviously
best thing may actually be disastrously wrong for someone.

Wouldn't Joe's "everything should just keep working if you
move it" have saved me?  Not when my Mac found itself
running my Linux ~/.profile instead of my Mac one:  the
problem here is not just that the thing expected to be at
location X wasn't there, but that something else _was_ there.
Even if stuff is packaged as single "things" that adapt to
new locations, *something* has to find them.  There'll always
be *something* that breaks if some other thing is moved.

Of course the Mac tries to handle that by associating applications
with documents, and keeping track of where the applications are.
So I have some .pdf files that open in Preview, some that open
in Acrobat 8, some that open in Acrobat 9, and some that fail
to open at all.  Of course, when I say "open in Acrobat 9",
what I really mean is "not open in Acrobat 9" because there's
something dodgy about Acrobat 9...

Members of the Jury, if you believe that there is a "one size
fits all" solution to this kind of problem, I an only envy
your easy faith.