Dynamic linking

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, like this article), but because I fear the ecosystem changes that a major shift towards static linking would allow.

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. I think they solve some important problems: when a maintainer is the gatekeeper, it means that a dev has to convince a third party that their app is (a) worth including, (b) not malware, (c) open source - at least heavily preferred since the dev will be building it themselves. And plus having a maintainer means someone besides the original dev is responsible for making sure you get security updates.

Now of course you can distribute statically built apps that way, but there's a reason it's less common. There are so many Go apps out there where the only supported method to build them is using the Go toolchain and pulling in 150 Github repos.

See also: this defense of the maintainer-based ecosystem, from an Arch Linux dev. http://kmkeen.com/maintainers-matter/

It makes ops so liquid and convenient. I love it.

To really push this idea (and microkernel) to its logical extreme, it would be cool to see a null-kernel. You have socket drivers, that's it. Everything is either a network call or some sort of IPC. You might still need something to handle paging, though, and obviously your "peripherals" like storage would need to be more conventional in nature.

If you care about security, you shouldn't be running closed source software anyway, at least not outside of a container.

Statically linked binaries for open source software, containers for everything else, and you're good to go.

Imagine statically linking UIKit or Android's UI library!

1) when making a static link archive (a .a file), include a .o with a static symbol(s) whose values(s) records the metadata that ELF would have recorded, which here is: a) dependencies, b) how to find them, c) the mapfile / version-script (at least which symbols are symbolic, protected, or demoted to local, and which, if any, are interposers.

2) on final link-edits only the direct dependency -lfoo arguments should be needed, and then link-editor should find the dependencies' dependencies... by looking at the metadata recorded in the .a files.

Really, it's very simple. libstool is a very bad attempt at layering this on top of the linker (recording metadata in .la files), but it doesn't work well. This functionality has to be in the linkers.