8 ms·

It seems to me that several circumstances have changed since the idea of dynamic linking first came about: - A whole lot of software is now open and freely ava

It seems to me that several circumstances have changed since the idea of dynamic linking first came about: - A whole lot of software is now open and freely available - The code-changes-to-binary-updates pipeline has been greased by a couple orders of magnitude, from internet availability to CI to user expectations around automatic updates (for both commercial and non-commercial software) - Disk space, and arguably even RAM, have become very cheap by comparison Given these, it seems worthwhile to re-evaluate the tradeoffs that come with dynamic linking

drewcoo 6y ago
To underscore the gp's point, I have had to work with a 3rd party-provided .so before. No sources. A binary. And strict (if unenforceable) rules about what we could do with the binary.
- CyberDildonics 6y ago
  I don't think that was their point at all. They were saying that dynamic linking creates flexibility and modularity that doesn't exist otherwise.
  - TeMPOraL 6y ago
    I think this was precisely the point. Shared libraries create seams you can exploit if you need to modify behavior of a program without rebuilding it - which is very useful if you don't want to or can't rebuild the program, for example because it's proprietary third-party software.
- mikepurvis 6y ago
  I dealt with a situation like this for a ROS driver for a camera, where the proprietary SO was redistributable, but the headers and the rest of the vendor's "SDK" was not. The vendor clarified for me repeatedly that it would not be acceptable for us to re-host the SDK, that it was only accessible from behind a login portal on their own site. The solution we eventually came to was downloading the SDK on each build, using credentials baked into the downloader script: https://github.com/ros-drivers/pointgrey_camera_driver/blob/ae67188a5b49b56b1d5d5b102301f7d8a3523a92/pointgrey_camera_driver/cmake/download_flycap#L37 https://github.com/ros-drivers/pointgrey_camera_driver/blob/... The vendor was fine with this approach, and it didn't violate their TOU, though it sure did cause a bunch of pain for the maintainers of the public ROS CI infrastructure, as there were various random failures which would pop up as a consequence of this approach. I think eventually the vendor must have relented, as the current version of the package actually does still download at build time, but at least it downloads from a local location— though if that is permissable, I don't know why the headers themselves aren't just included in the git repo.
  - DaiPlusPlus 6y ago
    Have things changed at all since Pointgrey were acquired by FLIR?
    - mikepurvis 6y ago
      To be honest, I haven't really tracked it— the product I work on dropped stereo vision in favour of RGBD, so I don't really know where it's landed. I suppose it's not a great sign that the current generation SDK still requires a login to access: https://www.flir.ca/products/spinnaker-sdk/ https://www.flir.ca/products/spinnaker-sdk/ And at least one spinnaker-based driver seems to have inherited the "download the SDK from elsewhere" approach, though who knows if that's due to genuine need or just cargo-culting forward what was implemented years ago in the flycapture driver: https://github.com/neufieldrobotics/spinnaker_sdk_camera_driver/blob/master/download_and_install_spinnaker.sh https://github.com/neufieldrobotics/spinnaker_sdk_camera_dri... The "proper" approach here would of course be for Open Robotics (the ROS maintainers) to pull the debs and host them on the official ROS repos, as they do for a number of other dependencies [1], but that clearly hasn't happened [2]. I think a lot of hardware vendors who cut their teeth in the totally locked down world of industrial controls/perception still think they're protecting some fantastic trade secret or whatever by behaving like this. [1]: https://github.com/ros-infrastructure/reprepro-updater/tree/master/config https://github.com/ros-infrastructure/reprepro-updater/tree/... [2]: http://packages.ros.org/ros/ubuntu/pool/main/s/ http://packages.ros.org/ros/ubuntu/pool/main/s/
