5 ms·

Additionally I would say at least `dbus`, `gnutls`, `libssh2` and maybe?? `curl` are this kind of libraries which count as "widely used system libraries". I.e.

Additionally I would say at least `dbus`, `gnutls`, `libssh2` and maybe?? `curl` are this kind of libraries which count as "widely used system libraries". I.e. the few for which Linus thinks dynamic linking still can make sense ;=)

chasil 6y ago
Shared library and .DLL usage is like freedom, and writing a constitution. Where you can agree, you share. Where you cannot agree, you table and hold. Perhaps we are trying to share too much. I have removed shared libraries from internal code for similar reasons.
bch 6y ago
I think none of those (at least two, nearly surely) might qualify for that exemption. On the vast majority of systems I bet libcurl, for example, is probably linked against by 1 other piece of software - curl(1). “Really useful” isn’t the qualifier here. I bet ~same for libssh. dbus and gnutls I’d have to see more examples to understand.
- throwaway525142 6y ago
  I think you misunderstand how widely used libcurl is. On Arch Linux, it has 291 reverse dependencies: https://archlinux.org/packages/core/x86_64/curl/ https://archlinux.org/packages/core/x86_64/curl/. It is e.g. used by git, cargo (Rust's package manager) and cmake (C++ build system). It's literally installed on 99.99% of all Arch Linux systems: https://www.archlinux.de/packages/core/x86_64/curl https://www.archlinux.de/packages/core/x86_64/curl.
  - ahartmetz 6y ago
    I think that the kind of "knowledge" you are correcting is informing much of the discussion here. And it seems like the motivation is "I want to make MY thing as easy to ship as possible!". There are hundreds of binaries in a Linux system and no one wants to rebuild all of them when an important library is updated.
    - CRConrad 6y ago
      > There are hundreds of binaries in a Linux system and no one wants to rebuild all of them when an important library is updated. Oh, Idunno... How certain are you of this, and why?
      - pdkl95 6y ago
        VERY certain $ find /{,usr/}{,s}bin/ -maxdepth 1 -type f \ | wc -l 5616 $ du -h --total --no-dereference \ $(find /{,usr/}{,s}bin/ -maxdepth 1 -type f) \ | tail -n 1 1.3G total That's with shared libraries and debug symbols stripped. If I upgrade libc, why would I want to also waste a massive amount of time rebuilding all 5616 binaries? Of course, even if we ignore the insane buld time, I don't have the source for some of those binaries, and in a few cases the source no longer exists. In those cases, should I be forced to only use those programs with the (buggy) versions of the libraries they were originally built with?
        scatters 6y ago
        1.3 GB? It's 2021, I can read that from SSD into memory in less than the blink of an eye. Hard disk is fast and cheap enough that it's worth keeping builds around to incremental rebuild against new libraries. Also, typically tests require a build tree, and you are going to rerun tests on the relinked binaries, aren't you?
  - bch 6y ago
    You’re absolutely right, I did misunderstand :/ Colour me a bit surprised, and corrected.
- colonwqbang 6y ago
  Libcurl is the only sane way I know to access the web from a C or C++ environment. I expect that most C programs needing to do web requests will link in libcurl.
yrro 6y ago
Some kind of Linux Standard Base, perhaps?

chasil 6y ago

Shared library and .DLL usage is like freedom, and writing a constitution. Where you can agree, you share. Where you cannot agree, you table and hold. Perhaps we are trying to share too much. I have removed shared libraries from internal code for similar reasons.

bch 6y ago

I think none of those (at least two, nearly surely) might qualify for that exemption. On the vast majority of systems I bet libcurl, for example, is probably linked against by 1 other piece of software - curl(1). “Really useful” isn’t the qualifier here. I bet ~same for libssh. dbus and gnutls I’d have to see more examples to understand.

throwaway525142 6y ago
I think you misunderstand how widely used libcurl is. On Arch Linux, it has 291 reverse dependencies: https://archlinux.org/packages/core/x86_64/curl/ https://archlinux.org/packages/core/x86_64/curl/. It is e.g. used by git, cargo (Rust's package manager) and cmake (C++ build system). It's literally installed on 99.99% of all Arch Linux systems: https://www.archlinux.de/packages/core/x86_64/curl https://www.archlinux.de/packages/core/x86_64/curl.
- ahartmetz 6y ago
  I think that the kind of "knowledge" you are correcting is informing much of the discussion here. And it seems like the motivation is "I want to make MY thing as easy to ship as possible!". There are hundreds of binaries in a Linux system and no one wants to rebuild all of them when an important library is updated.
  - CRConrad 6y ago
    > There are hundreds of binaries in a Linux system and no one wants to rebuild all of them when an important library is updated. Oh, Idunno... How certain are you of this, and why?
    - pdkl95 6y ago
      VERY certain $ find /{,usr/}{,s}bin/ -maxdepth 1 -type f \ | wc -l 5616 $ du -h --total --no-dereference \ $(find /{,usr/}{,s}bin/ -maxdepth 1 -type f) \ | tail -n 1 1.3G total That's with shared libraries and debug symbols stripped. If I upgrade libc, why would I want to also waste a massive amount of time rebuilding all 5616 binaries? Of course, even if we ignore the insane buld time, I don't have the source for some of those binaries, and in a few cases the source no longer exists. In those cases, should I be forced to only use those programs with the (buggy) versions of the libraries they were originally built with?
      - scatters 6y ago
        1.3 GB? It's 2021, I can read that from SSD into memory in less than the blink of an eye. Hard disk is fast and cheap enough that it's worth keeping builds around to incremental rebuild against new libraries. Also, typically tests require a build tree, and you are going to rerun tests on the relinked binaries, aren't you?
- bch 6y ago
  You’re absolutely right, I did misunderstand :/ Colour me a bit surprised, and corrected.
colonwqbang 6y ago
Libcurl is the only sane way I know to access the web from a C or C++ environment. I expect that most C programs needing to do web requests will link in libcurl.

yrro 6y ago

Some kind of Linux Standard Base, perhaps?