6 ms·

Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback

by hnarn 4y ago

Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback of these “huge” binaries? Wasn’t the reason to separate binaries and libraries in the first place to conserve disk space? They are then clearly versioned to signal that you can’t expect just any version of the library to work with the program you wrote. The trade-off in using more disk to contain “an application” to “a binary” seems fine to me, if you’re not sacrificing anything else. The only drawback I can think of is that it makes very minor patches, like security fixes, to the library impossible, which is a nice thing to have I guess, but on the other hand you’re now giving the library maintainer the capability to crash your application, and since that would presumably go through some kind of review and rebuild of the application in the first place to avoid crashes against the new library code, why does it matter if the lib is a part of the actual binary or not? Is it really down to nothing but bandwidth and disk usage, or am I missing something here? Because if it is, and “blob binaries” becomes the norm, I’m sure you could still figure out partial patches somehow to conserve bandwidth and IO, while still keeping the binary essentially a built monolith. Maybe one argument is that abandoned programs can still be “patched” in a way because a library it depends on fixes an issue that library was responsible for, but doesn’t that seem pretty risky to begin with to run software that is no longer being patched? Indeed what constitutes “software” just seems to be multiple pieces in one case, and one piece in the other, no? The biggest case against “vendoring”, which in my mind is similar to “huge” binaries, that I can think of at least is that it gives developers a false sense of security to not have to think about keeping libraries up to date: but aren’t they already equally able to be sloppy about this when the libs are separate?

poulpy123 4y ago
I just checked and I have 5600 binaries in my /usr/bin. They take an average of 100kb. If statically compiling them means an average of 50M that means 281gb.
- hnarn 4y ago
  You're arguing against a strawman saying that no binaries should ever be anything but statically compiled, including system binaries bundled with the operating system. I certainly did not say that.
sgjohnson 4y ago
> what is the actual drawback of these “huge” binaries? The problem isn’t size. The problem is that with static linking it gets significantly more difficult to patch security vulnerabilities, because with dynamic linking, the vuln is gone once the underlying library is updated, however this wouldn’t happen with static linking.
- nicoburns 4y ago
  You need to be regularly updating the higher level packages anyway though, as they might contain vulnerabilities that are not due to underlying libraries. At which point, we might as well update them for library issues too.
  - Scramblejams 4y ago
    But then you're relying on every single higher level package owner to pull in patches for all their dependencies and update their binaries in a timely fashion. That works for, say, Debian packages (my distro of choice), but as soon as you move outside of that circle it'll make it harder to guarantee quality. In contrast, on (for example) Debian, I know that the Debian Security Team is looking after the libraries and that gives me a lot of peace of mind. Instead, I'd be wondering if every single third-party apt repository package owner is doing a professional job. At least if they're shipping binaries that are dynamically linked to Debian packages, I can have confidence that those library issues are being handled. (XML parser update, anybody?)
  - wccrawford 4y ago
    Many games rarely update, though. They put out the original version, and then maybe a few patches to fix game-breaking bugs, and then that's how they exist from then on. If you're expecting them to update to address vulnerabilities, you're going to be very disappointed. That said, if the library changes the API or functionality at all, dynamic linking is going to break the game, and that's not good either. So gamedevs are going to opt for static linking and call it a day rather than deal with support requests.
    - 4y ago
