4 ms·

> "oh wow, better static link all the things!". Is that wrong? Depends. Sadly, current trend is to keep everything static in big binary or bundle own set of de

by dig1 7y ago

> "oh wow, better static link all the things!". Is that wrong? Depends. Sadly, current trend is to keep everything static in big binary or bundle own set of dependencies. Let's assume your program is using libpng. Now, every program is keeping own libpng in RAM. That is not even the worst case; imagine particular libpng has security issue. The only way to update all those static programs is to recompile everything or download everything; which is trend, again. I image we will have shared library approach "rediscovered" and commercialized with some cool buzzword.

nicoburns 7y ago
How much RAM does libpng use? It surely can't more than a couple of megabytes at most (much less I'd imagine, given typical binary sizes). This is rapidly becoming a non-issue. Regarding security issues. I imagine that we will gradually rewrite everything in memory-safe languages such as Rust. It'll take a while - there's a lot of value in the code that's already been written. But once a library for a given task has been rewritten into a safe language, it's going to be hard to justify using the equivalent C library. Of course this won't completely eliminate security issues. But I'd guess that along with a bit of fuzzing, it could easily reduce the frequency to <10% of what we have today. That, along with the fact that modern languages have package managers, and updating a library to the latest patch version is a one-line change, will make keeping on top of security issues well within the reach of the average app developer. Shared libraries were a necessary tool in a world with limited computing resources, but I suspect the current trend will continue until they're used only in niche circumstances (plugins? libc?)
- zzzcpan 7y ago
  > How much RAM does libpng use? The assumption here is likely that read-only mapped pages of libpng could be shared across different running programs that link with it. But it ignores all the extra read-write pages as a consequence of dynamic linking and that there is basically just libc that is shared across different running programs. So it's mostly wrong, you can probably even reduce memory usage by switching to static linking.
  - cycloptic 7y ago
    Libpng is not a good example. Often in real-world applications there are dozens of libraries that are dynamically linked, and they can get quite large. The other argument is that having them dynamically linked increases cache coherency. For example if all applications share the same GUI library, the core rendering loop of that library will be likely to get kept in the cache. However, I have not tested this theory and it seems like the library would have to be designed for it to get any real benefit.
- dig1 7y ago
  Libpng wasn't good example regarding size indeed, my main focus was security and how much of things it can affect. For heavy libraries, good example is Qt and KDE. KDE would preload all necessary libraries so KDE and Qt applications could start faster, and there was significant differences when Qt application was started under KDE comparing other desktop environment. Don't forget that under X11, everything is linked with X11 libraries and many applications with either Qt or Gtk, which brings own set of additional dependencies (pango, cairo, etc). > Regarding security issues. I imagine that we will gradually rewrite everything in memory-safe languages such as Rust I'm not sure how this will save us from programming errors. You just move from one surface (memory) to another (VM, compiler, package manager) with added complexity.

by dig1 7y ago

nicoburns 7y ago

How much RAM does libpng use? It surely can't more than a couple of megabytes at most (much less I'd imagine, given typical binary sizes). This is rapidly becoming a non-issue. Regarding security issues. I imagine that we will gradually rewrite everything in memory-safe languages such as Rust. It'll take a while - there's a lot of value in the code that's already been written. But once a library for a given task has been rewritten into a safe language, it's going to be hard to justify using the equivalent C library. Of course this won't completely eliminate security issues. But I'd guess that along with a bit of fuzzing, it could easily reduce the frequency to <10% of what we have today. That, along with the fact that modern languages have package managers, and updating a library to the latest patch version is a one-line change, will make keeping on top of security issues well within the reach of the average app developer. Shared libraries were a necessary tool in a world with limited computing resources, but I suspect the current trend will continue until they're used only in niche circumstances (plugins? libc?)

zzzcpan 7y ago
> How much RAM does libpng use? The assumption here is likely that read-only mapped pages of libpng could be shared across different running programs that link with it. But it ignores all the extra read-write pages as a consequence of dynamic linking and that there is basically just libc that is shared across different running programs. So it's mostly wrong, you can probably even reduce memory usage by switching to static linking.
- cycloptic 7y ago
  Libpng is not a good example. Often in real-world applications there are dozens of libraries that are dynamically linked, and they can get quite large. The other argument is that having them dynamically linked increases cache coherency. For example if all applications share the same GUI library, the core rendering loop of that library will be likely to get kept in the cache. However, I have not tested this theory and it seems like the library would have to be designed for it to get any real benefit.
dig1 7y ago
Libpng wasn't good example regarding size indeed, my main focus was security and how much of things it can affect. For heavy libraries, good example is Qt and KDE. KDE would preload all necessary libraries so KDE and Qt applications could start faster, and there was significant differences when Qt application was started under KDE comparing other desktop environment. Don't forget that under X11, everything is linked with X11 libraries and many applications with either Qt or Gtk, which brings own set of additional dependencies (pango, cairo, etc). > Regarding security issues. I imagine that we will gradually rewrite everything in memory-safe languages such as Rust I'm not sure how this will save us from programming errors. You just move from one surface (memory) to another (VM, compiler, package manager) with added complexity.