2009/1/15 Matt Sealey <matt@genesi-usa.com>:
On Wed, Jan 14, 2009 at 2:33 PM, Stanislav Visnovsky <visnov@suse.cz> wrote:
One thing I have a serious problem with, which is totally unfixable in Linux if only because it is too much work on thousands of applications, is the fact that every dependency has to be a hard one, enforced at link time of the application.
If you have an image viewer with GIF, JPEG or PNG support, it has to be linked against these and all of them are pulled in by ldso when the application is started.
The dynamic linking finds w here the library is, but the code isn't loaded until page fault occur. The VM has to do it's magic with page tables and such, and share physical memory library code amongst many invocations, but it does it by just memory mapping in code, lazily reading it from disk, when it's unavailable. If everything was "pulled in", there'd only be the benefit of shared text pages compared to static linking, and modular updates. Some programs like perl for example, use a pluggable architecture to allow runtime selection of such support, to reduce link time, and allow usage of features without hard dependencies.
It is absolutely no problem on a lot of other non-Unix operating systems to pull in a shared library if you deem it necessary at that time - for instance if you are viewing a JPEG, there is no need to pull in GIF or PNG support until you're about to load one.
There is a way on Linux etc. (dlopen etc.) but it's simply never used, nor is any other method.
But it is where it makes sense! Perl, Python are a couple of examples.
As an example, I accidentially did rm -rf /usr/lib yesterday (typo in an RPM spec, and I was having trouble with build so I just did it through RPM - it's just a single file packaged anyway) and while I killed it before it did any serious damage, SSH quit working because it could not open "libopensc". Now, I don't use any smartcards or other authentication like that, but this library is loaded anyway. Imagine how much memory this uses, before it's decided it's not being used and is paged out. There is no way for an application to use that library as "optional".
Actually it doesn't really use much memory at all! Because it's a demand paged virtual memory system, not one using "swapping", and furthermore those pages can be shared amongst many processes thanks to COW. Just try adding up, all the virtual memory sizes of processes VSZ, RES and compare with the actual memory of the system. Another example is an X server, which often looked like a huge memory hog, when in fact a large part of it's memory consumption is the mapped memory from the graphics card, rather than system RAM. Though I'm not sure that memory is still counted in the current reporting, so I use pat tense. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org