5 ms·

I think general consensus is against you. Fedora packaging policy [1]: > Packages including libraries should exclude static libs as far as possible (eg by conf

I think general consensus is against you. Fedora packaging policy [1]: > 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/ https://docs.fedoraproject.org/en-US/packaging-guidelines/

Brian_K_White 2y ago
I'd far rather a static binary than a bundled vm for a single app which produces all the same bad points of a static binary plus 900 new bad points on top. 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.
- booi 2y ago
  So instead of 1000 programs and 1000 libraries, you’d rather 1000 programs and 1,000,000 libraries?
  - Brian_K_White 2y ago
    Baffled how you got there, but not interested.
    - MyOutfitIsVague 2y ago
      Their point is that if 1000 programs use the same 1000 libraries, static linking duplicates all those libraries across each binary, taking that much more storage and memory (which can hurt performance as well), effectively making 1000000 libraries in use. Dynamic linking gives you M binaries + N libraries. Static linking is M * N.
      - Brian_K_White 2y ago
        But there are not 1000 programs being proposed. No one said every binary in a system. Only some binaries are a problem. That is silly hyperbole that isn't useful or any kind of valid argument. 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.
  - josefx 2y ago
    Given that the comment is talking about python he probably already has those 1.000.000 libraries. 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.
  - rcxdude 2y ago
    That's already the result from most of these container formats, just messier
- Kudos 2y ago
  I don't know why you'd go straight to a VM as the alternative when containers are the obvious choice.
  - rcxdude 2y ago
    not much difference from a dependency management point of view
  - Brian_K_White 2y ago
    A literal vm is hyperbole and sloppy language on my part. I meant all the different forms of containerising or bundling apps with all of their dependencies and os environment.

Brian_K_White 2y ago

I'd far rather a static binary than a bundled vm for a single app which produces all the same bad points of a static binary plus 900 new bad points on top. 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.

booi 2y ago
So instead of 1000 programs and 1000 libraries, you’d rather 1000 programs and 1,000,000 libraries?
- Brian_K_White 2y ago
  Baffled how you got there, but not interested.
  - MyOutfitIsVague 2y ago
    Their point is that if 1000 programs use the same 1000 libraries, static linking duplicates all those libraries across each binary, taking that much more storage and memory (which can hurt performance as well), effectively making 1000000 libraries in use. Dynamic linking gives you M binaries + N libraries. Static linking is M * N.
    - Brian_K_White 2y ago
      But there are not 1000 programs being proposed. No one said every binary in a system. Only some binaries are a problem. That is silly hyperbole that isn't useful or any kind of valid argument. 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.
- josefx 2y ago
  Given that the comment is talking about python he probably already has those 1.000.000 libraries. 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.
- rcxdude 2y ago
  That's already the result from most of these container formats, just messier
Kudos 2y ago
I don't know why you'd go straight to a VM as the alternative when containers are the obvious choice.
- rcxdude 2y ago
  not much difference from a dependency management point of view
- Brian_K_White 2y ago
  A literal vm is hyperbole and sloppy language on my part. I meant all the different forms of containerising or bundling apps with all of their dependencies and os environment.