dynamic linking bad

static linking good

@sir binary size tho .-.

with a good package manager dynamic linking is fine?

@syntacticsugarglider binary size is fine if you have a competent linker and don't load up on dependencies like it's ladies night at the local all-you-can-eat buffet

@sir sure but even with LTO you still obviously have to ship the code you use

with dynamic linking you don't

with a good package manager the question isn't "can we bear the storage cost?", it's "why would we want to bear the storage cost?"

@syntacticsugarglider with people shipping entire fucking web browsers, I reckon that shipping another megabyte for some shitty library isn't going to be the end of the world. We should be spending our modern storage miracle on stability, not laziness

@syntacticsugarglider the real savings are not from dynamic linking, but from not shipping complicated, overengineered, lazy garbage

@sir yeah of course

but once you have good software, why not dynamically link common libraries?

and how far do you go? do you ship statically linked musl instead of using system libc?

i just don't really think there's a problem to be solved by statically linking everything

@sir i mean i agree that it's not the most pressing issue but at the same time why make that concession?

linking errors are basically a thing of the past with modern package managers (esp. something like Nix that maintains a fully atomic state graph where basically nothing can go wrong)

@syntacticsugarglider @sir

Binary size, RAM usage and loading time are increased with static linking.

@danyspin97 @sir an important point to make is also that static linking makes updates far less efficient in most software ecosystems and also makes the developers of individual like... leaf nodes in the ecosystem (i.e. user-facing binaries) responsible for security upgrades, which is something people are notoriously incapable of doing consistently and expediently

@danyspin97 @syntacticsugarglider binary size, RAM usage, and loading time can all be improved by not making your application a giant hulking monster

Also loading time is definitely faster with most statically linked programs

@sir @danyspin97 right but why have your application be a non-hulking reasonable sized program when it could be an absolutely tiny program that ships a negligible amount of executable code

and the security updates point still stands, which is probably the most important argument for dynamic linking bc all of this other stuff is, as you said, somewhat irrelevant while we're still shipping entire browsers with our executables

@syntacticsugarglider @danyspin97 the hulking monster doesn't go away if you shove it into your libraries. Most programs *don't* share most libraries, odds are that when your program is installed most of its dependencies are also being installed for the first time - and you're probably using less than half of each.

And the importance of shipping security updates via dynamic linking is grossly overstated.

@sir @danyspin97 most programs share **some** libraries, not most libraries.

but... what? you can't just state something is "grossly overstated". how is it not a huge issue? openssl breaks constantly and if anything links statically against it it's not like it's going to get instantly rebuilt and updated and, even if it were to, you would have to redownload **every single binary** that uses it. you could say "just don't use openssl" but that's a "if things were nice they would be nice" argument

@syntacticsugarglider @danyspin97 oh yeah sure bring up openssl, literally the only library for which this argument is ever made. I'm surprised it took this long.

Of the 2188 packages I have installed, 70 of them depend on OpenSSL.

@sir @danyspin97 it's just the best example

and honestly... i've heard a lot of refutation of my various arguments for why dynamic linking is advantageous

...why is static linking advantageous? because you don't need a good package manager? we have those. because you might end up with wasted space in fact if a library isn't widely used? well, as a developer one has no idea how widely a library is going to be used in the future at compile time.

@syntacticsugarglider @danyspin97 because a statically linked program which works today will work tomorrow, and a dynamically linked program which works today will break tomorrow.

@sir @danyspin97 this doesn't happen with a proper package manager

(something like nix)

@sir @syntacticsugarglider

That's true. For examples programs linked with Boost breaks every update. Can this be fixed instead of changing paradigm?

@danyspin97 @sir yeah it's not hard: use semantic versioning and don't randomly break your existing API surface without bumping the major version

@syntacticsugarglider @danyspin97 or, statically link and then you can do literally anything you want without breaking my program

@sir @syntacticsugarglider @danyspin97 not really. Today a lot of common code is shipped not as libraries but as services (accessed through dbus in Linux/Unix) and you sure as hell can't statically link those. So the whole argument is basically irrelevant.