atweiden 6y ago
> Given these, it seems worthwhile to re-evaluate the tradeoffs that come with dynamic linking Perhaps this is just a Linux distro thing, but as someone who closely monitors the Void packages repo, dynamic linking burdens distro maintainers with hundreds of additional packages which need to be individually tracked, tested and updated. (Packages which could otherwise be vendored by upstream and statically linked during the build.) Dynamic linking also adds complexity to distro upgrades, because dependant packages often need to be rebuilt when the libraries they dynamically link to are changed or upgraded. For example, Void’s recent switch from LibreSSL to OpenSSL borked my install script which wasn’t aware of the change. It resulted in a built system whose XBPS package manager couldn’t verify SSL certs. On Arch, AUR packages were notoriously prone to dynamic linking errors (back when I still used it). Personally, I don’t find the bandwidth efficiency and CVE arguments for dynamic linking to be all that convincing [1]: Will security vulnerabilities in libraries that have been statically linked cause large or unmanagable updates? Findings: not really Not including libc, the only libraries which had "critical" or "high" severity vulnerabilities in 2019 which affected over 100 binaries on my system were dbus, gnutls, cairo, libssh2, and curl. 265 binaries were affected by the rest. The total download cost to upgrade all binaries on my system which were affected by CVEs in 2019 is 3.8 GiB. This is reduced to 1.0 GiB if you eliminate glibc. It is also unknown if any of these vulnerabilities would have been introduced after the last build date for a given statically linked binary; if so that binary would not need to be updated. Many vulnerabilities are also limited to a specific code path or use-case, and binaries which do not invoke that code path in their dependencies will not be affected. A process to ascertain this information in the wake of a vulnerability could be automated. [1]: https://drewdevault.com/dynlib https://drewdevault.com/dynlib
- rkeene2 6y ago
  As someone who runs a Linux distribution, please don't vendor your dependencies for the benefit of distribution maintainers, it makes it much more difficult to build a coherent system. Running different versions of common libraries causes real annoyances.
  - 6y ago
vonwoodson 6y ago
Isn’t this especially true in the world of containerization? We literally ship entire images or configurations of OS’s to run a single application or system function. Although, I have mixed feeling about containers, because I fully appreciate that Unix is the application and the software that runs on it are just the calculations. In that world, sure, a shared library makes sense the same way a standard library makes sense for a programming language. Thus, a container is “just” a packaged application. Regardless, this concept is so out of the realm of “performance” that it’s worth noting that the idea of trying to reduce memory use or hard disk space is not a valid argument for shared libraries.
- FartyMcFarter 6y ago
  Google's distroless containers attempt to fix this issue: https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless
gautamdivgi 6y ago
One tradeoff is security. If you're patching vulnerabilities, then just a single .so needs to be patched. With static linking every binary needs to be investigated and patched.
- nickez 6y ago
  You can also argue that it is impossible to update dynamic libraries because they are used by multiple applications and you can't afford that any application breaks. So instead of being able to patch that one application where the security is needed, you now have to patch all of them.
  - gspr 6y ago
    > You can also argue that it is impossible to update dynamic libraries because they are used by multiple applications and you can't afford that any application breaks. That's where maintenance branches comes in. You fix only the security issue, and push out a new version.
alerighi 6y ago
Also compilers nowadays are smarter and can perform link time optimizations. Meaning that if of a library you only use a single function, in the final executable you would only get that single function. In reality code that use static linking could be more efficient than code that uses dynamic linking. And you have to consider some performance penalty when using shared libraries. First you have a time penalty when loading the executable, since first you have to run the interpreter (ld-linux) and then your actual code. But also for each function call you have to make an indirect jump into it.
- bonzini 6y ago
  > But also for each function call you have to make an indirect jump into it. Only the first call has a penalty. Then you call into the PLT and the PLT contains a direct jump to the function.
  - kaba0 6y ago
    It still has a cost over potential inlining (that allows for more optimizations as well). Of course if it is not a hotspot, it is meaningless.
  - creamytaco 6y ago
    The call into the PLT is a penalty.
    - bonzini 6y ago
      Sure but it's not an indirect jump.
