Re: app-encapsulation and transparent-install (MS is doing it)

[David Jeske <jeske home chat net>]

On Sat, Sep 05, 1998 at 10:40:53PM -0500, Havoc Pennington wrote:
> On Fri, 4 Sep 1998, David Jeske wrote:
> > I just wanted to follow up on some ideas I was throwing around here
> > for stricter encapsulation of application data a while back. The next
> > logical step, once app data is encapsulated strictly, is doing some
> > kind of 'transparent-installation'. Something like how Marimba
> > works(ed) for Java applications. In this model, the OS merely 'caches'
> > application data, knowing it can get it out there somewhere should it
> > need it again.
> 
> I haven't ever seen Marimba; how is this different from packages, except
> for the fact that it's all automatic?
> 
> For example, I needed g77 the other day; I typed "apt-get install g77" and
> the ultra-cool new Debian package manager Apt went online, got the program
> and all dependencies, installed and configured it. And I was done.  Then
> when it's taking up disk space, I type "dpkg --remove g77." The commands
> are a little cryptic, but a simple GUI cures that.

1) Users can't do what you said above, only administrator.
2) Marimba can automatically keep the application up to date

> I guess the Debian window manager menu entries could all point to a script
> like:
> 
> if (the program is installed) 
>  run it
> else 
>  ask the user if they want to install it, then run it

This would be a nightmare (IMO). This is exactly the kind of thing
which makes Linux systems hard for non-unix gurus to setup today.

> (problem is that right now the menu entries only appear after
>  installation, but that could be changed.)
> 
> I guess all that's missing then is blowing away the installation if disk
> space is needed. But that wouldn't be too hard. 

That's not how this stuff I'm talking about works. It can actually
delete part of the app if it's not needed, and when you run the app
again, and the app needs it's files, it can just pull it from the
network or cdrom. It's just like the virtual memory paging scheme,
only for applications.

> I see it as a distribution issue; I doubt you could get a dist. to do it
> by default, because it would sure annoy most people, but it doesn't seem
> too difficult to retrofit. Debian at least encourages distributions based 
> on it; seems like it'd be fairly straightforward to create a custom Debian
> derivative with this feature.

In Linux it's very hard to relocate packages, because alot of software
is dependent on install location. This makes it very hard for users to
ever install apps using precompiled packages.

It's also not always possible to install multiple versions of the same
app, which under the above 'automatic' scheme is absolutly
necessary. The structure of the apps themselves need to change. I
think the CORBA stuff that felix mentioned may get us there more
appropriately. We'll see.

> However I don't think the Gnome project can really do anything with this;
> it's got to involve the distributions, because that's where software gets
> installed.

Actually, I see it as exactly the opposite. 'UNIX' has it's own set of
rules for how software works and gets installed into the system. In a
sense the desktop environments (Gnome and KDE) are making a new set of
rules for software which is primarily 'end-user' software to be run on
the desktop. This kind of software has different needs than UNIX
server software, and should be handled differently. It's (IMO) exactly
the _job_ of Gnome/KDE to define this.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net