5 ms·

Author here. In everything in the post, I attempted to give Drepper the benefit of the doubt, though there are cases where I don't want to since he sounds (to

Author here. In everything in the post, I attempted to give Drepper the benefit of the doubt, though there are cases where I don't want to since he sounds (to me) paternalistic in the way Apple and Microsoft do. So perhaps he understood, but I didn't want to assume that, especially since it might inflame the discussion, which is exactly what I was trying to avoid doing (again).

PaulDavisThe1st 5y ago
DLL Hell was well understood in the mid-90s. I think you need to give him more benefit of the doubt on this point.
- ghoward 5y ago
  I'm having a hard time understanding because if DLL Hell was well understood by 2006, it seems I should have given him less benefit of the doubt, but you say I should give him more. Apologies.
- torstenvl 5y ago
  If someone glosses over an issue, it's either innocent (didn't know about it, didn't understand it) or deceptive (intentionally ignored it). Giving Drepper the benefit of the doubt here means assuming he didn't know or understand the problem he failed to adequately address.
  - PaulDavisThe1st 5y ago
    Here is most of the relevant text from TFA: > Ulrich Drepper claims, rightly, that you only need to update a shared library to apply security fixes to all executables that rely on that library. > This is a good thing! It is also a good vision. > Unfortunately, it is only a vision because it’s not the whole story. > As of yet, there is no way to automatically determine if the ABI or API of a shared library changed between updates. This is called DLL Hell. The final two words are a link to the wikipedia page on "DLL Hell". The final sentence of the intro section there states: > DLL Hell is the Windows ecosystem-specific form of the general concept dependency hell. That is, TFA defines "DLL Hell" using a wikipedia page that explicitly states that it is a Windows-specific version of a more general problem. Drepper's article from 2006 fully tackles the general problem, albeit without (as the TFA puts it): "a way to automatically determine if the ABI or API of a shared library changed between updates." Drepper's primary suggestion there is a naming/versioning scheme which describes specifically whether the ABI/API has changed in ways that matter for shared linkage. It's not automatic - that part is true. But is is a solution, widely used in Linux and *nix more broadly. Did Drepper address the Windows specific parts of "DLL Hell". He did not, but that's because "DLL Hell" is Windows specific (as other comments here fully clarify), and he was not writing about how to fix the full scope of that particular nightmare. He likely understood "DLL Hell" as well as anyone, nevertheless.
    - torstenvl 5y ago
      I think you're missing the point. When the only alternatives are intellectual dishonesty or ignorance, assuming ignorance is the more generous option. Therefore, assuming he didn't know is giving him the benefit of the doubt. The reasoning behind your differing assumption is beside the point, even though your reasoning is more likely to be true.
      - PaulDavisThe1st 5y ago
        I think you're missing my point. The TFA's claim is that Drepper didn't get all the issues with DLL Hell. My claim is that Drepper did get all of the issues, and addressed those that were not Windows-specific (e.g. per-process COM servers etc.)
        torstenvl 5y ago
        No. I am not addressing your point because your point is not logically related to the topic under discussion. Specifically, your post said: > DLL Hell was well understood in the mid-90s. I think you need to give him more benefit of the doubt on this point. The substantive question about whether he adequately addressed the issues with dynamic linking is beside the point. Feel free to agree or disagree with the above poster. Not relevant. The post I am responding to is about, given ghoward's position that X did not adequately address topic Y, whether it is "giving X the benefit of the doubt" to further assume (a) X did know about topic Y; or (b) X did not know about topic Y. Because (a) implies dishonesty but (b) merely implies ignorance, "giving X the benefit of the doubt" means you should assume (b) until proven otherwise. If you want to respond to other topics, feel free to hit the reply button below someone else's post.
        PaulDavisThe1st 5y ago
        The point under discussion is this line (and the surrounding text) from TFA: > I don’t think Ulrich Drepper could have foreseen all of the problems with DLL Hell (though there were signs on Windows),
- cesarb 5y ago
  > DLL Hell was well understood in the mid-90s. Also, there are some additional facets of DLL Hell which happened in the Windows of the mid-90s which are not as relevant to Linux. What made DLL Hell so bad there was that installing any random program could replace globally shared libraries, sometimes even with an older version. That is, installing a game could make an unrelated productivity app stop working, because the game helpfully installed newer (or older!) versions of the shared libraries it needed, into the same globally shared directory in which nearly all DLLs lived. It got so bad (even DLLs which came with the operating system were being overwritten) that Microsoft IIRC initially introduced a system which detected when this happened, and replaced the DLLs again with a clean copy it had stashed somewhere else (and later, made these files more directly protected). That's before considering the disaster that is in-process COM servers; presenting a standard "open file" dialog, or doing some printing, is enough to make Windows load arbitrary DLLs into your process (shell extensions and/or printer drivers), and these often don't have the highest code quality. And then there are some things which inject arbitrary DLLs into every process... Compared to that, the dynamic linking issues in the Linux world are much more bearable. You don't see arbitrary programs overwriting the global copy of something like libgtk or openssl or zlib or libc, the only arbitrary dynamic libraries being loaded into a process are things like the NSS ones (usually from a small well behaved set) or plugins from the graphics libraries (also usually from a small well behaved set), and the only dynamic library being injected into every process is the vDSO from the kernel.

