> ...but at some point people will realize again all the issues and limitations of that and go back to dynamic linking.

Except that for using third-party libraries and distributing apps or games, there is no reason to use dynamically linked libraries here and also in software distribution.

I guess if you talked to iOS / Android app developers who complained about dynamically linked third-party libraries that slowed app execution startup times, desktop app developers who wanted a single statically-linked executable that prevents their app being hijacked with a malicious dynamically linked library via LD_PRELOAD or DYLD_INSERT_LIBRARIES or in general developers or users don't want to have to upgrade other dependencies using dynamically linked libraries to install your software, then I guess one can say it would be better to use static binaries here.

Who's to say that a hacker can simply modify a .dll, .dylib or .so in your game and enable developer cheats to ruin it. The authors point on LD_PRELOAD alongside with 'security benefits' is nothing more than outdated and has now been intellectually bankrupted.

I am more interested in security for users than for developers. Sure, it's convenient and might be slightly more work for users to mess with your app, but I don't trust every proprietary app developer to be monitoring the CVEs for every library they use.

I'm sure there's a ton of multiplayer games out there that statically linked things like libpng and networking libraries, and by now are an open door into the systems of anyone playing online.

> I'm sure there's a ton of multiplayer games out there that statically linked things like libpng and networking libraries

you know that even when they are dynamically linked, the developer just ships the dlls next to the app right ?

Security is a wrong argument. You can have dynamic loading and locked source folders and disabled LD_PRELOAD. At the opposite, remember that each statically loaded exe would have to constantly be updated/recompiled for all the libraries updates that they use or could let a lot of security holes opened for a long time.

On the flip side, with libraries that use version symbols, you need to update all of the versions, so dynamic linking might have some of the same problem.

> The authors point on LD_PRELOAD alongside with 'security benefits' is nothing more than outdated and has now been intellectually bankrupted.

I LD_PRELOAD (and DYLD_INSERT_LIBRARIES) code into every process I spawn from the command line, except setuid executables (and sometimes even then–I jump through the hoops necessary to make this work), because it lets me extend compiled applications in arbitrary ways to better suit whatever I want them to do. Saying that my usecase is "outdated and…intellectually bankrupted" just because you're not aware of the very real and very convenient benefits of function interposing is the real ignorance here.