Static linking OpenSSL is probably not a good idea
You mean for security patches? i.e rebuilding all your binaries, instead of just openssl's shared libs
Static Linux
21–30 of 61 posts
Re: Static Linux
#22 > Because dwm is customized through editing its source code, it’s
> pointless to make binary packages of it. This keeps its userbase
> small and elitist. No novices asking stupid questions.
Re: Static Linux
#23I wish Linux would replace dynamic libraries (especially ones referencing specific paths) with a system based on the library's hash. Then we could have a single lib folder with 1 copy of each library, and get ourselves out of dependency hell by just making dynamic loading act like static loading. We could even download libraries from the web on the fly, if needed. Heck it would even remove a lot of the need to compile every_single_time because apps could reference binaries.
The notion of being able to fix an app by merely upgrading a library it depends on has not worked out in practice. More often than not, when I upgrade a library, I find myself having to upgrade my app’s code because so much has changed. The burden of having to constantly backup, upgrade, manually tweak config files, over and over and over again for days/weeks/months was SO not worth the few hundred megabytes or whatever dynamic loading was supposed to have saved.
Re: Static Linux
#24Earlier quoted context omitted.
And that feature disparity includes security updates. If a library is updated with a security fix, you'll need to update everything that uses that library to get the fix, rather than just the shared dynamic library.
The tools for updating security fixes should be applicable for the applications just as easily as the libraries. The applications would have to be rebuilt which should be automated. If the library changes anything that causes the build to fail, much better to find that out at that time than to have the failure occur when it dynamically links on end user machines. There would be inevitable bandwidth costs in updating…
> There would be inevitable bandwidth costs in updating like this
I don't think that's true. You could transfer only binary differences with bsdiff or something and if there are a lot of them with the same security update - you could go even farther and establish a single patch as a base and all the other patches as differences with the base (or other appropriate compression algorithm). Bandwidth should be very tiny.
Re: Static Linux
#25I wish Linux would replace dynamic libraries (especially ones referencing specific paths) with a system based on the library's hash. Then we could have a single lib folder with 1 copy of each library, and get ourselves out of dependency hell by just making dynamic loading act like static loading. We could even download libraries from the web on the fly, if needed. Heck it would even remove a lot of the need to compil…
> I wish Linux would replace dynamic libraries (especially ones referencing specific paths) with a system based on the library's hash.
This is how NixOS works: http://nixos.org/
Re: Static Linux
#26An advantage of dynamic libraries is that the memory used to hold the library's executable pages can be shared across processes. So using static only binaries will lead to less free memory on the OS.
Re: Static Linux
#27An advantage of dynamic libraries is that the memory used to hold the library's executable pages can be shared across processes. So using static only binaries will lead to less free memory on the OS.
[deleted]
Re: Static Linux
#28I wish Linux would replace dynamic libraries (especially ones referencing specific paths) with a system based on the library's hash. Then we could have a single lib folder with 1 copy of each library, and get ourselves out of dependency hell by just making dynamic loading act like static loading. We could even download libraries from the web on the fly, if needed. Heck it would even remove a lot of the need to compil…
> I wish Linux would replace dynamic libraries (especially ones referencing specific paths) with a system based on the library's hash.
Given this scheme, how would you distribute a security patch? Is each user of the library supposed to re-compile against the patched library?
Also, a program A depends on library B and library C v1.1. Library B also depends on C, but v1.2. Which gets used?
> More often than not, when I upgrade a library, I find myself having to upgrade my app’s code because so much has changed.
To me, this is the point of major version numbers. If you break clients, you increment the major version number, resulting in libfoo.so.2 and libfoo.so.3. Then, the scheme becomes much like hashes, in that newer versions won't break older clients, except you get security patches and a single copy of the library. However, the responsibility of knowing when to increment the major is left to a human, and all the error that entails.
As a sibling notes, there are distros out there that do this. (They are not my preference, for the above reasons.)
Re: Static Linux
#29I wish Linux would replace dynamic libraries (especially ones referencing specific paths) with a system based on the library's hash. Then we could have a single lib folder with 1 copy of each library, and get ourselves out of dependency hell by just making dynamic loading act like static loading. We could even download libraries from the web on the fly, if needed. Heck it would even remove a lot of the need to compil…
> I wish Linux would replace dynamic libraries (especially ones referencing specific paths) with a system based on the library's hash. Given this scheme, how would you distribute a security patch? Is each user of the library supposed to re-compile against the patched library? Also, a program A depends on library B and library C v1.1. Library B also depends on C, but v1.2. Which gets used? > More often than not, when…
I'm no expert, but based on the parent, I think it comes down to what he means by "library hash." If it's a hash (like a checksum) of the whole shared library, then different versions would have different hashes, theoretically.
Re: Static Linux
#30An advantage of dynamic libraries is that the memory used to hold the library's executable pages can be shared across processes. So using static only binaries will lead to less free memory on the OS.
That's the party line. It's often wrong. If two copies of the same program are running, they share memory for code. For a shared library to reduce memory consumption, there must be multiple different programs using the same version of the same library. That's not all that common, beyond very basic libraries such as "libc".
Linking to a shared library brings in and initializes the whole library, even if you only need one function from it. So you tend to get stuff paged in during load that never gets used.