Another thing I'd love to see is more statically linked binaries. Something like Python, for instance, is a nightmare to install and work with
> Packages including libraries should exclude static libs as far as possible (eg by configuring with --disable-static). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions.
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/
Packaging guidelines from a distros docs like this are not any kind of counter argument to that comment.
This is the current orthodoxy, so obviously all docs say it. We all know the standard argument for the current standard. Their comment was explicitly "I'd like to see a change from the current orthodoxy". They are saying that maybe that argument is not all it promised to be back in the 90's when we started using dynamic libs.
The common thing to do for python programs that are not directly bundled with the os is to set up a separate virtual environment for each one and download/compile the exact version of each dependency from scratch.
Dynamic linking gives you M binaries + N libraries. Static linking is M * N.
What I said specifically is I'd rather a static binary than a flatpak/snap/appimage/docker/etc. That is a comparison between 2 specific things, and neither of them is "1000 programs using 1000 libraries"
And some binaries already ship with their own copies of all the libraries anyway, just in other forms than static linking. If there are 1000 flatpaks/snaps/docker images etc, then those million libraries are already out there in an even worse form than if they were all static binaries. But there are not, generally, on any give single system, yet, though the number is growing not shrinking.
For all the well known and obvious benefits of dynamic linking, there are reasons why sometimes it's not a good fit for the task.
And in those cases where, for whatever reason, you want the executable to be self-contained, there are any number of ways to arrange it, from a simple tar with the libs & bin in non-conflicting locations and a launcher script that sets a custom lib path (or bin is compiled with the lib path), to appimage/snap/etc, to a full docker/other container, to unikernel, to simple static bin.
All of those give different benefits and incur different costs. Static linking simply has the benefit of being dead simple. It's both space and complexity-efficient compared to any container or bundle system.
I also have a tiny collection of statically linked utilities available here[2].
Ideally everything would be statically linked but thr sections would be marked and deduped by the filesystem.
This binary may be statically linked, or link to system libraries. Quite a few times the only system library being linked is libc though.
But yes, I also hope this gets more prevalent instead of the python approach.