5 ms·

>Do your installed programs share dynamic libraries? >Findings: not really >Over half of your libraries are used by fewer than 0.1% of your executables. Find

>Do your installed programs share dynamic libraries? >Findings: not really >Over half of your libraries are used by fewer than 0.1% of your executables. Findings: Yes, lots, but mostly the most common ones. Dynamically linking against something in the long tail is pretty pointless though.

rumanator 6y ago
> Dynamically linking against something in the long tail is pretty pointless though. I disagree. Dynamic linking, in the context of an OS which offers a curated list of packages in the form of an official package repository, means that a specialized third party is able to maintain a subcomponent of your system. This means you and me and countless others are able to reap the benefit of bugfixes and security fixes provided by a third-party without being actively engaged in the process. In the context of an OS where the DLL hell problem hasn't been addressed and all software packages are forced to ship all their libraries that are shared with no one at all, indeed its pretty pointless.
- eeereerews 6y ago
  It can also cut the other way though. Bugs can be introduced, compatibility can be broken, users can not find the library in their package manager, or they may find too new of a version. The danger of this is smaller for popular libraries, but goes up as you move to the long tail.
  - wahern 6y ago
    But this also highlights the benefit of community packaging. Debian packagers often backport security fixes into older versions of libraries that are no longer maintained upstream. That's a big part of their job--not just to bang out a build and walk away, but to keep an eye on things. This is why it's important to only use distro-packaged libraries as much as you can, even when statically linking. Getting off the treadmill of integrating interface-breaking upstream changes is one of the biggest practical reasons people prefer static linking and directly adding upstream source repositories into their build. It's at least as important, IME, as being able to use newer versions of libraries unavailable in an LTS distro. It can work well for large organizations, such as Google with their monolithic build, because they can and often do substitute the army of open source packers with their own army of people to curate and backport upstream changes. For everybody else it's quite risky, and if containerization provides any measure we're definitely worse off given the staleness problems with even the most popular containers.[1] [1] I wouldn't be surprised if an open source project emerged to provide regularly rebuilt and possibly patched upstream containers, recapitulating the organizational evolution of the traditional FOSS distribution ecosystem.
  - deathanatos 6y ago
    Bugs & compatibility issues are still a problem with the statically-linked version, unless you want to stay on the version of the library with the security vulnerability, you have to upgrade. That means, for either static or dynamic, dealing with bugs and compatibility issues — which I'd argue is another form of bug; if you're practicing semantic versioning (which you should be, as it prevents exactly this issue), this indicates either someone accidentally broke compatibility (a bug in the library), or someone was relying on something outside the established API (a bug in the consumer). For major versions (i.e., where compatibility is intentionally broken), good package managers are able to manage side-by-side installation of well-behaved packaged. (E.g., Portage's "slots" concept.) I'd also mention Nix's design here; my understanding is that it allows you to upgrade the dependency for just some consumers, so you really can then choose between insecure & bugs.
- bscphil 6y ago
  > Dynamic linking, in the context of an OS which offers a curated list of packages in the form of an official package repository, means that a specialized third party is able to maintain a subcomponent of your system. You nailed it, in my opinion. The biggest reason I favor dynamic linking is not because of any inherent advantage that I'm determined to believe in (in the face of purported evidence to the contrary, like this article), but because I fear the ecosystem changes that a major shift towards static linking would allow. If everything is a static blob, you have an environment that is much more friendly to every dev shipping their app as a binary download on their website, like Windows "freeware". Or worse still, they only support AppImage or some other "modern" method of distribution. This cuts maintainers out of the loop. I want to continue using a distribution with maintainers. I think they solve some important problems: when a maintainer is the gatekeeper, it means that a dev has to convince a third party that their app is (a) worth including, (b) not malware, (c) open source - at least heavily preferred since the dev will be building it themselves. And plus having a maintainer means someone besides the original dev is responsible for making sure you get security updates. Now of course you can distribute statically built apps that way, but there's a reason it's less common. There are so many Go apps out there where the only supported method to build them is using the Go toolchain and pulling in 150 Github repos. See also: this defense of the maintainer-based ecosystem, from an Arch Linux dev. http://kmkeen.com/maintainers-matter/ http://kmkeen.com/maintainers-matter/
  - AnIdiotOnTheNet 6y ago
    > If everything is a static blob, you have an environment that is much more friendly to every dev shipping their app as a binary download on their website, like Windows "freeware". Or worse still, they only support AppImage or some other "modern" method of distribution. This cuts maintainers out of the loop. I want to continue using a distribution with maintainers. So because that's what you want, let's make what other people want harder. Personally, I can't stand the repo/maintainer model. I want to cut maintainers out of the loop! I like having a direct relationship with the developer of the software I use. If they update their software with a feature or bug fix I need, I want the update right now, not when some unpaid third party gets around to integrating it with the f'ing distro. When I report bugs to the developer, I don't want to have to involve the third party. Shit like this is why I stick to Windows.

rumanator 6y ago

> Dynamically linking against something in the long tail is pretty pointless though. I disagree. Dynamic linking, in the context of an OS which offers a curated list of packages in the form of an official package repository, means that a specialized third party is able to maintain a subcomponent of your system. This means you and me and countless others are able to reap the benefit of bugfixes and security fixes provided by a third-party without being actively engaged in the process. In the context of an OS where the DLL hell problem hasn't been addressed and all software packages are forced to ship all their libraries that are shared with no one at all, indeed its pretty pointless.

eeereerews 6y ago
It can also cut the other way though. Bugs can be introduced, compatibility can be broken, users can not find the library in their package manager, or they may find too new of a version. The danger of this is smaller for popular libraries, but goes up as you move to the long tail.
- wahern 6y ago
  But this also highlights the benefit of community packaging. Debian packagers often backport security fixes into older versions of libraries that are no longer maintained upstream. That's a big part of their job--not just to bang out a build and walk away, but to keep an eye on things. This is why it's important to only use distro-packaged libraries as much as you can, even when statically linking. Getting off the treadmill of integrating interface-breaking upstream changes is one of the biggest practical reasons people prefer static linking and directly adding upstream source repositories into their build. It's at least as important, IME, as being able to use newer versions of libraries unavailable in an LTS distro. It can work well for large organizations, such as Google with their monolithic build, because they can and often do substitute the army of open source packers with their own army of people to curate and backport upstream changes. For everybody else it's quite risky, and if containerization provides any measure we're definitely worse off given the staleness problems with even the most popular containers.[1] [1] I wouldn't be surprised if an open source project emerged to provide regularly rebuilt and possibly patched upstream containers, recapitulating the organizational evolution of the traditional FOSS distribution ecosystem.
- deathanatos 6y ago
  Bugs & compatibility issues are still a problem with the statically-linked version, unless you want to stay on the version of the library with the security vulnerability, you have to upgrade. That means, for either static or dynamic, dealing with bugs and compatibility issues — which I'd argue is another form of bug; if you're practicing semantic versioning (which you should be, as it prevents exactly this issue), this indicates either someone accidentally broke compatibility (a bug in the library), or someone was relying on something outside the established API (a bug in the consumer). For major versions (i.e., where compatibility is intentionally broken), good package managers are able to manage side-by-side installation of well-behaved packaged. (E.g., Portage's "slots" concept.) I'd also mention Nix's design here; my understanding is that it allows you to upgrade the dependency for just some consumers, so you really can then choose between insecure & bugs.
bscphil 6y ago
> Dynamic linking, in the context of an OS which offers a curated list of packages in the form of an official package repository, means that a specialized third party is able to maintain a subcomponent of your system. You nailed it, in my opinion. The biggest reason I favor dynamic linking is not because of any inherent advantage that I'm determined to believe in (in the face of purported evidence to the contrary, like this article), but because I fear the ecosystem changes that a major shift towards static linking would allow. If everything is a static blob, you have an environment that is much more friendly to every dev shipping their app as a binary download on their website, like Windows "freeware". Or worse still, they only support AppImage or some other "modern" method of distribution. This cuts maintainers out of the loop. I want to continue using a distribution with maintainers. I think they solve some important problems: when a maintainer is the gatekeeper, it means that a dev has to convince a third party that their app is (a) worth including, (b) not malware, (c) open source - at least heavily preferred since the dev will be building it themselves. And plus having a maintainer means someone besides the original dev is responsible for making sure you get security updates. Now of course you can distribute statically built apps that way, but there's a reason it's less common. There are so many Go apps out there where the only supported method to build them is using the Go toolchain and pulling in 150 Github repos. See also: this defense of the maintainer-based ecosystem, from an Arch Linux dev. http://kmkeen.com/maintainers-matter/ http://kmkeen.com/maintainers-matter/
- AnIdiotOnTheNet 6y ago
  > If everything is a static blob, you have an environment that is much more friendly to every dev shipping their app as a binary download on their website, like Windows "freeware". Or worse still, they only support AppImage or some other "modern" method of distribution. This cuts maintainers out of the loop. I want to continue using a distribution with maintainers. So because that's what you want, let's make what other people want harder. Personally, I can't stand the repo/maintainer model. I want to cut maintainers out of the loop! I like having a direct relationship with the developer of the software I use. If they update their software with a feature or bug fix I need, I want the update right now, not when some unpaid third party gets around to integrating it with the f'ing distro. When I report bugs to the developer, I don't want to have to involve the third party. Shit like this is why I stick to Windows.