3 ms·
It's very far from true for many of languages. Tried to gradually upgrade projects written Ruby and Python, that were not touched in 10 years. The dependencies
by kunley 3y ago
It's very far from true for many of languages.
Tried to gradually upgrade projects written Ruby and Python, that were not touched in 10 years. The dependencies were based on C extensions that depended on libs not existing anymore. It was even impossible to get the original version compiled, because in was dependent on a Linux distro version that doesn't exist anymore, even as docker images.
That was the hard lesson: depending on dynamically loaded libs means you need to constantly maintain the project and even if it has no visible bugs, or doesn't depend on the code having security vulnerabilities, you need to adapt it to evolve together with the libs, and that is needed even if you actually use only what's "old" in the libs. But we're not saving every megabyte of a disk space anymore like in 90s. Switching to static compilation does wonders for maintainability.
- hiepph 3y agoI think the only option to make sure it will run in the 10 years is to package the linking libraries and all the dependencies. Container (e.g. Docker) or Nix can solve this, provided that these technology still live in the next 10 years.
- dragonwriter 3y agoYou can vendor compiled dynamically loaded libraries, too, installing them with your program if not available. If you actually need them to be the same version used by something else on the system, that's still a peoblem, but static compilation doesn't solve that, anyway.
- kunley 3y agoIt is not about vendoring. Vendored dynamic libs would be depending or other libs or even on glibc that does not exist anymore. You can't recreate the dynamic libs environment. With static you don't need that environment, only the kernel, so yes, static compilation solves the problem.