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.
I'm not sure that I would want all of Windows libraries to be statically linked to all my applications.
Sometimes you want static linking - sometimes you don't.
This is a very very tiny part of an app. UI libraries with prebuilt controls are already almost always bundled with apps.
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)".
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.
Why not?
> Sometimes you want static linking - sometimes you don't.
Why wouldn't you here?
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.
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).