drran 6y ago
> Disk space, and arguably even RAM, have become very cheap by comparison CPU frequency and CPU cache are remaining small, so smaller binaries, which fit the cache, are running faster, and use less energy, and wastes less resources overall. > Given these, it seems worthwhile to re-evaluate the tradeoffs that come with dynamic linking Create your own distribution and show us benefits of static linking.

drewcoo 6y ago

To underscore the gp's point, I have had to work with a 3rd party-provided .so before. No sources. A binary. And strict (if unenforceable) rules about what we could do with the binary.

CyberDildonics 6y ago
I don't think that was their point at all. They were saying that dynamic linking creates flexibility and modularity that doesn't exist otherwise.
- TeMPOraL 6y ago
  I think this was precisely the point. Shared libraries create seams you can exploit if you need to modify behavior of a program without rebuilding it - which is very useful if you don't want to or can't rebuild the program, for example because it's proprietary third-party software.
mikepurvis 6y ago
I dealt with a situation like this for a ROS driver for a camera, where the proprietary SO was redistributable, but the headers and the rest of the vendor's "SDK" was not. The vendor clarified for me repeatedly that it would not be acceptable for us to re-host the SDK, that it was only accessible from behind a login portal on their own site. The solution we eventually came to was downloading the SDK on each build, using credentials baked into the downloader script: https://github.com/ros-drivers/pointgrey_camera_driver/blob/ae67188a5b49b56b1d5d5b102301f7d8a3523a92/pointgrey_camera_driver/cmake/download_flycap#L37 https://github.com/ros-drivers/pointgrey_camera_driver/blob/... The vendor was fine with this approach, and it didn't violate their TOU, though it sure did cause a bunch of pain for the maintainers of the public ROS CI infrastructure, as there were various random failures which would pop up as a consequence of this approach. I think eventually the vendor must have relented, as the current version of the package actually does still download at build time, but at least it downloads from a local location— though if that is permissable, I don't know why the headers themselves aren't just included in the git repo.
- DaiPlusPlus 6y ago
  Have things changed at all since Pointgrey were acquired by FLIR?
  - mikepurvis 6y ago
    To be honest, I haven't really tracked it— the product I work on dropped stereo vision in favour of RGBD, so I don't really know where it's landed. I suppose it's not a great sign that the current generation SDK still requires a login to access: https://www.flir.ca/products/spinnaker-sdk/ https://www.flir.ca/products/spinnaker-sdk/ And at least one spinnaker-based driver seems to have inherited the "download the SDK from elsewhere" approach, though who knows if that's due to genuine need or just cargo-culting forward what was implemented years ago in the flycapture driver: https://github.com/neufieldrobotics/spinnaker_sdk_camera_driver/blob/master/download_and_install_spinnaker.sh https://github.com/neufieldrobotics/spinnaker_sdk_camera_dri... The "proper" approach here would of course be for Open Robotics (the ROS maintainers) to pull the debs and host them on the official ROS repos, as they do for a number of other dependencies [1], but that clearly hasn't happened [2]. I think a lot of hardware vendors who cut their teeth in the totally locked down world of industrial controls/perception still think they're protecting some fantastic trade secret or whatever by behaving like this. [1]: https://github.com/ros-infrastructure/reprepro-updater/tree/master/config https://github.com/ros-infrastructure/reprepro-updater/tree/... [2]: http://packages.ros.org/ros/ubuntu/pool/main/s/ http://packages.ros.org/ros/ubuntu/pool/main/s/

atweiden 6y ago

