This is hiding in the obfuscation of being overly specific. The problem is general. To name a package, one must be in a namespace of some sort. As the universe does not provide any sort of abstract ambient "namespace" we can all appeal to, all namespaces are human constructs. As human constructs, they may fail.
In this terminology, the article basically amounts to saying "This namespace can fail! The solution is, use another!"
But that doesn't get you anywhere, because the new namespace can fail too. In fact it is almost certain that it will fail sooner than "github.com's DNS and hosting" as a namespace.
There is no solution where you tie your software release to a namespace that can't fail because there is no namespace that can't fail. It doesn't matter if your favorite language uses DNS or has a centrally blessed repository or if it distributes a blessed list of package names with the language itself or anything else. The namespace can fail.
Therefore, the only thing you can really do is be resilient against failures, and in a lot of ways, the only practical solution to resilience is just to assume that if, in the future, someone has problems getting a package due to a namespace failure, they will not helplessly disintegrate into a puddle of tears while your code is lost forever, but that the future person will instead solve this perfectly solvable problem.
The article doesn’t mention any of these namespaces failing as the major issue… he is referring to the challenge of transferring hosting providers, which could be done for various reasons.
That is a failure; the old namespace no longer meets your needs. My point is abstracted over all of that. There is no namespace solution where that can't possibly happen. Switching from one solution that has problem X (and more generally than the article describes) to another that still has problem X isn't a solution, and given that problem X can't be solved, that means there is no solution. In the interests of not spamming replies, this is also my reply to
dcreager.
Yes, but the solution differs. As the author says — updating DNS entries can be considerably less complicated than migrating libraries and their references
In this example, the old namespace is perfectly fine. The issue is the hosting provider. The point is that you can (and probably should) decouple the namespace from the hosting provider.
jerf · · focus · HN ↗
In this terminology, the article basically amounts to saying "This namespace can fail! The solution is, use another!"
But that doesn't get you anywhere, because the new namespace can fail too. In fact it is almost certain that it will fail sooner than "github.com's DNS and hosting" as a namespace.
There is no solution where you tie your software release to a namespace that can't fail because there is no namespace that can't fail. It doesn't matter if your favorite language uses DNS or has a centrally blessed repository or if it distributes a blessed list of package names with the language itself or anything else. The namespace can fail.
Therefore, the only thing you can really do is be resilient against failures, and in a lot of ways, the only practical solution to resilience is just to assume that if, in the future, someone has problems getting a package due to a namespace failure, they will not helplessly disintegrate into a puddle of tears while your code is lost forever, but that the future person will instead solve this perfectly solvable problem.
mfro · · focus · HN ↗
jerf · · focus · HN ↗
mfro · · focus · HN ↗
bloppe · · focus · HN ↗