3 ms·

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

theteapot 2y ago
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.
hashstring 2y ago
What do you mean with “a nightmare to install and work with” exactly?
- gessha 2y ago
  They use Windows. \s
  - JodieBenitez 2y ago
    Python has official installers for windows, is distributed in the Microsoft store and can also be pulled out by UV which works a breeze in Powershell.
    - Iwan-Zotow 2y ago
      What is UV?
      - wisenull 2y ago
        https://github.com/astral-sh/uv https://github.com/astral-sh/uv
supriyo-biswas 2y ago
For Python, take a look at the musl builds in python-build-standalone[1], which are statically linked. I also have a tiny collection of statically linked utilities available here[2]. [1] https://github.com/astral-sh/python-build-standalone https://github.com/astral-sh/python-build-standalone [2] https://github.com/supriyo-biswas/static-builds https://github.com/supriyo-biswas/static-builds
throwaway48476 2y ago
Were stuck with a computing paradigm from 50 years ago. Ideally everything would be statically linked but thr sections would be marked and deduped by the filesystem.
- microtonal 2y ago
  Even though the idea is much older, shared libraries were only introduced on Unix systems on SunOS 4.x and System V release 3 (?). Sun paper from 1988: https://www.cs.cornell.edu/courses/cs414/2001FA/sharedlib.pdf https://www.cs.cornell.edu/courses/cs414/2001FA/sharedlib.pd...
- LtWorf 2y ago
  They'd still be duplicated in RAM in the page cache… which is the real problem with static linking.
kpcyrd 2y ago
Due to the python reference I think you mean "compiles into a single binary", not necessarily "static linking". 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.

theteapot 2y ago

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.

hashstring 2y ago

What do you mean with “a nightmare to install and work with” exactly?

gessha 2y ago
They use Windows. \s
- JodieBenitez 2y ago
  Python has official installers for windows, is distributed in the Microsoft store and can also be pulled out by UV which works a breeze in Powershell.
  - Iwan-Zotow 2y ago
    What is UV?
    - wisenull 2y ago
      https://github.com/astral-sh/uv https://github.com/astral-sh/uv

supriyo-biswas 2y ago

For Python, take a look at the musl builds in python-build-standalone[1], which are statically linked. I also have a tiny collection of statically linked utilities available here[2]. [1] https://github.com/astral-sh/python-build-standalone https://github.com/astral-sh/python-build-standalone [2] https://github.com/supriyo-biswas/static-builds https://github.com/supriyo-biswas/static-builds

throwaway48476 2y ago

Were stuck with a computing paradigm from 50 years ago. Ideally everything would be statically linked but thr sections would be marked and deduped by the filesystem.

microtonal 2y ago
Even though the idea is much older, shared libraries were only introduced on Unix systems on SunOS 4.x and System V release 3 (?). Sun paper from 1988: https://www.cs.cornell.edu/courses/cs414/2001FA/sharedlib.pdf https://www.cs.cornell.edu/courses/cs414/2001FA/sharedlib.pd...
LtWorf 2y ago
They'd still be duplicated in RAM in the page cache… which is the real problem with static linking.

kpcyrd 2y ago

Due to the python reference I think you mean "compiles into a single binary", not necessarily "static linking". 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.