4 ms·

crates.io and npmjs.org don't rely on individuals maintaining a paid subscription for the packages to continue to exist. If my package is at example.org/pkg/my

crates.io and npmjs.org don't rely on individuals maintaining a paid subscription for the packages to continue to exist. If my package is at example.org/pkg/mypkg and I stop paying for my domain name for any number of reasons then that package is essentially lost.

Kamq 3y ago
Neither does github. Any package at github.com/user/package (which is a lot of them) has this property. With the bonus that if github does go down, you can redirect it to another mirror of the package if the maintainer puts one up (or you can vendor early, but that's an option for everything).
- lexicality 3y ago
  The article isn't talking about GitHub though. It's talking about people who self host packages on their own domain.
  - Kamq 3y ago
    It's talking about domains going down in general as far as I can tell. People with their own domain are just much more likely for it to happen. It seems you have two specific options. Centralize on a big company's url, which you can use in go via sticking to github.com (and a couple other domains) packages as well as js/rust/java/etc. Decentralize it and have to worry about constant low-level package rot, but not be able to have any individual domain take out all of your dependencies, which you can only really do in go (or languages like C where git submodules are a fairly standard form of dependency management). There is a tradeoff of having a single point of failure in the first example in exchange for increased reliability during normal operations, and in the second example, you're much more likely to be hit by package rot, but you're significantly less vulnerable to your entire dependency tree being wiped out. This is the tradeoff I'm talking about.
Thaxll 3y ago
It woudn't be no, since Google cache almost all public packages. By default go mod fetch packages from Google proxy/cache. https://sum.golang.org/ https://sum.golang.org/ https://index.golang.org/index https://index.golang.org/index
- lexicality 3y ago
  Perhaps users can still install it, but the maintainer has lost control over the package and can't push updates or fixes. Additionally, as the article points out, a new person may now have taken control over the package. Doesn't sound like a good situation to me.

Kamq 3y ago

Neither does github. Any package at github.com/user/package (which is a lot of them) has this property. With the bonus that if github does go down, you can redirect it to another mirror of the package if the maintainer puts one up (or you can vendor early, but that's an option for everything).

lexicality 3y ago
The article isn't talking about GitHub though. It's talking about people who self host packages on their own domain.
- Kamq 3y ago
  It's talking about domains going down in general as far as I can tell. People with their own domain are just much more likely for it to happen. It seems you have two specific options. Centralize on a big company's url, which you can use in go via sticking to github.com (and a couple other domains) packages as well as js/rust/java/etc. Decentralize it and have to worry about constant low-level package rot, but not be able to have any individual domain take out all of your dependencies, which you can only really do in go (or languages like C where git submodules are a fairly standard form of dependency management). There is a tradeoff of having a single point of failure in the first example in exchange for increased reliability during normal operations, and in the second example, you're much more likely to be hit by package rot, but you're significantly less vulnerable to your entire dependency tree being wiped out. This is the tradeoff I'm talking about.

Thaxll 3y ago

It woudn't be no, since Google cache almost all public packages. By default go mod fetch packages from Google proxy/cache. https://sum.golang.org/ https://sum.golang.org/ https://index.golang.org/index https://index.golang.org/index

lexicality 3y ago
Perhaps users can still install it, but the maintainer has lost control over the package and can't push updates or fixes. Additionally, as the article points out, a new person may now have taken control over the package. Doesn't sound like a good situation to me.