Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic linking

drewdevault.com

Post reply on HN
Print view View original

91–100 of 249 posts

Re: Dynamic linking

#91

Post by saagarjha »

IshKebab wrote: post #85
petters wrote: post #52

Earlier quoted context omitted.

Sure, but I think the most important reason people have in mind when they argue for dynamic linking is that they will receive upstream bugfixes. I don't think your eight cases are equally important. You are of course right, though, and writing it down like this can be useful.

Why would you not receive upstream bug fixes with statically linked programs? Assuming you are using an Apt-style package manager then the statically linked program would be rebuilt and updated too. If you are not using an apt-style package manager then the program must include all of its dependencies (except ones that are guaranteed to be present on the platform, which is none on Linux and a few on Mac/Windows), and…

The first hurdle is that you require source code to do any of this. Then you need to actually rebuild everything.

Re: Dynamic linking

#92

Post by dan-robertson »

earthboundkid wrote: post #40

Say 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. - dynami…

If you’re a Linux distribution and you have the source code to the software you distribute then the responsiveness of the maintainers doesn’t matter so much: any change to a library which is compatible with the previous version (in the sense that you could dynamically link to the new version instead of the old version) is going to be compatible under static linking too.

Re: Dynamic linking

#93

Post by cryptonector »

kick wrote: post #66
dwheeler wrote: post #28

Not 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…

This comment hits all of the boxes for everything that is wrong with Hacker News. "First, false statement. Since you know false assumption, I would false conclusion. And of course, this means false conclusion. I'd like to see analysis done on what you did them on." "Second, the arguments seem a little cherry-picked. "Quote from article about W and Z" is cute. But modern systems have a lot of Z, and Obviously You Didn…

Actually, this is a very serious topic, and TFA is wrong in a number of ways. HN commenters being able to say so is everything that's right with HN. My own commentary on TFA is all over the comments on this HN post. I put more effort and detail into my comments on this post than GP, but GP is not wrong.

Commenting that a comment is exemplary of all that's wrong with HN is... popular, I'll grant you that, but it grates, and it's not really right. It's a "shut up" argument. Just downvote what you don't like, upvote what you do like, and reply with detailed commentary where you have something important to say. No need to disparage commenters.

Re: Dynamic linking

#94

Post by cryptonector »

pengaru wrote: post #42

Back in the 90s we'd statically link the most frequently executed programs on busy servers for a significant performance boost. Dynamic linking is not a performance feature, it's a decoupling feature.

Dynamic linking boosted performance for Solaris back around 2004.

Re: Dynamic linking

#95

Post by dan-robertson »

I’m curious about the supposed memory advantages of dynamic linking: on average how many different executables share each page of memory? What about when memory is in high demand? How high does that average become? What is the probability that a page of a shared library is already in memory (cache or otherwise) when it needs to be loaded, and in particular the probability that it is there because another program loaded it).

My guess is that apart from eg libc, the average is pretty low (ie 1 for the pages that aren’t free).

Re: Dynamic linking

#96

Post by yjftsjthsd-h »

glouwbug wrote: post #22
jnwatson wrote: post #17

Earlier quoted context omitted.

Go executables are statically linked. It makes deployment a breeze. I think you overestimate how much saving you get from dynamically linking libc. Each executable uses only a small portion of libc, so the average savings is going to be in the handful of kilobytes per executable.

True, but a couple github imports and 10 lines of code generates a 100mb binary. But, to be fair, I guess we're okay with shipping huge binaries now a days because we're literally shipping whole environments with docker anyway.

To be fair, you're not really supposed to be shipping a full system in a docker image if you can help it; you're supposed to layer your application over the smallest base that will support it (whether that's scratch, distroless, alpine, or a minimal debian base). Of course, I'll be the first to agree that "supposed to" and reality have little in common; if I had a dollar for every time I've seen a final image that still included the whole compiler chain...

Re: Dynamic linking

#97

Post by cryptonector »

saagarjha wrote: post #89

As always, static and dynamic linking both have their advantages and drawbacks. The usual arguments for dynamic linking around brought up in the article, and as others have mentioned here, the analysis is a bit lacking so the conclusions aren't generally true. Static linking has its own, fairly straightforwards benefits as well. It's no surprise that those who push one or the other usually do so because of their spec…

Specifically for C, static linking is a trap due to its poor semantics. Don't do it. Or fix the C link-editors, then static linking C will be fine.

Re: Dynamic linking

#98

Post by sigjuice »

cryptonector wrote: post #97
saagarjha wrote: post #89

As always, static and dynamic linking both have their advantages and drawbacks. The usual arguments for dynamic linking around brought up in the article, and as others have mentioned here, the analysis is a bit lacking so the conclusions aren't generally true. Static linking has its own, fairly straightforwards benefits as well. It's no surprise that those who push one or the other usually do so because of their spec…

Specifically for C, static linking is a trap due to its poor semantics. Don't do it. Or fix the C link-editors, then static linking C will be fine.

What would be examples of poor static linking semantics? Thanks!

Re: Dynamic linking

#99

Post by furbyhater »

earthboundkid wrote: post #40

Say 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. - dynami…

I don't agree with this:

- static responsive add bug: Positive. Users will not get the bad version of Y.

On the contrary, it's negative because the maintainers of X will update Y and introduce the bug to their users (I'm assuming they don't thoroughly audit the source of Y each time they do a version upgrade).

Also, "unresponsive remove bug" should be given more weight since it's more likely to happen IMO.

Post reply on HN