3 ms·

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

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),
        torstenvl 5y ago
        I'm pretty sure I know what I replied to, and it wasn't that. If you want to go get into some grary internet argument with someone else about that, feel free, but it's off-topic in reply to my comment. Thanks.
        5y ago

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),
      - torstenvl 5y ago
        I'm pretty sure I know what I replied to, and it wasn't that. If you want to go get into some grary internet argument with someone else about that, feel free, but it's off-topic in reply to my comment. Thanks.
        5y ago