> if your tiny executable uses just some methods of a gigantic library, it can do so an it will still stay tiny
How many other functions do the ones you explicitly call drag into the executable? How do you propose to deduplicate them and their resources between processes? I'm specifically thinking about UI code. Having 30 different copies of your UI toolkit and its resources would be silly, even if each was stripped to 1/3 the size of the original. "Just use IPC and do UI in the window server" sounds an awful lot like X11, whose architecture we were just starting to migrate away from!
> Shared libraries are the reason a lot of app installations are several GB these days.
What are you referring to? vcredist is 7MB. Direct X runtimes are ~100MB. Qt is 20MB. Not small, but not the majority of several GB. Sure it's silly to ship an app with a shared library rather than statically link it, but I think you're exaggerating the scale of the problem and understating the number of profitable examples of library sharing, especially when it comes to UI libraries.
The X Window System architecture solves a specific problem - allowing clients to use graphical applications no matter where the app actually runs. This was important in the 1980s and is still worthwhile today - no matter how much compute power you can stash under your desk or wear on your wrist, you can cram orders of magnitudes more into a data center. Having a uniform interface that's independent of where the heavy lifting actually happens is a crucial accomplishment for X, and throwing that away with the focus on Direct X is ultimately a mistake.
Not saying X is anywhere near perfect. But losing network transparency is a mistake.
Personally I always preferred MGR. I suppose that evolved into Plan 9's window system, but I've never tried the latter. My attempt to bring MGR into the modern age is clunky at best. https://github.com/hyc/mgr But there's a lot to be said for a lightweight network-transparent protocol with a braindead-simple runtime.
How many other functions do the ones you explicitly call drag into the executable? How do you propose to deduplicate them and their resources between processes? I'm specifically thinking about UI code. Having 30 different copies of your UI toolkit and its resources would be silly, even if each was stripped to 1/3 the size of the original. "Just use IPC and do UI in the window server" sounds an awful lot like X11, whose architecture we were just starting to migrate away from!
> Shared libraries are the reason a lot of app installations are several GB these days.
What are you referring to? vcredist is 7MB. Direct X runtimes are ~100MB. Qt is 20MB. Not small, but not the majority of several GB. Sure it's silly to ship an app with a shared library rather than statically link it, but I think you're exaggerating the scale of the problem and understating the number of profitable examples of library sharing, especially when it comes to UI libraries.