Re: Windows and DLLs

[Nils Philippsen <nils wombat dialup fht-esslingen de>]

On Thu, 1 Oct 1998, David Jeske wrote:
> 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.

No (at least not in the sense you obviously mean).

[snip]
> > 
> > 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.

Given the typical user is as communicative as I experienced in my time
being an admin (I'm still one, it's still fun :-) In a system with say
more than 100 users there will be at least 20 version of a certain app
floating around in the users' homes before anyone even thinks about
asking the admin to install it. This is a messy situation that I don't
want to have (think of disk space, helping the users with various
different version of which you don't even know that they exist). Oh, and
I'd like to have a little control of what's installed on "my" systems. At
least Joe Random User (!= Hacker) won't be playing around with 3733t hax0r
t00ls when it doesn't come in a shrink wrapped install wizard like
package (yeah, this would be the worst scenario (the d00des won't shrink
wrap this, hopefully), but think of a netscape communicator ("but it's
the latest beta version - I need this!") in every home directory -- disk
space is valuable). 

> 
> 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>".

As I am very confident with users not able to install the apps alone (or
at least not that easily) it would be a good mechanism if apps worked out
of the box in different directories (/opt, /usr, /usr/local, ...).

> 
> > 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?

Who would need that? In the rare cases where this applies a little shell
script is very handy (e.g. in the times where communicator 4 was still in
beta, I had "netscape" as the original netscape 3 binary and a shell
script "communicator" for the latest communicator beta - does this answer
your question?).

> 
> > 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.

You should be one of my users -- we sure would have big fun together, at
least with this attitude of letting the admin do the dirty stuff, but heck
I may do what I want on this system (even if it's not mine).

> 
> > 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

At least this way the number of cases is drastically reduced, because the
people capable of doing this task will sooner or later run in my office to
have it installed systemwide (oh, and they less often bother me with the
problems arising of their 'private' installation).

> 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,

You have to show me "UNIX's installation method" - I know at least 5.

> nor does it allow users to install their own apps. 

I don't, too :-) Now that's what I call compatibility. We would be losing
one major advantage of UNIX if users installed binaries themselves -- the
lack (or low number) of viruses. 

> 
> > 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.

This doesn't have anything to do with a network of machines -- this is a
special need you have at your systems, but it's not network related.
Nevertheless the handling of multiple version is bogus (read noneexistent)
in rpm.

> 
> 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.

MMMV (my mileage may vary).

> 
> > 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.

Oh a religion thing. I'd beter duck.

> 
> > 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.

Best regards,
Nils
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nils Philippsen                  @college: nils@rhlx01.rz.fht-esslingen.de
Vogelsangstrasse 115             @home:    nils@wombat.dialup.fht-esslingen.de
D 70197 Stuttgart                phone:    +49-711-6599405
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe I should patent stupidity so every lawyer will owe me BIG !!
(mpare@cadvision.com)