Why are we still using shared libraries?
 

I understand them being used back in the day when we had to save every bit of space imaginable.

I also concede that compiling on different machines might give you a different output.

But these days, custom compilation yields very little improvement, and we have terrabytes of space.

So,.. why dont package maintainers just package up EVERYTHING they need in one package, instead of relying on dependencies?

Instead of Openoffice relying on Erlang 1.2.3.141.9.222-buld00001.alpha.centauri.486, and breaking when that package can't be found, why doesn't the programmer using Erlang 1.2.3.141.9.222-buld00001.alpha.centauri.486 just copy that all into the Openoffice source tree and call it a day? Why depend on the niceties of package maintainers and goodwill from other projects?

Pull in what you need - make it work - distribute it. Stop with the 'I need this one 2 line function from version 12.83.1323.99a-b of foo.alpha-x86.el2 and my program will NOT compile without it!' nonsense.

Its a thought anyway. Sure there are a million intricate reasons why packaging and installation can't be simplified, and a million more why we need dependencies still.

Anyone know the reasons?

Projects that build and distribute their own binaries usually actually do that. (Or they statically link, which is letting the compiler do the same thing). OpenOffice is an example. So are most games, including those on Steam, GOG and the Humble Store.

Nice. Perhaps more programs will follow suit!

it could be worse
we could have the windows "dll hell" issue of every single version all called the same thing

Suppose a bug or security problem is found in a library. Would you rather upgrade one shared library, or tens of applications which are statically compiled with it? Consider that each application upgrade is likely to have new features, new bugs, changed functionality, perhaps a redesigned user interface. Wouldn't that be fun? Not.

I imagine, If everyone started packaging their own libraries and dependencies in their application:

• They would be responsible for security updates, as many of them are now anyway
• They would push out updates, which many of them do now anyway
• Each program might end up using a different version of said library - possibly skirting the vulnerability by way of version,

Something like that.

Got me thinking. Currently, most things use shared libraries right? So, if the library is a security vulnerability, every single thing on the box that uses it is vulnerable. Possibly 100's of programs. Whereas if a program was pacakged with everything it needed, it might come about that only that version of the library is vulnerable, but only one program is using it, rather than 100's sharing it.

Perhaps.

I don't think static libs are a good idea. Like said above, if something changes you'll have to recompile everything. It would also be harder to maintain, and would be less secure because it would take time for them to patch their local version, which may be out-of-date and the patches would need back-porting.

Shared libraries have many advantages and that's why they are used in most cases. The only cases where I don't like it is small libraries that don't even need to exist. I know some small projects like to separate part of their code into libraries, but nobody uses these libraries except for the program they wrote. I guess they are hoping someone would use it.

I believe PC-BSD does this with PBI's.

http://en.wikipedia.org/wiki/PC-BSD#Package_management

And why would that be better? You can upgrade OpenSSL and fix the vulnerability in hundreds of packages immediately, or you can depend on the maintainer of each of those hundreds of packages to individually notice and tell if they've been using a vulnerable version of OpenSSL.

Someone seems to be thinking along the same lines as you, szboardstretcher.

http://www.linuxquestions.org/questi...re-4175524566/

(My personal thought: sounds like Mojo installers and other analagous things).

I'm not sure it would be better.

But there has to be *some* way to make it less of a pain-in-the-ass to install a package, without the dependency calculations required currently.

And, with that link, it certainly seems like other people have been thinking about the issue as well. That's good. If it's being thought about, talked about and tinkered with, then someday the packaging ecosystem might be more homogenous and less prone to the dependency hells that exist.

What dependency hells? I've had to do a bit of juggling with stuff for CentOS from other distros, but that's a penalty of using such a small distro. When testing distros (and I've used 114) only the obscurer ones have had problems with software installation. Except, that is, Debian. Does your profile's "GNU/Linux" entry indicate that you're a Debian user?

Just identifying myself with Linux in general. I've used many (112.5 +- 2%) over the years, and have many different distros that I have to feed at work. I also have a couple of solaris boxes and an AIX db server.

Assuming you are using a package manager like yum, you might not see the various levels of horrific dependency requirements and collisions that happen still to this day. This happens more often when installing software from source - which is the reason that I prefer the handful of programs that come with everything that they need rather than depending on external packages.

I think some of dependency hell is caused by programmers' carelessness when choosing dependencies. I know a number of programs that could reduce their dependency list, especially to less esoteric dependencies that are not well maintained and are hard to install. Please consider this when writing programs and choosing dependencies. I mean, here's a concrete example: OGRE. Yeah, if you've ever tried to install it, you'll be missing some hairs on your head.

I haven't tried to install it, but the Slackware packaging script doesn't look too complex to me:

http://slackbuilds.org/slackbuilds/1...gre.SlackBuild

Am I missing something?

If you're trying to build your own debs or RPMs, yes. If you're just doing ./configure ; make ; make install or building for a distribution that doesn't enforce dependency versions (Slackware, Arch, Gentoo, etc) then no. The build system detects the dependencies that are present on your system.