Suckless has a project to get a fully static compiled Linux environment. Unfortunately I don't know how far that have come
The thing that's missing is static link semantics that don't suck.
Dynamic linking
31–40 of 249 posts
Re: Dynamic linking
#32> Will security vulnerabilities in libraries that have been statically linked cause large or unmanagable updates?
This is maybe not an issue for open source packages which are managed by your distribution package manager, assuming they update all the dependent packages once some library gets updated (which would lead to a lot more updates all the time).
However, the maybe more critical issue is about other independently installed software, or maybe closed source software, where you will not automatically get an update once some library gets updated.
Re: Dynamic linking
#33I believe the original reasoning for Dynamic Linking wasn't performance gains, but security gains -- someone described the driving story to me as essentially a found vulnerability in a very common library required updating and re-compiling everything on every system , scarring sysadmins globally and permanently; the space saving and performance aspects came up as later "bonuses". I have little memory of the details o…
The original reasoning for shared libraries was reducing memory footprint -- back then memory was scarce. We're talking back in the days of SVR2, the mid-80s.
The original reasoning for ELF was that static link semantics suck. ELF's semantics are far superior (https://news.ycombinator.com/item?id=23656173).
Re: Dynamic linking
#34I think a more interesting analysis of "security vulnerability costs for static linking" would look not at just "how many bytes does the end user download" but "what are the overall costs to the distro to support a fully statically linked setup", looking at eg CPU costs of doing the rebuild or how much total-elapsed-time it would take to do a full rebuild of every affected package.
Not to mention that fixing a security vulnerability in, say, libm or libc becomes an amount of work equivalent to a distribution upgrade with all the associated risks.
Or am I the only one who has occasional problems when replacing all the binaries on my system?
Re: Dynamic linking
#35What are the counter arguments?
Re: Dynamic linking
#36>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.
> 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 prov…
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.
Re: Dynamic linking
#37Not convinced. First, this analysis was done on Arch Linux, a source-based distribution. Since you know at compile time what your environment is, I would expect the benefits to be smaller. And of course, this means you're willing to do a lot of recompiles. I'd like to see analysis done on more traditional (& common) binary distros. Second, the arguments seem a little cherry-picked. "Over half of your libraries are us…
What do you mean by "source-based distribution"?
Re: Dynamic linking
#38Not convinced. First, this analysis was done on Arch Linux, a source-based distribution. Since you know at compile time what your environment is, I would expect the benefits to be smaller. And of course, this means you're willing to do a lot of recompiles. I'd like to see analysis done on more traditional (& common) binary distros. Second, the arguments seem a little cherry-picked. "Over half of your libraries are us…
How is arch Linux a source based distro?
Re: Dynamic linking
#39Not convinced. First, this analysis was done on Arch Linux, a source-based distribution. Since you know at compile time what your environment is, I would expect the benefits to be smaller. And of course, this means you're willing to do a lot of recompiles. I'd like to see analysis done on more traditional (& common) binary distros. Second, the arguments seem a little cherry-picked. "Over half of your libraries are us…
> First, this analysis was done on Arch Linux, a source-based distribution. Since you know at compile time what your environment is, I would expect the benefits to be smaller. And of course, this means you're willing to do a lot of recompiles. I'd like to see analysis done on more traditional (& common) binary distros.
Arch Linux is not Gentoo. And AUR is only a secondary method of installing software. So I'm not sure what you mean.
Re: Dynamic linking
#40Say we have program X with dependency Y. X+Y is either dynamic or static. X can either have responsive maintainers or unresponsive maintainers. Y can either change to fix a bug or change to add a bug. (With Heartbleed, I remember our server was fine because we were on some ancient version of OpenSSL.)
Here are the scenarios:
- dynamic responsive remove bug: Positive/neutral. Team X would have done it anyway.
- dynamic unresponsive remove bug: Positive.
- dynamic responsive add bug: Negative. Team X will see the bug but only be able to passively warn users not to use Y version whatever.
- dynamic unresponsive add bug: Negative. Users will be impacted and have to get Y to fix the error.
- static responsive remove bug: Positive/neutral: Team X will incorporate the change from Y, although possibly somewhat slower (but safer).
- static unresponsive remove bug: Negative. Users will have to fork X or goad them into incorportating the fix.
- static responsive add bug: Positive. Users will not get the bad version of Y.
- static unresponsive add bug: Positive. Users will not get the bad version of Y.
Overall, dynamic is positive 1, neutral 1, negative 2, and static is positive 2, neutral 1, negative 1. Unless you can rule out Y adding bugs, static makes more sense. Dynamic is best if "unresponsive remove bug" is likely, but if X is unresponsive, maybe you should just leave X anyway.