PaulDavisThe1st 5y ago

DLL Hell was well understood in the mid-90s. I think you need to give him more benefit of the doubt on this point.

ghoward 5y ago
I'm having a hard time understanding because if DLL Hell was well understood by 2006, it seems I should have given him less benefit of the doubt, but you say I should give him more. Apologies.
torstenvl 5y ago
If someone glosses over an issue, it's either innocent (didn't know about it, didn't understand it) or deceptive (intentionally ignored it). Giving Drepper the benefit of the doubt here means assuming he didn't know or understand the problem he failed to adequately address.
- PaulDavisThe1st 5y ago
  Here is most of the relevant text from TFA: > Ulrich Drepper claims, rightly, that you only need to update a shared library to apply security fixes to all executables that rely on that library. > This is a good thing! It is also a good vision. > Unfortunately, it is only a vision because it’s not the whole story. > As of yet, there is no way to automatically determine if the ABI or API of a shared library changed between updates. This is called DLL Hell. The final two words are a link to the wikipedia page on "DLL Hell". The final sentence of the intro section there states: > DLL Hell is the Windows ecosystem-specific form of the general concept dependency hell. That is, TFA defines "DLL Hell" using a wikipedia page that explicitly states that it is a Windows-specific version of a more general problem. Drepper's article from 2006 fully tackles the general problem, albeit without (as the TFA puts it): "a way to automatically determine if the ABI or API of a shared library changed between updates." Drepper's primary suggestion there is a naming/versioning scheme which describes specifically whether the ABI/API has changed in ways that matter for shared linkage. It's not automatic - that part is true. But is is a solution, widely used in Linux and *nix more broadly. Did Drepper address the Windows specific parts of "DLL Hell". He did not, but that's because "DLL Hell" is Windows specific (as other comments here fully clarify), and he was not writing about how to fix the full scope of that particular nightmare. He likely understood "DLL Hell" as well as anyone, nevertheless.
  - torstenvl 5y ago
    I think you're missing the point. When the only alternatives are intellectual dishonesty or ignorance, assuming ignorance is the more generous option. Therefore, assuming he didn't know is giving him the benefit of the doubt. The reasoning behind your differing assumption is beside the point, even though your reasoning is more likely to be true.
    - PaulDavisThe1st 5y ago
      I think you're missing my point. The TFA's claim is that Drepper didn't get all the issues with DLL Hell. My claim is that Drepper did get all of the issues, and addressed those that were not Windows-specific (e.g. per-process COM servers etc.)
      - torstenvl 5y ago
        No. I am not addressing your point because your point is not logically related to the topic under discussion. Specifically, your post said: > DLL Hell was well understood in the mid-90s. I think you need to give him more benefit of the doubt on this point. The substantive question about whether he adequately addressed the issues with dynamic linking is beside the point. Feel free to agree or disagree with the above poster. Not relevant. The post I am responding to is about, given ghoward's position that X did not adequately address topic Y, whether it is "giving X the benefit of the doubt" to further assume (a) X did know about topic Y; or (b) X did not know about topic Y. Because (a) implies dishonesty but (b) merely implies ignorance, "giving X the benefit of the doubt" means you should assume (b) until proven otherwise. If you want to respond to other topics, feel free to hit the reply button below someone else's post.
        PaulDavisThe1st 5y ago
        The point under discussion is this line (and the surrounding text) from TFA: > I don’t think Ulrich Drepper could have foreseen all of the problems with DLL Hell (though there were signs on Windows),
cesarb 5y ago
> DLL Hell was well understood in the mid-90s. Also, there are some additional facets of DLL Hell which happened in the Windows of the mid-90s which are not as relevant to Linux. What made DLL Hell so bad there was that installing any random program could replace globally shared libraries, sometimes even with an older version. That is, installing a game could make an unrelated productivity app stop working, because the game helpfully installed newer (or older!) versions of the shared libraries it needed, into the same globally shared directory in which nearly all DLLs lived. It got so bad (even DLLs which came with the operating system were being overwritten) that Microsoft IIRC initially introduced a system which detected when this happened, and replaced the DLLs again with a clean copy it had stashed somewhere else (and later, made these files more directly protected). That's before considering the disaster that is in-process COM servers; presenting a standard "open file" dialog, or doing some printing, is enough to make Windows load arbitrary DLLs into your process (shell extensions and/or printer drivers), and these often don't have the highest code quality. And then there are some things which inject arbitrary DLLs into every process... Compared to that, the dynamic linking issues in the Linux world are much more bearable. You don't see arbitrary programs overwriting the global copy of something like libgtk or openssl or zlib or libc, the only arbitrary dynamic libraries being loaded into a process are things like the NSS ones (usually from a small well behaved set) or plugins from the graphics libraries (also usually from a small well behaved set), and the only dynamic library being injected into every process is the vDSO from the kernel.