5 ms·

> I prefer to have things clearly separated in functionality and easily upgradeable. What is your thinking here? Are you talking about a use case where you hav

> I prefer to have things clearly separated in functionality and easily upgradeable. What is your thinking here? Are you talking about a use case where you have an application that uses a library and a bug fix is issued for that library, so you want to just get the new .so for the library and have the application use it? That feels like a niche use case to me. Maybe there is another benefit, or this use case is more common than I realize. I'd be interested in further opinions/info.

cestith 6y ago
That is not at al a niche use case, at least on a general-purpose system. Shared libraries on Linux, like most modern OSes, are also shared in resident memory among programs using them. For very common libraries like TLS, readline, or GTK that can be a big savings.
bityard 6y ago
> That feels like a niche use case to me. I wouldn't call it a niche use case at all, it's exactly how the software for all major Linux and BSD operating systems are packaged and built. For example, when (not if) a vulnerability is found in OpenSSL, package maintainers just commit an update to the openssl package and users only have to download and install one package to patch their system against the vulnerability. Contrast with a fully-static OS and applications: the maintainers would have to update the openssl package, rebuild it, and then also rebuild _every single other program_ that relies on it as well. On my system, that's 123 packages. I don't have all of those installed, but as a user, it means I would have to download new full copies of around a dozen packages to patch one flaw in one package. And of course, the packages themselves are much _much_ larger too. Most software that I can install as a flatpack or appimage are at least an order of magnitude larger than the deb version, take longer to start, and also take up more valuable RAM when running. Proponents of static linking have generally experienced the pain of dynamically-linked software either through container deployment or by accidentally messing up their system with third-party packages and repos and the like. I get it, I have been there too. But even through managing a dynamically linked system is certainly more complex, it brings a lot of benefits to the table.
- abainbridge 6y ago
  OK, that makes sense. I error in my head was imagining a situation where the user was responsible for knowing which openssl .so file to download and where to put it.
- jcelerier 6y ago
  > I wouldn't call it a niche use case at all, it's exactly how the software for all major Linux and BSD operating systems are packaged and built. even though I'm typing this on a linux desktop, this is a niche use case. In Windows, macOS, iOS and Android, so 99.9% of all user-facing computing, all the libraries except the OS API are duplicated for each app.
  - tonyedgecombe 6y ago
    I think the license for the Microsoft C runtime dll's precludes bundling although it does allow static linking. It used to cause me no end of problems because the silent install would often fail.
  - eeZah7Ux 6y ago
    Updating OpenSSL or any other shared library is a "niche use case"?
    - jcelerier 6y ago
      Using OpenSSL is itself a niche on windows / macOS. And it's not about using shared libraries - it's about actually sharing them. I have at least two dozens apps using Qt on my windows desktop but they all use a slightly different or patched Qt version so exactly nothing is gained when compared to static linking
- mleonhard 6y ago
  When you rebuild the binaries that depend on the upgraded library, you can also run their tests and run automated analysis tools. This improves reliability. DLL loading is full of security risks. Static binaries are free of them. DLLs are compiled separately from the binaries that load them. Compilers cannot optimize code that calls into a DLL. Compiler optimizers are amazing these days. Compared to a separately optimized binary + DLL, a completely optimized binary will consume less CPU, use less memory, and cause less heap pressure and fragmentation. DLL's original purpose is reducing memory and disk usage. Since we have different needs now, DLLs are just technical debt.

cestith 6y ago

That is not at al a niche use case, at least on a general-purpose system. Shared libraries on Linux, like most modern OSes, are also shared in resident memory among programs using them. For very common libraries like TLS, readline, or GTK that can be a big savings.

bityard 6y ago

> That feels like a niche use case to me. I wouldn't call it a niche use case at all, it's exactly how the software for all major Linux and BSD operating systems are packaged and built. For example, when (not if) a vulnerability is found in OpenSSL, package maintainers just commit an update to the openssl package and users only have to download and install one package to patch their system against the vulnerability. Contrast with a fully-static OS and applications: the maintainers would have to update the openssl package, rebuild it, and then also rebuild _every single other program_ that relies on it as well. On my system, that's 123 packages. I don't have all of those installed, but as a user, it means I would have to download new full copies of around a dozen packages to patch one flaw in one package. And of course, the packages themselves are much _much_ larger too. Most software that I can install as a flatpack or appimage are at least an order of magnitude larger than the deb version, take longer to start, and also take up more valuable RAM when running. Proponents of static linking have generally experienced the pain of dynamically-linked software either through container deployment or by accidentally messing up their system with third-party packages and repos and the like. I get it, I have been there too. But even through managing a dynamically linked system is certainly more complex, it brings a lot of benefits to the table.

abainbridge 6y ago
OK, that makes sense. I error in my head was imagining a situation where the user was responsible for knowing which openssl .so file to download and where to put it.
jcelerier 6y ago
> I wouldn't call it a niche use case at all, it's exactly how the software for all major Linux and BSD operating systems are packaged and built. even though I'm typing this on a linux desktop, this is a niche use case. In Windows, macOS, iOS and Android, so 99.9% of all user-facing computing, all the libraries except the OS API are duplicated for each app.
- tonyedgecombe 6y ago
  I think the license for the Microsoft C runtime dll's precludes bundling although it does allow static linking. It used to cause me no end of problems because the silent install would often fail.
- eeZah7Ux 6y ago
  Updating OpenSSL or any other shared library is a "niche use case"?
  - jcelerier 6y ago
    Using OpenSSL is itself a niche on windows / macOS. And it's not about using shared libraries - it's about actually sharing them. I have at least two dozens apps using Qt on my windows desktop but they all use a slightly different or patched Qt version so exactly nothing is gained when compared to static linking
mleonhard 6y ago
When you rebuild the binaries that depend on the upgraded library, you can also run their tests and run automated analysis tools. This improves reliability. DLL loading is full of security risks. Static binaries are free of them. DLLs are compiled separately from the binaries that load them. Compilers cannot optimize code that calls into a DLL. Compiler optimizers are amazing these days. Compared to a separately optimized binary + DLL, a completely optimized binary will consume less CPU, use less memory, and cause less heap pressure and fragmentation. DLL's original purpose is reducing memory and disk usage. Since we have different needs now, DLLs are just technical debt.