[rsp1984]

An excellent read. Moreover, most linkers these days have the ability to strip out unused code from your executable if you are using static linkage.

That means if your tiny executable uses just some methods of a gigantic library, it can do so an it will still stay tiny. Contrast that with dynamic linkage where in practice the whole gigantic library has to ship with your executable because you can never be sure that the host will already have the right version of libGigantic installed. What a mess.

Shared libraries are the reason a lot of app installations are several GB these days. And I dare say that 99.x % of the code that's shipped with an installation package never gets used by the app installed and that most compiled app code would comfortably fit on a couple of floppy disks if static linkage was used rigorously.

[jjoonathan]

> 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.

[hyc_symas]

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.

[hbogert]

Now, only if X actually worked when you want it to run in a data center and see it on your laptop. X is horrible when the latency goes above 5ms.

[hyc_symas]

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.

[jjoonathan]

> losing network transparency is a mistake.

Why? X11 competes with VNC to provide remote interaction. VNC wins, and not by a small factor, on the apps I use day-to-day.

[Fenume]

Don't forget, X11 is the reason why Unix got dynamic libraries.