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

211–220 of 249 posts

Re: Dynamic linking

#211

Post by microtonal »

adev_ wrote: post #205
microtonal wrote: post #194

Earlier quoted context omitted.

I was talking about finding vulnerabilities on end-user systems and servers. I don't know about others, but I don't generally keep compiler tool chains [...] You don't have to, most NixOS/Guix systems use binary caches. So, their build clusters do the work for the packages included the nixpkgs/guix package sets. If your organization builds their own packages in top of that, you can use a CI plus your private cache (o…

> You don't have to, most NixOS/Guix systems use binary caches. Yes, Nix/Guix and Spack are up to my knowledge the only systems that got that right. The centralised recipe repository (and their functional nature) make scratch recompilation reliable and easy. Now good luck to get that with most lock-file based package managers like npm, cargo or pip with ~1000 packages in your dependency tree that hardcode their depen…

> Now good luck to get that with most lock-file based package managers like npm, cargo or pip with ~1000 packages in your dependency tree that hardcode their dependency number...

I don't know about spack or Guix, but nixpkgs has buildRustCrate, which builds each Rust crate dependency as a Nix derivation (it does not use Cargo). In this kind of setup it is possible to override specific crate versions across all packages that use a specific crate.

Unfortunately, currently most Rust-based packages in nixpkgs use buildRustPackage, which does not follow this approach [1].

[1] https://github.com/NixOS/nixpkgs/issues/89563

Re: Dynamic linking

#212

Post by AnIdiotOnTheNet »

petters wrote: post #52
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…

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.

> 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.

Ironic considering that the package manager/repo model is largely implemented as a solution to issues with dynamic linking and yet makes getting up to date software from the developer much harder by introducing a third-party maintainer into the process.

Re: Dynamic linking

#213

Post by AnIdiotOnTheNet »

enriquto wrote: post #204

Static executables are a sweet spot between the craziness of dynamic dependencies (where we come from) and the idiocy of shipping a whole virtual machine for each program (where we seem to be going to). If we could just stop at that spot!

I kindof agree, but I think the real sweet spot is that system libraries[0] should be dynamically linked and everything else should be static.

For Linux though, where the very concept of a standardized base system is loathed, static the sweet spot.

[0] libraries that are likely to be used by a large number of applications like the GUI libraries, kernel interfaces, networking, encryption, etc.

Re: Dynamic linking

#214

Post by AnIdiotOnTheNet »

bscphil wrote: post #161
rumanator wrote: post #19

Earlier quoted context omitted.

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

> 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, li…

> 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.

Re: Dynamic linking

#215

Post by tsimionescu »

Aissen wrote: post #191
tsimionescu wrote: post #183

> The total download cost to upgrade all binaries on my system which were affected by CVEs in 2019 is 3.8 GiB. This is reduced to 1.0 GiB if you eliminate glibc. The upgrade problem has almost nothing to do with download size. The real problem is that you have > 100 binaries which depend on those libraries, and instead of having the library authors go and update the library, you need each team responsible for one or…

> instead of having the library authors go and update the library, you need each team responsible for one or more binaries to go and take the new library and release a new version of their binary. Wait, so you're telling me dynamic libraries are a way for distros to ship their org chart? Maybe it's time in 2020 for automated and deterministic builds to allow anyone to ship a library update and have dependent packages…

> Wait, so you're telling me dynamic libraries are a way for distros to ship their org chart?

I'm not sure what you mean by this. The libraries are not maintained by the distro, they are maintained by the library maintainers; the distro just distributes them when new versions are available, after testing.

> Maybe it's time in 2020 for automated and deterministic builds to allow anyone to ship a library update and have dependent packages being rebuilt automatically if needed.

This would be nice, but it is not there yet for most languages/pacakges; and you still need to solve the problem of who will actually run those automatic builds.

Re: Dynamic linking

#216

Post by jeffbee »

binarycrusader wrote: post #158
danans wrote: post #153

Earlier quoted context omitted.

> Cloud vendor computing models are not generally the computing model of the rest of the world. > Comparison to their environment is not relevant to the general populace. The way that Google shares server compute and memory resources is by having a service oriented architecture. A single high scale service serves many different applications, usually colocated in the same cluster or data center. Each service is based…

I'm aware, which is why I specifically said that cloud vendor computing models aren't really relevant to the general populace. Google's model in particular is (or at least was) very different from other vendors.

I don't disagree with your point that use cases vary, but when I hear people say that "only clouds need this" I think the speaker is underestimating the size of cloud facilities. The amount of the world's computers that are in Amazon's, Google's, Facebook's, and Microsoft's clouds is a huge chunk of the total.

Re: Dynamic linking

#217

Post by spacechild1 »

kick wrote: post #140
spacechild1 wrote: post #136

Earlier quoted context omitted.

You're being unnecessarily rude.

The point of the first half of his comment was very obviously pointing out that "form is less important than content" is wrong; Saagar wasn't doing it for no reason, and wasn't doing it in bad faith. That's why it was in an entirely different tone than the rest of the comment, and just about every other comment he's ever made on this site.

Oh, I see. Sarcasm on the internet can be tricky. (There are many people who actually write like that, or much worse.)

Re: Dynamic linking

#218

Post by [deleted] »

tsimionescu wrote: post #215
Aissen wrote: post #191

Earlier quoted context omitted.

> instead of having the library authors go and update the library, you need each team responsible for one or more binaries to go and take the new library and release a new version of their binary. Wait, so you're telling me dynamic libraries are a way for distros to ship their org chart? Maybe it's time in 2020 for automated and deterministic builds to allow anyone to ship a library update and have dependent packages…

> Wait, so you're telling me dynamic libraries are a way for distros to ship their org chart? I'm not sure what you mean by this. The libraries are not maintained by the distro, they are maintained by the library maintainers; the distro just distributes them when new versions are available, after testing. > Maybe it's time in 2020 for automated and deterministic builds to allow anyone to ship a library update and hav…

[deleted]

Re: Dynamic linking

#219

Post by btilly »

steveklabnik wrote: post #144
btilly wrote: post #117

Earlier quoted context omitted.

I have not used Rust very much. But in https://doc.rust-lang.org/cargo/reference/build-scripts.html I find comments like, It is recommended to carefully consider each dependency you add, weighing against the impact on compile time, licensing, maintenance, etc. Cargo will attempt to reuse a dependency if it is shared between build dependencies and normal dependencies. However, this is not always possible, for example…

This is talking about very different issues than the ones identified in that paper. Most of that paper, if not all, does not directly apply to Cargo.

Thank you for the insight. I know you know Rust very well.

Do you have an explanation for why compile times would be an issue for Rust?

Re: Dynamic linking

#220

Post by btilly »

saagarjha wrote: post #147
btilly wrote: post #145

Earlier quoted context omitted.

This is quite possibly the stupidest thing I have heard this year. How could you possibly have come up with something that brain-dead? That is an opinion. It is your opinion. I happen to have a very different opinion. It may be surprising to you, but surprise doesn't mean that it is trivially wrong. Experience has taught me that if you have good content, then you have something worthwhile to say if I can get past the…

I have read a lot of your writing, much more than you've linked here, simply by being active on this site for just over three years. While I don't really think I could say I know you personally, I think I have at least a little bit of context about you, what your interests are, and what you like to talk about. Your comments have been consistently useful and relevant, and I have no complaints there. But back to the to…

I agree that form and content are not a zero sum game, and try to present with a combination of form and content.

But when I consume information, I prioritize looking for content over form.

Post reply on HN