5 ms·
This isn't really a dynamic vs static linking problem. This is an ABI problem and affects static libraries too depending how each library was compiled and what
by dottrap 11y ago
This isn't really a dynamic vs static linking problem. This is an ABI problem and affects static libraries too depending how each library was compiled and what its dependencies are.
Go avoids this because the language designed in simpler ABI requirements, and also doesn't allow binary libraries at all (everything is expected to be source code). This completely avoids the problem since you only have one compiler producing all the components.
But this isn't always a good thing. There are some good reasons for prebuilt libraries. (I had the unfortunate need to recently compile a huge C++ library on a slow ARM based embedded machine without the help of a cross-compiler. It took about 14 hours to compile. And I had to do it twice because the first time the build flags were wrong.)
For more interesting perspective on dynamic vs. static libraries, read:
iOS Static Libraries Are, Like, Really Bad, And Stuff (Radar 15800975)http://landonf.org/code/ios/Radar_15800975_iOS_Frameworks.20140112.html http://landonf.org/code/ios/Radar_15800975_iOS_Frameworks.20...
- pbiggar 11y ago> Go avoids this because the language designed in simpler ABI requirements, and also doesn't allow binary libraries at all. Yes, this is what I'm getting at! This mess of linking and ABIs is a mess, and it shouldn't exist unless it must, and it only must in very few cases. Thanks for the link, I'll take a read.
- felixgallo 11y agoFor instance, all those cases where you'd like security issues fixed by updating a shared library, rather than finding and recompiling and redistributing every program on your system that may have used that library.
- marssaxman 11y agoAs an end user, I'd like to ensure that it's impossible to change the behavior of multiple unrelated applications by upgrading something on my system. I don't want a program to change until I decide to upgrade that specific program.
- felixgallo 11y agoI assure you, that is not at all what you want. https://cve.mitre.org/data/downloads/allitems.html https://cve.mitre.org/data/downloads/allitems.html
- marssaxman 11y agoI'm not running a server; I'm running a PC. Security problems affect me very little; broken functionality affects me all the goddamn time. edit: also, because I'm talking about PCs and not servers, I'm running very few apps, and most of them do not interact with the network. Strategies for securing servers do not necessarily make the right tradeoffs for personal machines.
- felixgallo 11y agoI understand your base viewpoint. Nevertheless, you are still incorrect; many hundreds if not thousands of executable programs provide you with your experience, if you're using linux, osx, or windows; every executable on your system is capable of interacting with outside sources of malevolence, be that the network, usb drives, bluetooth anything, files that you got via e-mail; and if anything, personal machines need even more vigilance and patchability, as their attack surface is radically larger than your average server. The ability to update common components is a boon. Seriously. Not without concerns or flaws, as you correctly note. But overall, it's radically better than the alternative.
- marssaxman 11y agoIt's not a matter of correctness or incorrectness; it's a judgement about the relative costs. I have experienced vastly more inconvenience as a result of breakage caused by well-intentioned updates than I have ever experienced as a result of malevolence. As a result, I habitually disable all auto-update systems and do whatever I can to prevent my machine from trying to update itself. So what's really been gained? I have the stability I want, but the supposed security benefits of the incremental update process are lost. In practice, hacker attacks trouble me about as much as terrorist attacks, while system breakage resulting from library updates is common and hard to fix.