5 ms·

Can somebody explain to me the obsession with static linking? Do these people not realize that performance gains from shared memory between disparate applicatio

Can somebody explain to me the obsession with static linking? Do these people not realize that performance gains from shared memory between disparate applications hinges on dynamic linking mmap'd libraries and COWing shared memory sections to private on demand, reduces duplicate code, standardizes operations, and simplifies debugging? Has the world gone mad?!

insulanus 10y ago
That is a nice feature, but if code is only 1% of your process image, it doesn't matter.
stonogo 10y ago
Think of it like docker without the network overhead, using the os kernel as kubernetes. Think of it like webworkers with the kernel as the js runtime. Ram is cheap. Complexity is expensive.
- peterwwillis 10y ago
  Multiple different versions of the same software running in the same environment increases complexity. Ram is cheap, loading code into ram wastes cycles and following new or different code paths trashes cpu cache and recent code paths.
  - zzzcpan 10y ago
    So far I see only the opposite. Inability to be flexible about multiple versions adds a lot of unnecessary complexity.
Sir_Cmpwn 10y ago
Most of the applications you will have running at any given moment probably have few libraries in common. A typical linker will only include in the final executable any functions you require from your dependency as well, which can dramatically reduce the footprint of a piece of software (when considered in combination with its dependencies). Statically linked binaries also load faster and don't break when you have a botched update. My distro does support dynamic linking, but prefers static. In practice the RAM footprint and disk footprint is much, much smaller than any dynamically linked distro I've tried. Avoiding GNU also helps a lot to reduce bloat. Static linking also makes agunix more portable. Stuff like this is possible: https://sr.ht/5HTs.png https://sr.ht/5HTs.png
- peterwwillis 10y ago
  I have 878 unique libraries shared between currently running processes on my Linux laptop at this moment, with the amount of processes sharing a library ranging from 2 processes to 820. Most may have few in common, but there are a lot of them, and the mean is 62, mode is 4. As far as the botched update argument: When does anybody botch an update of a shared library? When they're forcing something to install, or they don't know what they're doing. On the other hand, mis-matches in applications using different versions of the same code causes silent, unexpected, difficult to debug errors. I'd also be interested in seeing actual "RAM and disk footprint" numbers as a comparison for the same applications and libraries, because that doesn't really make sense. Even if applications only copy a couple small functions each, they add up, whereas the shared library only has one copy. I can't speak to the speed differences (again, I would like to see numbers) but certainly different versions could lead to competing cache and code path hits. And a static application has nothing to do with portability. Just because I can run a Windows 95 application in Windows 10 doesn't mean it's going to work right, and just because FreeBSD has a Linux binary compatibility layer doesn't mean the app is going to work. Portability requires making it portable first. You can copy shared libraries with a dynamic executable and run it as reliably as a static app.
  - Sir_Cmpwn 10y ago
    >I have 878 unique shared libraries shared between currently running processes on my Linux laptop at this moment, with the amount of processes sharing a library ranging from 2 processes to 820. Most may have few in common, but there are a lot of them, and the mean is 62, mode is 4. Good god, this tells half the story. An agunix install booted to a shell will typically only have 3 processes running: runit, a getty, and your shell. I don't think I've ever had more than 50 processes running on my agunix system at any given moment. >As far as the botched update argument: When does anybody botch an update of a shared library? When they're forcing something to install, or they don't know what they're doing. For any number of reasons. This has happened to me dozens of times in the past year. You also run into issues with any software you compiled yourself that aren't managed by the package manager (or at least not supported by your distro). You know what's better? An executable that works on any Linux system and will continue to work for the next 20 years without any changes. How about running two executables that need different versions of a library? >On the other hand, mis-matches in applications using different versions of the same code causes silent, unexpected, difficult to debug errors. I haven't run into this yet. Have you? >I'd also be interested in seeing actual "RAM and disk footprint" numbers as a comparison for the same applications and libraries, because that doesn't really make sense. Even if applications only copy a couple small functions each, they add up, whereas the shared library only has one copy. My laptop is currently running runit, 8 gettys, sshd, wpa_supplicant, crond, udevd, and dhcpcd. It's using 60 MiB of RAM. So far as disk footprint is concerned, see package sizes at https://repo.agunix.org/ https://repo.agunix.org/. Base system is ~350 MiB on disk and there's still room for improvement. From the agunix home page: >Our first concern is to build a lightweight POSIX environment - a familiar design for users familiar with other Linux distributions is not our goal. It's better to think of this as a new operating system entirely than as a new Linux distro.
zzzcpan 10y ago
Statically linked binaries deploy easily, deploy faster, start faster, don't depend on libraries or even on a filesystem hierarchy standard, because they don't require hardcoded elf interpreter and so on.
- kasabali 10y ago
  these are very desirable properties for binaries that are meant to be deployed. makes no sense whatsoever for distribution binaries though.
