Shared libraries are a tradeoff from a time (80's and 90's) where big projects like GUI systems needed to be run on small computers.
Today with the cheap memory resources and fast interfacing you are often better off with programs that are statically linked as they have no run dependencies other than the OS.
Well, in Windows and MacOS you need libraries like kernel32.dll etc to sit in-between userland and kernel because the kernel ABI is not stable, like Linux.
Also, Linus talks about this sort of exception in his post: "unless it's some very core library used by a lot of things (ie particularly things like GUI libraries like gnome or Qt or similar)".
Even desktop libraries are moving towards IPC architectures so not even they require dynamic linking. E.g you don't dynlink a library for the trashcan subsystem, you communicate with some service on the dbus thingy. This makes hot updates possible which you don't get with dynamic linking.
Demo scene windows programs essentially revolve around the fact there is an enormous amount built in to windows that can be relied on. You can make a tiny windows GUI binary that is a few kilobytes and has no dependencies other than what comes with windows.
GUI is something like an API, let's take React Native - you just have an api to rendering (via bridge), same for X server, same for almost any GUI framework.
This is a very very tiny part of an app. UI libraries with prebuilt controls are already almost always bundled with apps.
Its not all the windows libraries, but often the OS creates just one interface library to wrap the syscalls. Those do not tend to be big libraries where you should worry about being statically linked to your program.
The problem with Linux also have to do with license, giving GPL can get some program into trouble by statically linking GPL code.
There are 3 cases for me that can force one to use shared libraries: Licensing, Dynamic loading a DSO at runtime (like in Apache modules) and when you are developing a big project, but once you need to ship the production code, get it back to statically linking everything.
Other from that i don't see why you would want this.
> Today with the cheap memory resources and fast interfacing you are often better off with programs that are statically linked as they have no run dependencies other than the OS.
This might be the case for developers, and for some people in the first world, but much of the world is using older hardware with relatively smaller amounts of memory and storage.
I've noticed developers tend to buy new computers often, but a lot of people just have one computer they bought several years ago and have no reason to upgrade it because it works well enough for Facebook, YouTube and email.
>much of the world is using older hardware with relatively smaller amounts of memory and storage.
If you read Linus' email, you'll see that for most libraries it doesn't save any memory or disk space.
What it WOULD do to link statically is save the extra IO needed to load shared libraries (somewhat, the same code would be loaded at program execution instead of dynamically).
Today with the cheap memory resources and fast interfacing you are often better off with programs that are statically linked as they have no run dependencies other than the OS.