pxc 4y ago
> Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback of these “huge” binaries? The functional package management/build system design instantiated by Guix and Nix shows that you can have the best of both worlds when it comes to static and dynamic linking, even without any form of containerization. Guix in particular has a feature called 'grafts' which implements a kind of hot patching for libraries in programs which are nominally dynamically linked but which in fact never search for libraries other than the exact versions they were built with. So there's no need to choose between the portability of static linking or the efficiency and flexibility of dynamic linking. You can get all of those things together, today, for many thousands of packages. If you're not familiar with the basic outline of these build systems, the idea is basically this: - every package gets installed to a unique, quasi-content-addressed location - each such location has its own FHS-like tree which gets treated as a prefix for that package at build time - every package gets manually pointed to each of it's dependencies' unique, full paths at build time this ensures that each package always tries to load the libraries it was built with, and allows multiple versions of libraries to safely exist side-by-side, even when everything is dynamically linked. To ship a package, you then just ship the whole dependency closure, which gives you the portability that motivates people to distribute static binaries. Here's some info on Guix grafts, for an idea of how security updates can still be managed in such a system. The official docs for grafts: https://guix.gnu.org/manual/en/html_node/Security-Updates.html https://guix.gnu.org/manual/en/html_node/Security-Updates.ht... Original blog post/announcement for the feature: https://guix.gnu.org/blog/2016/timely-delivery-of-security-updates/ https://guix.gnu.org/blog/2016/timely-delivery-of-security-u... Detailed writeup of further implementation details: https://guix.gnu.org/en/blog/2020/grafts-continued/ https://guix.gnu.org/en/blog/2020/grafts-continued/
jnwatson 4y ago
Shared libraries can reduce load time as they might already be in page cache. There’s also potential for a small impact in reduced instruction cache misses. On the other side, link time optimization on static libraries allows deletion of unused functions and more aggressive inlining, so you might get that performance back and more.
- dralley 4y ago
  People say this but every test case I've seen has proven otherwise. Static binaries load much faster. Maybe it depends on the size of the libraries involved an the quality of the OS' dynamic linking machinery (supposedly OSX has better runtime dynamic linking startup times than linux), but at the very least it is conditional, not a pure win.
- CamperBob2 4y ago
  Not only that, but executable images are demand-paged anyway. You can link 1 GB of static library code if you like; you won't pay the penalty unless and until those functions are actually called. The whole debate is just stupid. If it inconveniences even one fewer user, then static linking is the way to go, because of the sheer number of drawbacks that shared libraries bring. Nobody cares how big the executable is. If you do, well... the best time to stop caring was 10 years ago, and the second best time is now.
  - bombolo 4y ago
    But the called functions need to be loaded in memory for every process using them, instead of once. Also there is value in being able to fix a library without having to recompile everything.
    - deleted 4y ago
      [deleted]
    - craftkiller 4y ago
      Everything is getting recompiled all the time anyway. At least with FreeBSD, any time a dependency is updated, all the packages that depend on that package get rebuilt. There's no concept of "this was a small update and its dynamically linked", its just "the version string changed, so rebuild everything that lists it as a dependency". This is particularly "fun" for web browsers because they have a lot of dependencies, ensuring they're rebuilt often, and they take a long time to build.
kabdib 4y ago
If we're talking about binaries for game titles, meh. Load time for the executable is utterly insignificant compared to the load time of a title's assets. Heck, shared libraries probably slow things down. Typical games I have experience with were in the 5-20Mb range for executables, with tens of GB for assets. Most titles I looked at the performance of were terrible at scheduling I/O, often leaving 80% of their available disk bandwidth unused.

by hnarn 4y ago

poulpy123 4y ago

I just checked and I have 5600 binaries in my /usr/bin. They take an average of 100kb. If statically compiling them means an average of 50M that means 281gb.

hnarn 4y ago
You're arguing against a strawman saying that no binaries should ever be anything but statically compiled, including system binaries bundled with the operating system. I certainly did not say that.

sgjohnson 4y ago

> what is the actual drawback of these “huge” binaries? The problem isn’t size. The problem is that with static linking it gets significantly more difficult to patch security vulnerabilities, because with dynamic linking, the vuln is gone once the underlying library is updated, however this wouldn’t happen with static linking.

nicoburns 4y ago
You need to be regularly updating the higher level packages anyway though, as they might contain vulnerabilities that are not due to underlying libraries. At which point, we might as well update them for library issues too.
- Scramblejams 4y ago
  But then you're relying on every single higher level package owner to pull in patches for all their dependencies and update their binaries in a timely fashion. That works for, say, Debian packages (my distro of choice), but as soon as you move outside of that circle it'll make it harder to guarantee quality. In contrast, on (for example) Debian, I know that the Debian Security Team is looking after the libraries and that gives me a lot of peace of mind. Instead, I'd be wondering if every single third-party apt repository package owner is doing a professional job. At least if they're shipping binaries that are dynamically linked to Debian packages, I can have confidence that those library issues are being handled. (XML parser update, anybody?)
