Reply to post: Re: JS lib house of cards - you ARE the weakest link!

Re: JS lib house of cards - you ARE the weakest link!

"Back in the day" I chose to ALWAYS static link libraries to PREVENT the "DLL Hell" in Windows. And in POSIX systems, if I don't build from source [or have a package available in the distro], I'll want to do the SAME THING for _MY_ stuff. Reason: A midnight phone call due to "some third party dweeb" screwing up or NOT being able to make swift updates [in the cases of a 'cloud update' model which I won't do anyway] won't happen to ME because some *IDIOT* "developer" was... THE WEAKEST LINK.

While that certainly has advantages, it also has significant downsides to.

Say, for example, you use an OpenSSL library in your code. And a critical bug is found in OpenSSL (e.g. heartbleed).

In the normal course of events, system admins would download the OpenSSL patch and distribute that to their servers, so any application using the system provided OpenSSL library is now patched.

However, for your app, you need to download the patch, recompile your app with the patch, and then distribute this new binary to whatever servers (or customers, but I do note you said for 'your' apps, so assuming you aren't talking about an app you distribute to third parties ;) ) are using your app.

Now, this may be fine for a home project, where your app is the only non-system application running. But if everyone does this, and on a server is a dozen different apps, then the system admins, in addition to applying the OpenSSL patch to the system for those system apps that use it, then have to go out to all the various vendors of those dozen apps and obtain the application-specific patches for each of those apps from each of those vendors, and then go and apply those patches to each of those apps, to fix a single bug in a single - now statically linked - OpenSSL library.

So rather than applying 1 patch across a couple servers, or dozens, or even thousands in a large organisation, they now have to apply dozens, hundreds, thousands of different patches across different random selections of servers (some servers have app A, others have B, some have A+B+C, some have B+Z, etc. all of which may need to be patched).

Also, statically linking a library means increased memory use. Every application that has that library inside the app, statically linked, will be running a full copy of that library in memory, having the same code duplicated and stored in memory for each of the apps, 10 apps with statically linked 10MB fred.so? 100MB of memory in use just for the instructions of that library since there are 10 full copies of it in memory.

When a shared library (Windows DLL, POSIX .so, etc.) is dynamically linked then the library is loaded into memory once and each app that needs the services of that library share (hence the term, shared library) that same, single instruction set in memory. So the same 10 apps using the 10MB fred.so, but now dynamically linked, that's only 10MB of RAM used for the single copy of that library in memory. Sure, they may need to spawn off a process/thread with it's own stack, instruction pointers and so on, but they don't need their own copy of the code itself in memory.

And 10MB vs 100MB might not sound that bad in typically systems that have 8GB+ just for desktops, let alone servers in the 10's to 100's of GB. But that is just for that one library. Even simple apps (e.g. say a notepad) may have a half dozen libraries linked to it, complex apps could have scores of libraries linked in. Dynamic vs static can save many GBs of RAM in a modern system running dozens of background services all with their dynamically linked libraries instead of statically linked.