[gobolinux-users] Application virtualization and GoboLinux

[Paul Dann]

Samuel A. Falvo II wrote:
> 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.
>   
  OK, as you say, installation of some sort has to occur.  I guess what
I'm trying to say is that I want installation and relocation to be
equally easy.  I don't want to have to uninstall a program and reinstall
it just because I want to move it from my home folder to a global
folder, or into a subdirectory.  The idea of doing that with documents
is ludicrous, so why with programs?
> 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?
>   
  As I expect you know, 'ls' is part of CoreUtils.  My ideas revolve
around the idea of merging packages into the path, pretty much how
GoboLinux currently does it, so the 'ls' binary would be on the path.
> 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.
>   
  I think GoboLinux's approach makes sense --- program != binary, so
once the package is merged, the binary can be executed directly (more or
less), just like GoboLinux.
> 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.
>   
  I've been thinking about the idea of a database that stores which
executables and libraries each known package provides.  A library, for
instance, may be provided by more than one package, in which case the
user may be prompted for which one to use when a package that requires
that library is first merged.

  I would suggest that there should be a set of base system packages
that are merged on boot (e.g. CoreUtils).  To merge a non-system
package, you can do something like:

  $ MergePackage /Applications/Firefox-2.0.0.6
  $ firefox
> 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).
>   
  Ah yes, now this is more interesting.  The problem extends to all
dependencies, not just libraries.  My design idea involves a FUSE
filesystem that provides something similar to GoboLinux's layout, but is
somewhat more intelligent, as it won't break if a package is moved like
a symlink would.
> 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.
>   
  I would certainly never want to get rid of the CLI.  I am very
interested in UI design myself, but it seems to me as though the GUI
sadly gets all the attention although the CLI is just as important a UI
paradigm.  It's a pity it's often overlooked by UI designers and so
remains too difficult an environment for the non-geek :(
> To summarize, you're never going to get rid of SymlinkProgram.
>   
  Maybe not, maybe not.  These are all just ideas right now, but when
(if) I have some time I'll certainly try ;)
> 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.
>   
  It seems as though you have quite a limited view of AppDirs.  I would
say that GoboLinux is pretty much an AppDir-based distro.  It lacks drag
& drop installation and trivial relocatability, but it has AppDirs. 
Personally, I'd prefer to have a "Firefox" package which is current, and
keep old ones tucked away somewhere (e.g. /Applications/Old) with
version names (Firefox-2.0.0.6, etc...).  I might keep both "GCC-3" and
"GCC-4" in /Applications/Tools.
> 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.
>   
  You may well be right, and without a doubt GoboLinux is the closest
thing I've seen to what I want.  It's given me hope for Linux :)

I'm also putting a few of my ideas down on the forum:
http://forum.gobolinux.org/discussion/25/userfriendly-gobolinux/#Item_27

Paul