- wccrawford 4y ago
  Many games rarely update, though. They put out the original version, and then maybe a few patches to fix game-breaking bugs, and then that's how they exist from then on. If you're expecting them to update to address vulnerabilities, you're going to be very disappointed. That said, if the library changes the API or functionality at all, dynamic linking is going to break the game, and that's not good either. So gamedevs are going to opt for static linking and call it a day rather than deal with support requests.
  - 4y ago

pxc 4y ago

> Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback of these “huge” binaries? The functional package management/build system design instantiated by Guix and Nix shows that you can have the best of both worlds when it comes to static and dynamic linking, even without any form of containerization. Guix in particular has a feature called 'grafts' which implements a kind of hot patching for libraries in programs which are nominally dynamically linked but which in fact never search for libraries other than the exact versions they were built with. So there's no need to choose between the portability of static linking or the efficiency and flexibility of dynamic linking. You can get all of those things together, today, for many thousands of packages. If you're not familiar with the basic outline of these build systems, the idea is basically this: - every package gets installed to a unique, quasi-content-addressed location - each such location has its own FHS-like tree which gets treated as a prefix for that package at build time - every package gets manually pointed to each of it's dependencies' unique, full paths at build time this ensures that each package always tries to load the libraries it was built with, and allows multiple versions of libraries to safely exist side-by-side, even when everything is dynamically linked. To ship a package, you then just ship the whole dependency closure, which gives you the portability that motivates people to distribute static binaries. Here's some info on Guix grafts, for an idea of how security updates can still be managed in such a system. The official docs for grafts: https://guix.gnu.org/manual/en/html_node/Security-Updates.html https://guix.gnu.org/manual/en/html_node/Security-Updates.ht... Original blog post/announcement for the feature: https://guix.gnu.org/blog/2016/timely-delivery-of-security-updates/ https://guix.gnu.org/blog/2016/timely-delivery-of-security-u... Detailed writeup of further implementation details: https://guix.gnu.org/en/blog/2020/grafts-continued/ https://guix.gnu.org/en/blog/2020/grafts-continued/

jnwatson 4y ago

Shared libraries can reduce load time as they might already be in page cache. There’s also potential for a small impact in reduced instruction cache misses. On the other side, link time optimization on static libraries allows deletion of unused functions and more aggressive inlining, so you might get that performance back and more.

dralley 4y ago
People say this but every test case I've seen has proven otherwise. Static binaries load much faster. Maybe it depends on the size of the libraries involved an the quality of the OS' dynamic linking machinery (supposedly OSX has better runtime dynamic linking startup times than linux), but at the very least it is conditional, not a pure win.
CamperBob2 4y ago
Not only that, but executable images are demand-paged anyway. You can link 1 GB of static library code if you like; you won't pay the penalty unless and until those functions are actually called. The whole debate is just stupid. If it inconveniences even one fewer user, then static linking is the way to go, because of the sheer number of drawbacks that shared libraries bring. Nobody cares how big the executable is. If you do, well... the best time to stop caring was 10 years ago, and the second best time is now.
- bombolo 4y ago
  But the called functions need to be loaded in memory for every process using them, instead of once. Also there is value in being able to fix a library without having to recompile everything.
  - deleted 4y ago
    [deleted]
  - craftkiller 4y ago
    Everything is getting recompiled all the time anyway. At least with FreeBSD, any time a dependency is updated, all the packages that depend on that package get rebuilt. There's no concept of "this was a small update and its dynamically linked", its just "the version string changed, so rebuild everything that lists it as a dependency". This is particularly "fun" for web browsers because they have a lot of dependencies, ensuring they're rebuilt often, and they take a long time to build.

kabdib 4y ago

If we're talking about binaries for game titles, meh. Load time for the executable is utterly insignificant compared to the load time of a title's assets. Heck, shared libraries probably slow things down. Typical games I have experience with were in the 5-20Mb range for executables, with tens of GB for assets. Most titles I looked at the performance of were terrible at scheduling I/O, often leaving 80% of their available disk bandwidth unused.