I have just sent this out to the SATLUG mail list and I thought I would also put it here for people to think about:

I was looking in the Debian Package Manager at the Libraries section. Doing a quick count I came up with about 2,900 of them. Yes, I know that not all of them are part of every installation, but I have probably 300 of them installed.

Windows has many .dll packages. On my Windows 7 machine I have over 10,700 of them on the disk.

I do not have a MAC so I do not know what they have.

Has there ever been a group that has looked at all the different .lib packages to see if there are two or more .lib's doing the same thing or very close to the same thing?

How much memory and disk space could we save if we just cut the number of .lib's by 10% to 15%?

How much faster would Linux run if it did not have to jump from .lib to .lib?

Or as I`ve said many times. Library statistics to get a handle on all of this.
I`d like to know how commonly used libs. are. I know most are seldom used.
Complete dependency trees for the "better" apps. would show lib. usage.
And also what group of apps. are the libs. used by? Audio, Video, Office, etc.

# It seems to me that this data is critical to the proper design of an O.S.
.

Or kick all libs out and start supply static linked applications where ever possible? This also makes the apps usable between puppy versions even usable on other linux-es...
Once found an 5 year old mplayer compiled static with diet libc - worked out of the box in puppy. Recent packages compiled on the new Puppy versions wont run in my P412 as glibc version has changed.

The packages with static linked apps might be bigger than the dynamic linked counterparts - but storage space and ram is normally not a restricted resource these days.

The packages with static linked apps might be bigger than the dynamic linked counterparts - but storage space and ram is normally not a restricted resource these days.

But I would think that it would still be valuable to use this approach even on a system with low resources wouldn't it? If I am trying to make some use of an older laptop with little ram I would think it would be possible to load only the one static app I needed, and ignore all the other thousands of shared libs I don't want. (If my old laptop can only be run as a fileserver at least it's still being useful...)

greengeek: I agree - but I am no expert here. I think that doing apps small and static make them more usable in time and space - although some programs are "impossible" to link static without severe rebuilding of the source...and then you have to live without or accept the libraries.

goingnuts, just curious, what are some of those programs that "can't" be static-linked?

I have two on which I gave up: xrdp-v0.7.0 which works by dynamic load of the appropriate library one is going to use. And the gtk1-theme engines seems also to use this technique. Might be that there are ways around but I haven't found any.

Has there ever been a group that has looked at all the different .lib packages to see if there are two or more .lib's doing the same thing or very close to the same thing?

How much memory and disk space could we save if we just cut the number of .lib's by 10% to 15%?

How much faster would Linux run if it did not have to jump from .lib to .lib?

When you compile applications yourself you become keenly aware of how many libraries do very similar things. Distributions often have multiple libraries for the same function that do things their own way or more than one version of the same library because certain programs require a particular version.

I haven't seen any official counts, but I've been building a lot of applications from scratch and have been attempting to limit number of dependencies. Here are some examples. Should you use openssl, gnutls or nss? There are differences in licensing for these three communications libraries, plus some are easier to build than others. Should you use jpegsrc from IJG or libjpeg-turbo. What about expat or libxml2? What about gnu readline or editline? Also, which GUI libraries (SDL, ncurses, fltk, wx widgets, fox toolkit, qt3, qt4, qt5, gtk+ 2, gtk+ 3) should one use? Each takes up room. Can you get all the applications you need with one library or do you need several and which can you do without? If you can find applications that work on more lightweight GUI libraries, you can save a lot of room by leaving out some of the heavyweights.

Many distributions seem to have packages with dependencies that one doesn't necessarily need. They try to supply everything any user could need, not optimize for a specific uses. Sometimes multiple libraries with similar function are needed because specific applications may only work with one of the many libraries that provide that function. If two applications using different libraries for the same function are needed, you're stuck needing both libraries if you want both applications. That or rewrite the application to use another library. (I'm personally looking at rewriting command line program sdcv to avoid needing the GTK GUI library.)

I don't think cutting down on libraries would necessarily make the applications run any faster. It may simplify install and update though.

Also, someone mentioned static linking. It doesn't necessarily take up more more memory to static link. Some interesting information on static linking is available at http://sta.li/faq

It's difficult trying to figure out just which libraries are a necessary minimum. Every user will have his or her own opinion. Issues such as wanting to stick with certain types of licenses can greatly affect decisions. For instance, one cannot use openssl (Apache 1.0 and BSD 4 clause licenses) in a GPL licensed program without some waiver in the program licensing to use it or you are violating the GPL license. You just can't satisfy every user. I love the idea of optimizing one's system to use minimal dependencies and try to remove redundant libraries. However, I haven't run across any useful resources on how best to accomplish that. Would love to compare notes on this subject if anyone's interested in discussing it further.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum