Re: Windows and DLLs

[David Jeske <jeske home chat net>]

On Thu, Oct 01, 1998 at 09:11:17PM +0200, Jochem Huhmann wrote:
> On Wed, 30 Sep 1998 17:24:08 PDT David Jeske wrote:
> 
> > We really need to move to an app-encap/wrapper standard where an
> > application can come in an encapsulated form with a collection of
> > private datafiles, where it's given the 'current locaiton' of itself
> > when it's launched, and where it can ask for it's private datafiles
> > with _relative_ paths. 
> 
> That's a great thing for a single user system. 

This is a _better_ thing for a multi-user system.

> > Some apps do a better job.. for example "wmprefs.app". It is wrappered
> > in the same style that Nextstep apps were wrappered in ".app
> > directories". As long as you launch it with a full path to the
> > executable, it can find it's datafiles, and window maker knows how to
> > throw it into the Doc, etc , etc...
> 
> The problem comes up when users start to install their apps in their
> home directories (say, in /home/jeske/apps/foo.app). That's what this
> kind of scheme is intended for, I guess. But what if another user on the
> same machine or network also needs this application? 

Then he installs it himself, or they both ask the administrator to put
it in a public location. Or the first user makes his app directory
publicly readable. 

Compare this with the current UNIX system of installing apps, where
users _cant_ install apps, because many apps are hard-coded to find
their datafiles in "/usr/local/<appname>".

> Either he has to dig around in other user's home directories to find
> an specific app (I wouldn't like that) or - he just installs another
> copy of this app in his own home directory... And what about
> system-wide pre-configuration of applications?

Pre-configuration? In the app-wrapper world, the wrapper defines what
the app needs to run.. You can copy an app wrapper, and it works
anywhere. Any configuration data which is needed is stored in some
preferences system (like libPropList), and never changes the data
inside the app wrapper. If you need to setup system wide configuration
data, you do so in the preferences system.

> How to make sure that all users are using the same version of an
> app?

You don't.... user's voluntarily choose to use the same versions of the app.

In the unix world, how do you install multiple versions of the same
apps without them colliding?

> How to update libs or datafiles if they are spread all over the
> site?

What libs and datafiles are you trying to update? If I'm a user, and I
install my own privte version of my email program, (which I can do on
UNIX if I pull down the source), you sure as heck shouldn't be mucking
with it.

> This wrapping thing makes sure that the app knows everything it
> needs, but the *system* knows nothing. The unix way of installing
> applications is The Right Thing, IMHO.

Why? As a user, I can pull down source and compile an app to sit in my
home directory and the "system" knows nothing. My complaint is that I
can't do this with binary packages, because these apps are hard-coded
to a particular install location. UNIX's installation method dosn't
provide _any_ managability of multiple versions of the same packages,
nor does it allow users to install their own apps. 

> And rpm does the best job in this regard I have ever seen - no need
> to fix things that are definitely not broken. It may seem
> complicated, but it is as simple as possible (but not simpler).

RPM is completely ineffective for a network of machines with a need
for continuing support. I managed a 'free toolset' on a cluster of
Solaris machines, and I have to compile _everything_ from source. I
had to do this because multiple versions of the same apps needed to
coexist and people needed to be able to choose what versions of what
apps they were using either (a) for themselves, or (b) for some
project/set of scripts. Old apps needed to NEVER go away, so that old
tools would continue to work. RPM dosn't let me do any of these things
easily ebecause the apps which are being RPM packaged have hardcoded
path dependencies.

You can continue to use RPM all you want with an encap/wrapper
standard. My point is that I don't want to have to install from source
just because I want to orginize my system differently than the person
who compiled the RPM package.

> It's really funny: MS is trying to make NT (5.0) a lot more multi user
> aware and on the other side all unix desktop folks are trying to make
> unix a lot more like windows, copying shortcomings of it.

I'm not trying to copy anything about windows, I'm trying to copy
nextstep, which IMO is the best and easiest to use combination of UNIX
and 'friendly desktop' which has existed to date. CDE, KDE, and Gnome
all pale in comparison.

> I *really* hate that gtkrc-thing of gtk and gnome, BTW. No way to define
> a hierarchy of settings (per-app, per-user, systemwide). Just like
> oldfashioned  MS-Windows INI-files. It's a shame.

Nextstep had a great system for defining a heirarchy of settings
called "next defaults".


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