juliusz schrieb:
Quote
willi krenn wrote:
>
>I can not understand however, why the application directory is not even
>looked at when a search over all other paths fails to find the requested
>lib.
>
Because it is unreliable, insecure and it is just completely
unnecessary...what's application directory anyway?
I know that an "application directory" per se doesn't exist on Linux
(which is a pity, because there we have various levels of /bin, then
there is /opt and you never know exactly where to find some program AND
you constantly have to become su when you have to tune/configure some
files in these directories that should have mappings somewhere in ~/
(tex comes to mind) ).
It's always cool on Linux when you do a rpm install, then type the
application name on prompt - and nothing happens. Bad luck - now you
have to search for the binary (cause you don't know where it has gone)
and modify some searchpath. (So much for Linux and standards..)
Furthermore I don't think it would be insecure, 'cause everyone may set
the LD_XY environment variable and gets the same result. Honestly I do
not know, why you are of the opinion that loading .sos from 'application
directory' is unreliable? If built into the loader?
Quote
I can see where you are coming from;
From DOS obviously. I prefer the 'copy it to a directory on harddisk
and start working' deployment. Simple, elegant and the best way for
single user installations. (Backup is even easier!)
This could even be done for multi-user installations..
Quote
nobody says that it cannot be done,
that the shared objects be loaded from the application directory but
what is the real benefits of doing this accept perhaps to satisfy old
windows habits?
Whats the benefit of grouping (application dependant) libraries in 10s
of lib subdirectories that have to be mentioned somewhere in ld.so.conf?
As you can see, kde, gnome ... all already have their own 'library
application directory':
/usr/X11R6/lib64/Xaw95
/usr/X11R6/lib64/Xaw3d
/usr/X11R6/lib
/usr/X11R6/lib/Xaw95
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib64
/usr/x86_64-suse-linux/lib64
/usr/x86_64-suse-linux/lib
/usr/local/lib
/usr/openwin/lib
/opt/kde/lib
/opt/kde2/lib
/opt/kde3/lib
/opt/gnome/lib
/opt/gnome2/lib
/lib64
/lib
/usr/lib64
/usr/lib
/usr/local/lib64
/usr/openwin/lib64
/opt/kde/lib64
/opt/kde2/lib64
/opt/kde3/lib64
/opt/gnome/lib64
/opt/gnome2/lib64
The problem here is, if you add
/home/xy/lib
/home/zz/lib
both /home/??/lib directories are searched - regardeless which user is
asking for service..
Quote
I am aware of the fact that Borland could very easy
build in that capability as default behavior into Kylix but they didn't
do it. Why? Because this is not the Linux way, and it would create more
problems. Surely it would be more understandable for a window developer
to “deploy?Kylix application, but in the same time it will lead to
create bad habits, overall poor security of the system and effectively
to clutter the system with many redundant shared objects.
This is the only problem I can see (but I did not say that system libs
should be installed in private directories!). I do not see however, why
loading private shared objects from an application directory should
compromise security?? If a cracker has access to the user account, the
user has lost in any case.
Quote
This approach
of course could be used but only as an *option* for example for testing
or in controlled environment single-user application. But essentially
it does not give the developer any benefits whatsoever, because Linux
already has build in far superior means of doing this in much more
*reliable* and *safer* ways.
Tell me why this is so much safer! If a hacker has access to your user
account, the current way of application deployment won't save the user's
data.
Quote
The fact is that Linux system is designed
around the idea that the installed application location is predefined by
the developer/packager and has to correlate to the system security
requirements and other rules and standards and often the installed files
are spread all over the system in accordance to its respectful
functions...
Then tell me why every majour distributor has another view of these
requirements and standards. What's the purpose of globally installing
applications that are used by only one user. What about license issues?
Why do you think it's positive to store e.g. the program documentation
in a completely separate directory tree and not there where it belongs:
In the application directory?
Quote
by adding another variable (complexity) to the already
complex system will not simplify things, perhaps on the surface it will,
but because this method is inherently unreliable it can come back and
bite you hard in the moment when you are least expected.
You have absolutely no clue how many times Linux bit me in the past. My
first Linux was some SuSE 5.3 - since that time I spent significantly
more time in figuring out work arounds for Linux than for Windows.
I've learned several things:
- It won't work out of the box. (even packages from the distributor tend
to fail)
- If it works, don't try to customize. (Except you have a day off)
- Never try to get a snapshot and compile/install it; It will cause
endless grief with the possible outsight of having to replace half the
system.
- Everything is half finished (IOW: half working)
- No innovation; Most of the time just a clone from several commercial
packages.
Quote
Hey! Linux is all about freedom and flexibility and anyone can modify it
to its needs and redefine its basic behavior no problem there...
That's one of the basic problems :-)
At last, Mono will mostly fix the loading issues - so everyone will be
happy in future, I guess.
Willi