[gobolinux-users] Application virtualization and GoboLinux

[Samuel A. Falvo II]

On 8/28/07, Paul Dann <pdgiddie at googlemail.com> wrote:
> entrenched in us the idea of the installation procedure.  Look back at
> RISC OS --- copy a directory and you're done.  MacOS X --- copy a

AmigaOS as well, for the most part.

> Now we need to do our best to get rid of SymlinkProgram, which is
> brilliant at what it does, but in a way is quite conceptually similar to
> Windows Installer --- it does something "magical" that the user doesn't
> understand.  Any textbook on human-computer interaction will tell you
> that magic is something to be avoided at all costs.

Installation is required because that process tells the operating
system where it can find the newly installed software.  This is a
legitimate step one should be expected to take.  Whether it is done
lazily (in the case of AppDirs) or proactively (in the case of
SymlinkProgram) is immaterial.  At some point, it has to be done.
However, you'll find that proactive installation results in a faster
to use system.

That being said, please note that the command-line interface (CLI) is
a proper programming language in its own right.  When faced with
AppDirs, the CLI becomes more complicated.  Suppose we install a
package for 'ls'.  When I type 'ls', does that run a real binary
inside the AppDir?  Or, is the AppDir itself named 'ls', with a ".run"
file sitting inside it?

If following AppDir semantics as defined by ROX, supposing this is the
first run of 'ls', it will now proceed to self-compile.  Does this
open a new shell window for the task?  What if you don't have a GUI
environment to do this with?

See, this gets pretty sticky, VERY fast.  It also doesn't help that
.run will need to perform a check to see if it's been compiled every
time you use it.  It's bad enough that the shell interpreter is going
to need to make TWO disk accesses, minimum, just to invoke any
arbitrary shell command, assuming it knows the location of the
command's AppDir.

Speaking of which, just how does the shell interpreter learn about the
existance of AppDirs?  You end up reintroducing the concept of the
PATH variable, so that it can seek out AppDirs.  This either
constrains placement of AppDirs (defeating the purpose of placing
AppDirs arbitrarily), OR, you end up having to proactively
install/configure the shell's PATH variable every time you install a
new command.

The issue of libraries now rears its ugly head.  GoboLinux handles
libraries transparently because of SymlinkProgram, which proactively
creates library links in a centralized location.  However, in a pure
AppDir-based environment, you EITHER need to constrain library AppDirs
to a certain directory (e.g., the System folder in MacOS), or you need
to enumerate files along a library path, each file being within the
AppDir's "lib" directory (thus, _3_ disk accesses per sought library,
minimum).

To switch over to an AppDir environment, you're obligated to jettison
the CLI entirely.  In the interest of maintaining any degree of
reasonable performance while finding AppDirs, you're also obligated to
employ substantially more intelligent filesystem designs.  Modern
experience suggests this isn't necessarily such a bad idea -- if you
need some kind of scripting done, you can always employ Python or Lua
or some such.  And database-backed filesystems appear to be making a
comeback.  However, despite all this, the lack of a command-line
environment is fundamentally incompatible with ANY Posix environment,
and employment of more intelligent filesystem APIs has not been widely
accepted.

To summarize, you're never going to get rid of SymlinkProgram.

Not only that, but there is one fundamental flaw with AppDir-based
environments -- just how the heck do you manage multiple versions of
the same binary installed on the same system?  GoboLinux makes this
process utterly trivial.  I cannot think of any reasonable approach
with AppDirs, short of renaming the directory itself, which also
requires that I hand-tweak existing scripts or program configurations
to use the specific version I indicate.  Lots of manual labor
involved.

I think GoboLinux represents the best possible compromise between the
ideal environment we'd all like to see, and the POSIX straightjacket
that we're all obligated to wear.

-- 
Samuel A. Falvo II