Shared libraries mean that when there's a security issue, I can update the system's version of the library, restart all programs that use it, and have a fully patched system. If everything is statically linked, I would instead need to identify the library version in use for every binary, then get a patched version of each.

Dynamic linking is a tool to improve system administration.

Dynamic linking is a way to get opaque updates from vendors that may or may not have the patch you want, may or may not have a new CVE that you don't want, and have a very difficult time knowing if the code that's going to run when you invoke a given executable is the same or different from what you ran last time and how.

Here I thought symbolic links were "the most brain-damaged, over-used, needlessly complex, crime against computing in common use." I am not making this up, ask Jeremy Allison, who is in a position to know.

Using Nix without relying on symbolic links would be ... challenging.

Symbolic links can be a pain in the ass, but they're comprehensible and serve a purpose. Most importantly, they're pretty opt-in. Now maybe that means you opted in because you're using a piece of software like NixOS that can't work without them, but they don't infect everything and spread like Kudzu.

The `glibc` people won't even make it work properly without being an `.so`. I appreciate that the GCC people are desperately trying to hold on to relevance in the face of a much better toolchain, but at what point does the FSF die a hero or live long enough to become the villain it was trying to conquer?

Jeremy is a bright guy and I have huge respect for him. And I know the `cat-v` folks troll a bit much, but there is some real substance to linked set of arguments [0]. And it very much ties out with my experience.

In the glory days at FB we statically linked everything, and it was amazing. I don't know this firsthand but I've heard it secondhand, and given that we plagiarized basically everything else from Google in those days, I tend to believe the claims that Google did the same.

“I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.” – John Carmack

[0] http://harmful.cat-v.org/software/dynamic-linking/

There is no question but that symbolic links are convenient for users. Apparently the problem is that file-system operations on file systems that allow them, or that allow them to be changed, cannot be made secure. Maybe if you could turn off everybody's rights to create or delete symlinks, they would become less problematic. Maybe, have a mount option you could toggle on just when you need to change some, and turn it off again right away.

Dynamic linking used to be a big optimization thing -- saved on disk space, saved on virtual-memory footprint; nowadays we hardly notice. Next, it meant you didn't need to rebuild everything when a library got a fix or backward-compatible improvement. Then, it became a way to get security patches into use quickly.

It is kind of impressive that we don't (often?) see dynamic linking itself used as an attack vector, aside from bugs in the libraries so linked.

Eh, I will respectfully disagree on a couple of points.

Silently patching `.so` code actually obscures whether or not you have the relevant security fix to the relevant library. `libfoo.0 -> libfoo.0.1 -> libfoo -> 0.1.3` would be confusing enough even if vendors didn't routinely change the code out from underneath without moving the "version". If you're linking a `libfoo.a`, not only does the hash of that file change when it gets updated (or was failed to be updated), but the hash of your resulting binary that you choose to run either did or did not change. You don't need NixOS for that. No `LD_PRELOAD` crap can get in front of you because someone grabbed control of environment variables. There's like a zillion less things to go wrong from a security perspective. And even then, the security that you get from running a binary you built against someone who is already on your machine, and already has enough permissions to run it? You're in murky territory already. Keep them out of your box unless you're a cloud provider or something.

I'm no FS expert and I'm prepared to believe that symlinks might create problems for filesystem engineers, but you also sort of need them if you want atomic FS operations on POSIX. Something being a standard isn't a blank check to be bad obviously, but it's a lot easier to change whether or not `glibc` breaks on purpose when statically linked than to change a 30-year-old standard.

Dynamic linking is a nightmare for a number of reasons: it makes it murky and difficult to know what code is running, it makes effective text segments depend on environment variables, it further privileges superuser, it destroys the portability/backwards-compatibility that Linus has fought so hard to preserve in the kernel, it miseducates people about how virtual memory works by leading them to assume that it's some kind of performance win (it's not), it complicates the whole system by a ridiculous amount, it requires that you `readelf -d thing` to even know what crazy `rpath` shit is going on.

Symlinks have problems, I've been burned by them. But you can use them or not as you like, and the complexity is manageable. You show me a serious hacker, I'll show you someone who can get symlinks substantially right.

You show me someone who really, really deeply understands what the hell is going on with dynamic linking? I'll show you Ulrich Drepper and his weird agenda around suppressing LLVM.

Symbolic links are an overwhelmingly greater problem than just for "file system engineers".

If you code a program that does Posix file system operations, and may be used where security matters, congratulations, you are a security hole vector.

There’s a difference between deploying software to a data centre, and to a user’s personal PC

Oh sure, I completely agree. But a clear trail of custody around all of the text segments that end up in the binaries that get executed serve both use cases well.

I appreciate that for a lot of desktop users they just want it to work and aren't terribly picky about which minor version of `libfoo` is required to get Firefox or Chrome to start.

But there are vendors and maintainers who are deeply concerned about such things when attempting to give the desktop user a seamless experience, and why a big mushy puddle of who-friggin-knows code makes that job any easier?

Who friggin knows. I think it's just inertia.

The fact of the matter is that everything from snaps to flatpaks to docker to this whole containerization craze is mainly dealing with the pick a card, any card outcome you get with a bunch of random `.so` in `/usr/lib/`.

What's the alternative?

Nix/NixOS is an alternative, but as I've mentioned elsewhere in the thread it's got major, major downsides.

Excluding that, you can go the Alpine/Docker route, which isn't terrible but isn't great.

Or you can rebuild your box via Ansible or whatever every time you need a new AMI. This is actually a pretty reasonable solution.

Wait, I thought you were criticizing Nix because it uses symbolic links.

I originally used Absible but switched to Nix. I found ansible to be too idiosyncratic and brittle to maintain. It also isn't inherently idempotent though it's supposed to be used that way.

I believe it's `ncmncm` who is mounting a credible argument against the existence and use of symbolic links. I'm the "fuck dynamic linking by default" guy.