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.
There's actually a solution, it's NostrGit, decentralized git. No single point of failure, and your identity is a public key. You can also just host your git via http on a Tor onion or i2p eepsite to get a public key identity namespace that is also resilient to the operator of your namespace registrar trying to sabotage or subvert you.
Git is decentralized all on it's own. A relation that will not be named had a complete infrastructure failure that destroyed their version control servers as well. Everything was up in a few days pushed from developer laptops.
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.
sanskritical · · focus · HN ↗
throwawayffffas · · focus · HN ↗