3 ms·

As far as I am concerned, the only (almost) valid point they made is this one: > When you have an internally-maintained piece of code, it does not benefit from

As far as I am concerned, the only (almost) valid point they made is this one: > When you have an internally-maintained piece of code, it does not benefit from the incoming bugfixes that an external dependency might enjoy. But, even this one is not always good. Your internal code might not have the bugs that would affect your program, might be less efficient due to doing things that are not relevant to your program, and you might be able to fix the bug more easily in your own program than you would with an external dependency, especially if they do not fix it in time. There is also vulnerabilities, and other stuff. Furthermore, the external dependencies might make the program larger than it should be. There are many good reasons to avoid external dependencies.

ironmagma 2y ago
Key word is might. Yes, it’s a game of probability, and also a game of “is it, though?” I would posit that something maintained by the wider public is less likely to contain bugs than something maintained by a smaller/less varied group (you or your company). Yes, you can point to xz-utils as an example of the ineffectiveness of groups at catching attacks, but it’s also famous because it’s exceptionally bad and probably not normal.
- zzo38computer 2y ago
  Whether or not that is true (and what kind of bugs) might depend on the specific software. Furthermore, sometimes changes to external dependencies may introduce bugs (which might or might not be malicious; both kinds can and do happen), which might be fixed in a later version but that might take some time. Another alternative is that if the dependency is only one or two files, you can just make your own copy of them and use those instead, and maintain them by yourself, reviewing any changes to the official version and applying them to your own if you consider them necessary; this might also allow you to fix bugs that haven't been corrected and to omit features that you do not need. Another reason you might wish to avoid external dependencies is if they cannot be packaged together with the software; if they come from a different source, then there is the possibility that the external source may be no longer available (which might or might not be malicious; again, both kinds can and do happen). (If they are not very large and only one or two files, then you can just include it with your software.) If your software uses external dependencies, you might also specify exact versions by both version numbers and cryptographic hashes. The use of cryptographic hashes will mitigate some types of attacks as well as to potentially allow finding other copies if the source that you got it from is no longer available. Another issue, depending on the kind of dependencies, may be interfaces with other software (possibly including the operating system), in which case there may potentially be multiple possible implementations, and the system administrator may wish to install their own. In the package manager for operating system design that I had considered, this is also an issue that I had considered. A package can have multiple identifiers of any kinds. Additionally, there are other features of the operating system which can help many things. Hopefully, these things will be able avoid many kind of problems.

ironmagma 2y ago

Key word is might. Yes, it’s a game of probability, and also a game of “is it, though?” I would posit that something maintained by the wider public is less likely to contain bugs than something maintained by a smaller/less varied group (you or your company). Yes, you can point to xz-utils as an example of the ineffectiveness of groups at catching attacks, but it’s also famous because it’s exceptionally bad and probably not normal.

zzo38computer 2y ago
Whether or not that is true (and what kind of bugs) might depend on the specific software. Furthermore, sometimes changes to external dependencies may introduce bugs (which might or might not be malicious; both kinds can and do happen), which might be fixed in a later version but that might take some time. Another alternative is that if the dependency is only one or two files, you can just make your own copy of them and use those instead, and maintain them by yourself, reviewing any changes to the official version and applying them to your own if you consider them necessary; this might also allow you to fix bugs that haven't been corrected and to omit features that you do not need. Another reason you might wish to avoid external dependencies is if they cannot be packaged together with the software; if they come from a different source, then there is the possibility that the external source may be no longer available (which might or might not be malicious; again, both kinds can and do happen). (If they are not very large and only one or two files, then you can just include it with your software.) If your software uses external dependencies, you might also specify exact versions by both version numbers and cryptographic hashes. The use of cryptographic hashes will mitigate some types of attacks as well as to potentially allow finding other copies if the source that you got it from is no longer available. Another issue, depending on the kind of dependencies, may be interfaces with other software (possibly including the operating system), in which case there may potentially be multiple possible implementations, and the system administrator may wish to install their own. In the package manager for operating system design that I had considered, this is also an issue that I had considered. A package can have multiple identifiers of any kinds. Additionally, there are other features of the operating system which can help many things. Hopefully, these things will be able avoid many kind of problems.