@sir @emacsomancer @danyspin97 "severe security vulnerabilities are rare"

drew i know you live in some sort of weird future utopia where people write good, stable, minimal software but... the rest of us don't

you continually acknowledge that software is terrible. software is often vulnerable. this is ridiculous, especially coming from you.

@syntacticsugarglider @emacsomancer @danyspin97 software is terrible for reasons almost entirely unrelated to security

@syntacticsugarglider @emacsomancer @danyspin97 oh yes that's helpful just post all vulnerabilities at every level of severity for all software in every fucking domain in the entirety of 2020 why don't you

@syntacticsugarglider @sir @danyspin97

Of course, the counterpoint is (old) statically-linked libraries don't introduce *new* security vulnerabilities

@emacsomancer @danyspin97 @syntacticsugarglider aye, correct. And often the security vulnerability is in a code path that never gets hit by the program which is supposedly affected

@syntacticsugarglider @sir @emacsomancer @danyspin97 I'm confused. You have a vulnerability in some software, it's patched upstream, you rebuild / update it. Why is this an argument against static linking? I think I'm with Drew here, the percentage of programs depending on the same libs is too little for this to matter.

@sir @syntacticsugarglider @danyspin97 70 if you use direct dependencies or also with stuff like a program using curl and thus depending on OpenSSL or similar.

@sir @lanodan @danyspin97 sure, it's like less than half of that on mine

but at the same time more than 75% of the shared libraries on my system are used by more than one executable

@sir @lanodan @danyspin97 also like

- libffi
- libz
- libm
- pthread
- pcre
- libx11
- systemd
- harfbuzz
- freetype
- libuuid
- libjpeg
- fontconfig
etc. are all sizeable and used (except for fontconfig, which is used by 85) by more than 100 of the only 2905 executables on my system. there are more but these are the most obvious examples

dynamically linking those would be frankly ridiculous, and it turns out examples of things that are unique to a package are very rare (at least for me) <25%

@syntacticsugarglider @lanodan @danyspin97 I have also found that, on average, the typical dynamically linked executable on my system is using only 4.6% of the symbols on offer from its dependencies, so if it were statically linked the increase in size is unlikely to be severe

@lanodan @danyspin97 @syntacticsugarglider yes, it's a box plot. The extent of the box is the first and third quartiles, and the dots are outliers

@sir @danyspin97 @syntacticsugarglider So direct ones.

See the difference between these two:
$ pkg-config --libs openssl
-lssl -lcrypto
$ pkg-config --libs --static openssl
-lssl -lresolv -lpthread -lcrypto -lresolv -lpthread -lcrypto -lresolv -lpthread

Or for a basic web browser which basically only pulls webkit-gtk:

@sir @syntacticsugarglider

In my experience, this is in part true. It depends on the language and its ecosystem.

Most C/C++ packages reuse something already there and only some add a new dependency.

Python packages instead add a new dependency each.

@danyspin97 @sir yeah and in my experience any language with actual binary linking is going to tend toward the former case

@sir @danyspin97 @syntacticsugarglider Why is this discussion always the same. And what is the difference in mentality of people from either camp?

@sir @syntacticsugarglider

Dynamic linking is 2x time slower than static; I didn't expect it at all. Thanks for running a benchmark.

@sir @syntacticsugarglider

This is also a good metric. Tomorrow I'll run it on both my systems and share the results, if different than yours.

miniature american flags for others

@sir with a competent package manager which tracks statically linked libraries in packages and automatically updates all dependant packages on a library update, sure. But updating a core package would require a rebuild and update of almost all packages on the system which puts a big load on the network and requires too much power. I think if we had a good package manager, the benefits would be much better than the disadvantages.

@paper @sir rebuilding isn't that much required with static linking actually, you should be able to relink fine, like you currently do with dynamic linking.

To me the only current use of dynamic linking is because Unix-likes can't write proper protocols so we have compat librairies and stuff like linking libGL to different targets.
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!