|
|
|
|
|
by jjoonathan
4068 days ago
|
|
> 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. |
|