Hard drives are cheap, so space is not an argument anymore, for reasonable uses of disk space. And most uses are reasonable!
Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword.
The impetus behind the virtual environments for scripting languages, like Python's venv and Ruby's RVM, is isolation from the base system. Untold developer hours have been lost in attempts to run software with different dependencies than the base system. It's a total mess.
We shouldn't expect an operating system to be a monolith that dictates the dependency versions for all the code that runs on it. Code should be deployed in sandboxes and it should be independent of the base system. When the code is removed, it should be like it was never there.
Hint: static linking predates Plan 9. Static linking even predates shared libraries. Back in the '80s there were impassioned quarrels over whether anything should be shared. Laura Creighton was static linking's most impassioned voice. The fact that a shared library may be mapped once and used by all the programs that call it carried the day, back when main memory was measured in megabytes, and GUI libraries were huge and getting bigger.
If there is anything we should thank Plan 9 for, it has to be UTF-8.
> Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword.
Not sure I understand. I imagine without dynamic linking/shared libraries, most widely used shared libraries would be widely used statically linked libraries, and so a vulnerability in them would indeed be harder to fix, as you'd need to relink all the binaries using them instead of just the dynamically linked library?
(Also, memory usage seems more concerning to me than disk space. Shared libraries are called "shared" because all their non-mutable pages in memory are shared across processes. To even approximate the same with static libraries, you'd pretty much have to have deduplication of pages in memory. Link-time optimization might then spoil even that plan entirely. Of course on the other hand, dynamic linking precludes LTO for that.)
You don't re-link binaries. The vendors ship you a new build. Your OS should not have any libraries other than the ones it needs to function by itself.
Well, that's the point. The vendor needs to relink, and now you need to wait for an update from the vendor of each individual client of a library. With shared libraries, replacing the shared library is enough.
What I did not understand is how static linking would have precluded the problem in the first place. I don't think that would have made those libraries less widely used.
> With shared libraries, replacing the shared library is enough.
Yes, but if a shared library update includes a bug, it affects all your programs! That's why it is a double-edged sword: The same mechanism that solves the bugs can also deliver bugs.
This comes up constantly and is pretty easily refuted by opening pretty much any app on an Android or iOS phone and observing just how many pages of the system shared libraries are touched by even the most trivial apps. You can do this by e.g. purging the FS cache, disabling readahead, launching an app, and then observing how many code pages are resident.
All of that code would have to be brought into app binary itself, making mobile apps even larger in code size than they already are. Dead code elimination could eliminate some of that bloat, but I doubt it'd eliminate much of it, given that we're only measuring resident pages to begin with.
Only allowing static linking might make sense on servers (it certainly makes deployment a lot easier). But it wouldn't work on mobile devices without significantly changing the way mobile apps and OSes are architected.
Including XPC, D-BUS and COM into the picture, which allow for dynamic linking, or if one wants static linking like experience with out-of-process servers, and still there are some issues with it.
I don't much care for static linking. I do care about it being too difficult to have multiple versions of the same shared library, and no easy distribution mechanism when I just want to shoot a binary over to some system and run it.
In an ideal world, archives would be well structured executables and my system would automatically deduplicate libraries out of them when they landed on the local filesystem. The linker would automatically pull a whitelist of "known bad" and do overrides for me from my package manager/security source automatically.
> Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword.
By this logic, every game developer should be writing their own versions of Vulkan for every GPU they want to target. They would have to ship their own set of GPU drivers with every game.
Also, every app that wants to make a TLS connection would have to develop its own cryptography primitives. Hope you enjoy writing ASN.1 parsers (in C, because that's the Plan 9 way).
Sorry, but this "no dependencies" utopia is completely impractical.
Hard drives are cheap, so space is not an argument anymore, for reasonable uses of disk space. And most uses are reasonable!
Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword.
The impetus behind the virtual environments for scripting languages, like Python's venv and Ruby's RVM, is isolation from the base system. Untold developer hours have been lost in attempts to run software with different dependencies than the base system. It's a total mess.
We shouldn't expect an operating system to be a monolith that dictates the dependency versions for all the code that runs on it. Code should be deployed in sandboxes and it should be independent of the base system. When the code is removed, it should be like it was never there.