> Given these, it seems worthwhile to re-evaluate the tradeoffs that come with dynamic linking Perhaps this is just a Linux distro thing, but as someone who closely monitors the Void packages repo, dynamic linking burdens distro maintainers with hundreds of additional packages which need to be individually tracked, tested and updated. (Packages which could otherwise be vendored by upstream and statically linked during the build.) Dynamic linking also adds complexity to distro upgrades, because dependant packages often need to be rebuilt when the libraries they dynamically link to are changed or upgraded. For example, Void’s recent switch from LibreSSL to OpenSSL borked my install script which wasn’t aware of the change. It resulted in a built system whose XBPS package manager couldn’t verify SSL certs. On Arch, AUR packages were notoriously prone to dynamic linking errors (back when I still used it). Personally, I don’t find the bandwidth efficiency and CVE arguments for dynamic linking to be all that convincing [1]: Will security vulnerabilities in libraries that have been statically linked cause large or unmanagable updates? Findings: not really Not including libc, the only libraries which had "critical" or "high" severity vulnerabilities in 2019 which affected over 100 binaries on my system were dbus, gnutls, cairo, libssh2, and curl. 265 binaries were affected by the rest. The total download cost to upgrade all binaries on my system which were affected by CVEs in 2019 is 3.8 GiB. This is reduced to 1.0 GiB if you eliminate glibc. It is also unknown if any of these vulnerabilities would have been introduced after the last build date for a given statically linked binary; if so that binary would not need to be updated. Many vulnerabilities are also limited to a specific code path or use-case, and binaries which do not invoke that code path in their dependencies will not be affected. A process to ascertain this information in the wake of a vulnerability could be automated. [1]: https://drewdevault.com/dynlib https://drewdevault.com/dynlib

rkeene2 6y ago
As someone who runs a Linux distribution, please don't vendor your dependencies for the benefit of distribution maintainers, it makes it much more difficult to build a coherent system. Running different versions of common libraries causes real annoyances.
- 6y ago

vonwoodson 6y ago

Isn’t this especially true in the world of containerization? We literally ship entire images or configurations of OS’s to run a single application or system function. Although, I have mixed feeling about containers, because I fully appreciate that Unix is the application and the software that runs on it are just the calculations. In that world, sure, a shared library makes sense the same way a standard library makes sense for a programming language. Thus, a container is “just” a packaged application. Regardless, this concept is so out of the realm of “performance” that it’s worth noting that the idea of trying to reduce memory use or hard disk space is not a valid argument for shared libraries.

FartyMcFarter 6y ago
Google's distroless containers attempt to fix this issue: https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless

gautamdivgi 6y ago

One tradeoff is security. If you're patching vulnerabilities, then just a single .so needs to be patched. With static linking every binary needs to be investigated and patched.

nickez 6y ago
You can also argue that it is impossible to update dynamic libraries because they are used by multiple applications and you can't afford that any application breaks. So instead of being able to patch that one application where the security is needed, you now have to patch all of them.
- gspr 6y ago
  > You can also argue that it is impossible to update dynamic libraries because they are used by multiple applications and you can't afford that any application breaks. That's where maintenance branches comes in. You fix only the security issue, and push out a new version.

alerighi 6y ago

Also compilers nowadays are smarter and can perform link time optimizations. Meaning that if of a library you only use a single function, in the final executable you would only get that single function. In reality code that use static linking could be more efficient than code that uses dynamic linking. And you have to consider some performance penalty when using shared libraries. First you have a time penalty when loading the executable, since first you have to run the interpreter (ld-linux) and then your actual code. But also for each function call you have to make an indirect jump into it.

bonzini 6y ago
> But also for each function call you have to make an indirect jump into it. Only the first call has a penalty. Then you call into the PLT and the PLT contains a direct jump to the function.
- kaba0 6y ago
  It still has a cost over potential inlining (that allows for more optimizations as well). Of course if it is not a hotspot, it is meaningless.
- creamytaco 6y ago
  The call into the PLT is a penalty.
  - bonzini 6y ago
    Sure but it's not an indirect jump.

drran 6y ago

> Disk space, and arguably even RAM, have become very cheap by comparison CPU frequency and CPU cache are remaining small, so smaller binaries, which fit the cache, are running faster, and use less energy, and wastes less resources overall. > Given these, it seems worthwhile to re-evaluate the tradeoffs that come with dynamic linking Create your own distribution and show us benefits of static linking.