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

[andrew mmc]

I have to agree there is not one solution.  Dependent on the application
there will be a balance of objectives, performance, portability, and
expertise required.  There is no point in going to tremendous effort to keep
it totally portable if all users have sufficient knowledge to perform
whatever tasks may be required.  Simply mandating a minimum level of
expertise removes constraints on portability and opens up opportunities in
other areas.
In the web server scenario that has been discussed, the objective is
generally to have a dynamic, frequently changing website.  Moving a website
is trivial in most cases, but making it such that it cannot be broken (or
even striving to achieve that) is a great deal more effort than simply
educating a user on what they need to know in order to move it.  And on top
of it makes the original objective of the site being dynamic harder to
achieve.

An example of these changing priorities is the web archive example given:
 it is not an example of how the structure of the web is broken, but an
indication of making a system design choice in order to achieve a particular
goal:  accept the loss of fidelity by not archiving the images, in order to
be able to archive the whole web.  If they had ensured fidelity, that goal
would not be feasible.

In reality every project has its own balance.

On Wed, Aug 5, 2009 at 3:57 AM, Richard O'Keefe <ok@REDACTED> wrote:

> 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.
>
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>