placeybordeaux 10y ago
Up to a certain point (~64GB) I'd rather buy more ram than deal with any sort of problems of mismatched dependencies.
sfifs 10y ago
dependency management is the main reason I love statically linked binaries. Without static linking, getting the right ecosystem of libraries installed - especially when libraries depend on other libraries is a nightmare for any moderately complex software. With static linking, scp over a binary and you're done.

insulanus 10y ago

That is a nice feature, but if code is only 1% of your process image, it doesn't matter.

stonogo 10y ago

Think of it like docker without the network overhead, using the os kernel as kubernetes. Think of it like webworkers with the kernel as the js runtime. Ram is cheap. Complexity is expensive.

peterwwillis 10y ago
Multiple different versions of the same software running in the same environment increases complexity. Ram is cheap, loading code into ram wastes cycles and following new or different code paths trashes cpu cache and recent code paths.
- zzzcpan 10y ago
  So far I see only the opposite. Inability to be flexible about multiple versions adds a lot of unnecessary complexity.

Sir_Cmpwn 10y ago

Most of the applications you will have running at any given moment probably have few libraries in common. A typical linker will only include in the final executable any functions you require from your dependency as well, which can dramatically reduce the footprint of a piece of software (when considered in combination with its dependencies). Statically linked binaries also load faster and don't break when you have a botched update. My distro does support dynamic linking, but prefers static. In practice the RAM footprint and disk footprint is much, much smaller than any dynamically linked distro I've tried. Avoiding GNU also helps a lot to reduce bloat. Static linking also makes agunix more portable. Stuff like this is possible: https://sr.ht/5HTs.png https://sr.ht/5HTs.png

peterwwillis 10y ago
I have 878 unique libraries shared between currently running processes on my Linux laptop at this moment, with the amount of processes sharing a library ranging from 2 processes to 820. Most may have few in common, but there are a lot of them, and the mean is 62, mode is 4. As far as the botched update argument: When does anybody botch an update of a shared library? When they're forcing something to install, or they don't know what they're doing. On the other hand, mis-matches in applications using different versions of the same code causes silent, unexpected, difficult to debug errors. I'd also be interested in seeing actual "RAM and disk footprint" numbers as a comparison for the same applications and libraries, because that doesn't really make sense. Even if applications only copy a couple small functions each, they add up, whereas the shared library only has one copy. I can't speak to the speed differences (again, I would like to see numbers) but certainly different versions could lead to competing cache and code path hits. And a static application has nothing to do with portability. Just because I can run a Windows 95 application in Windows 10 doesn't mean it's going to work right, and just because FreeBSD has a Linux binary compatibility layer doesn't mean the app is going to work. Portability requires making it portable first. You can copy shared libraries with a dynamic executable and run it as reliably as a static app.
- Sir_Cmpwn 10y ago
  >I have 878 unique shared libraries shared between currently running processes on my Linux laptop at this moment, with the amount of processes sharing a library ranging from 2 processes to 820. Most may have few in common, but there are a lot of them, and the mean is 62, mode is 4. Good god, this tells half the story. An agunix install booted to a shell will typically only have 3 processes running: runit, a getty, and your shell. I don't think I've ever had more than 50 processes running on my agunix system at any given moment. >As far as the botched update argument: When does anybody botch an update of a shared library? When they're forcing something to install, or they don't know what they're doing. For any number of reasons. This has happened to me dozens of times in the past year. You also run into issues with any software you compiled yourself that aren't managed by the package manager (or at least not supported by your distro). You know what's better? An executable that works on any Linux system and will continue to work for the next 20 years without any changes. How about running two executables that need different versions of a library? >On the other hand, mis-matches in applications using different versions of the same code causes silent, unexpected, difficult to debug errors. I haven't run into this yet. Have you? >I'd also be interested in seeing actual "RAM and disk footprint" numbers as a comparison for the same applications and libraries, because that doesn't really make sense. Even if applications only copy a couple small functions each, they add up, whereas the shared library only has one copy. My laptop is currently running runit, 8 gettys, sshd, wpa_supplicant, crond, udevd, and dhcpcd. It's using 60 MiB of RAM. So far as disk footprint is concerned, see package sizes at https://repo.agunix.org/ https://repo.agunix.org/. Base system is ~350 MiB on disk and there's still room for improvement. From the agunix home page: >Our first concern is to build a lightweight POSIX environment - a familiar design for users familiar with other Linux distributions is not our goal. It's better to think of this as a new operating system entirely than as a new Linux distro.

zzzcpan 10y ago

Statically linked binaries deploy easily, deploy faster, start faster, don't depend on libraries or even on a filesystem hierarchy standard, because they don't require hardcoded elf interpreter and so on.

kasabali 10y ago
these are very desirable properties for binaries that are meant to be deployed. makes no sense whatsoever for distribution binaries though.

placeybordeaux 10y ago

Up to a certain point (~64GB) I'd rather buy more ram than deal with any sort of problems of mismatched dependencies.

sfifs 10y ago

dependency management is the main reason I love statically linked binaries. Without static linking, getting the right ecosystem of libraries installed - especially when libraries depend on other libraries is a nightmare for any moderately complex software. With static linking, scp over a binary and you're done.