5 ms·

Yet, people find static Go and Rust binaries a useful feature, so clearly there is some notable problem with the Linux ecosystem that static linking addresses.

Yet, people find static Go and Rust binaries a useful feature, so clearly there is some notable problem with the Linux ecosystem that static linking addresses. In particular there's tension between running enterprise distros on servers and getting stuff deployed when the system libs are very old.

ilammy 9y ago
It's not even about being old, but having different versions. Take libcurl and OpenSSL for example. Some distros use OpenSSL 1.0.2, some default to OpenSSL 1.1.0, in some cases libcurl depends on 1.0.2, but the system in general prefers OpenSSL 1.1.0. Which one should you use in your application for crypto? Obviously, the sane decision is to provide a separate build for each distro which uses the libraries bundled with the distro. Or you can just link everything statically (and then security updates of OpenSSL become your problem). Then also come QA people and management, which want to support multiple distros, but do not want to support multiple packages (as they are different and require separate QA effort), plus the users would find it hard to install an appropriate package for their distro. So... it's more convenient to just link statically.
zaarn 9y ago
Static linking used to be how everyone deployed software. The argument for dynamic linking was mainly "we can save a lot of diskspace and memory" (which it didn't when you account for how UNIX worked back then) Of course nowadays you also use it to quickly patch security holes in applications without having to relink them. IMO the proper way would be to simply relink the binary with patched libraries as default and only use dynamic linking where it's necessary. Statically linked binaries work far better in my experience, I can run (some) go programs on ancient 2.3 linux kernels (last i tested atleast) without complaint but any modern Firefox will likely refuse since the libraries in that specific distro are ancient af.
- pjmlp 9y ago
  I find it ironic that young generations only used to GNU/Linux glibc dynamic linking, find static linking something out of the ordinary. Like you say, it was how everyone deployed software.
  - zaarn 9y ago
    I count myself as the young generation (21), static linking is out of the ordinary since it is rarely done for software I run (outside my Rust and Go development). But I still think it's how software should be deployed, it should be the norm. I blame developing in Go.
ris 9y ago
> Yet, people find static Go and Rust binaries a useful feature People find junk food convenient, but encouraging people to form a habit based on it is no favour to them. Both situations prioritize instant gratification, the difference is that with downloading random binaries, you really only need one of them to lead to trouble for it not to have been worth it. > some notable problem with the Linux ecosystem How so? Care to name a platform which has "solved" this problem? They're all either "go and download a random binary from a random site and plonk it somewhere/run an installer that does god-knows-what" or lead you to installing "apps" that are so isolated from one other that general purpose productivity on such a platform is almost impossible.

ilammy 9y ago

It's not even about being old, but having different versions. Take libcurl and OpenSSL for example. Some distros use OpenSSL 1.0.2, some default to OpenSSL 1.1.0, in some cases libcurl depends on 1.0.2, but the system in general prefers OpenSSL 1.1.0. Which one should you use in your application for crypto? Obviously, the sane decision is to provide a separate build for each distro which uses the libraries bundled with the distro. Or you can just link everything statically (and then security updates of OpenSSL become your problem). Then also come QA people and management, which want to support multiple distros, but do not want to support multiple packages (as they are different and require separate QA effort), plus the users would find it hard to install an appropriate package for their distro. So... it's more convenient to just link statically.

zaarn 9y ago

Static linking used to be how everyone deployed software. The argument for dynamic linking was mainly "we can save a lot of diskspace and memory" (which it didn't when you account for how UNIX worked back then) Of course nowadays you also use it to quickly patch security holes in applications without having to relink them. IMO the proper way would be to simply relink the binary with patched libraries as default and only use dynamic linking where it's necessary. Statically linked binaries work far better in my experience, I can run (some) go programs on ancient 2.3 linux kernels (last i tested atleast) without complaint but any modern Firefox will likely refuse since the libraries in that specific distro are ancient af.

pjmlp 9y ago
I find it ironic that young generations only used to GNU/Linux glibc dynamic linking, find static linking something out of the ordinary. Like you say, it was how everyone deployed software.
- zaarn 9y ago
  I count myself as the young generation (21), static linking is out of the ordinary since it is rarely done for software I run (outside my Rust and Go development). But I still think it's how software should be deployed, it should be the norm. I blame developing in Go.

ris 9y ago

> Yet, people find static Go and Rust binaries a useful feature People find junk food convenient, but encouraging people to form a habit based on it is no favour to them. Both situations prioritize instant gratification, the difference is that with downloading random binaries, you really only need one of them to lead to trouble for it not to have been worth it. > some notable problem with the Linux ecosystem How so? Care to name a platform which has "solved" this problem? They're all either "go and download a random binary from a random site and plonk it somewhere/run an installer that does god-knows-what" or lead you to installing "apps" that are so isolated from one other that general purpose productivity on such a platform is almost impossible.