3 ms·

> I now have something to point people to when they ask "what is wrong with pinning?" or "what is wrong with static linking?" or "why can't you just use pip?" M

by saurik 6y ago

> I now have something to point people to when they ask "what is wrong with pinning?" or "what is wrong with static linking?" or "why can't you just use pip?" Michał has had to deal with some pretty crazy stuff the last couple of months ... scratch that, years. Literally the only argument in this article against static linking is "it will take an extra couple hours for the distribution to recompile all affected packages and then require the user to download a larger update, meaning time to fix for a security issue will be negligibly longer"... since you seem to believe this article represents the strongest statement of your argument, this has actually moved me further away from where you want me to be ;P. (FWIW, the best argument I could make for dynamic linking involves memory efficiency for shared pages, the disk cache, and maybe the i-cache, not security.)

jcranmer 6y ago
> maybe the i-cache This I doubt. On a statically-linked application, all calls to functions are going through a regular function call instruction. When you dynamically link, every call to a function that might cross library boundaries (which on ELF systems defaults to every call that's not to a static function) instead calls into the PLT, which will itself dispatch through to the underlying function call.
- Lx1oG-AWb6h_ZG0 6y ago
  We had an article on the front page yesterday about Swift’s ABI and how much Apple has invested in dynamic linking: https://news.ycombinator.com/item?id=26205969 https://news.ycombinator.com/item?id=26205969 > It's worth noting that the Swift devs disagree with the Rust and C++ codegen orthodoxy in one major way: they care much more about code sizes (as in the amount of executable code produced). More specifically, they care a lot more about making efficient usage of the cpu's instruction cache, because they believe it's better for system-wide power usage. Apple championing this concern makes a lot of sense, given their suite of battery-powered devices.

by saurik 6y ago

jcranmer 6y ago

> maybe the i-cache This I doubt. On a statically-linked application, all calls to functions are going through a regular function call instruction. When you dynamically link, every call to a function that might cross library boundaries (which on ELF systems defaults to every call that's not to a static function) instead calls into the PLT, which will itself dispatch through to the underlying function call.

Lx1oG-AWb6h_ZG0 6y ago
We had an article on the front page yesterday about Swift’s ABI and how much Apple has invested in dynamic linking: https://news.ycombinator.com/item?id=26205969 https://news.ycombinator.com/item?id=26205969 > It's worth noting that the Swift devs disagree with the Rust and C++ codegen orthodoxy in one major way: they care much more about code sizes (as in the amount of executable code produced). More specifically, they care a lot more about making efficient usage of the cpu's instruction cache, because they believe it's better for system-wide power usage. Apple championing this concern makes a lot of sense, given their suite of battery-powered devices.