3 ms·

Go, for some values of "distributed". The vast majority of go packages are hosted on GitHub, but nothing stops anyone from hosting elsewhere and Go has explicit

by zrail 1y ago

Go, for some values of "distributed". The vast majority of go packages are hosted on GitHub, but nothing stops anyone from hosting elsewhere and Go has explicit support for indirection such that anyone can use a vanity domain that happens to point at GitHub or wherever.

shadowgovt 1y ago
Go's one weakness is that the package source is baked into the package data in a not-automatically-fungible way. And if pkg.go.dev ever becomes a threat vector, we're gonna have a bad time. dselect solved this ages ago with its mirrors, but at some point it seems every major package manager decided that was unnecessary complexity ("why bother? It's not like a package repo just goes down") and left it out when they built their alternatives. So, from time to time, when a domain in the Internet goes sour it's a huge problem (whereas were a Debian mirror to go sour I'd add like one line to a config file and never notice the issue again, assuming dpkg doesn't automatically identify the problem and route around it).
- binary132 1y ago
  Depending on your definition of “threat” I’d definitely consider it a threat vector already.
cortesoft 1y ago
Isn't this the same as ruby gems, then? You can use alternative sources in your Gemfile pretty easily.
- zrail 1y ago
  Sort of. Go packages have the source baked into the package name. It would be like needing to say `require "github.com/sparklemotion/nokogiri"` rather than what we do today, `require "nokogiri"` and then if you want to change the source wrapping `gem "nokogiri"` in an alternate `source` block.
  - binary132 1y ago
    This is why Go’s dependency management doesn’t really qualify as “decentralized” in my mind. A decentralized provider (IPFS?) could possibly be implemented for some packages, but most of its packages are locked into centralized hosting and URLs today. Some of them sometimes being hash-identified and cache-proxied doesn’t help the case much and IMO the centralized proxying by default actually hurts it.
    - madeofpalk 1y ago
      Depends what you're trying to decentralise. Go has no centralised registry. The collective of all the packages are decentralised, but each individual package is centralised.
bananapub 1y ago
go is comically un-distributed in practice: - almost every package is hosted on GitHub and that url is baked in to consumers of those packages - the go proxy: https://flak.tedunangst.com/post/what-the-go-proxy-has-been-doing https://flak.tedunangst.com/post/what-the-go-proxy-has-been-...

by zrail 1y ago

shadowgovt 1y ago

Go's one weakness is that the package source is baked into the package data in a not-automatically-fungible way. And if pkg.go.dev ever becomes a threat vector, we're gonna have a bad time. dselect solved this ages ago with its mirrors, but at some point it seems every major package manager decided that was unnecessary complexity ("why bother? It's not like a package repo just goes down") and left it out when they built their alternatives. So, from time to time, when a domain in the Internet goes sour it's a huge problem (whereas were a Debian mirror to go sour I'd add like one line to a config file and never notice the issue again, assuming dpkg doesn't automatically identify the problem and route around it).

binary132 1y ago
Depending on your definition of “threat” I’d definitely consider it a threat vector already.

cortesoft 1y ago

Isn't this the same as ruby gems, then? You can use alternative sources in your Gemfile pretty easily.

zrail 1y ago
Sort of. Go packages have the source baked into the package name. It would be like needing to say `require "github.com/sparklemotion/nokogiri"` rather than what we do today, `require "nokogiri"` and then if you want to change the source wrapping `gem "nokogiri"` in an alternate `source` block.
- binary132 1y ago
  This is why Go’s dependency management doesn’t really qualify as “decentralized” in my mind. A decentralized provider (IPFS?) could possibly be implemented for some packages, but most of its packages are locked into centralized hosting and URLs today. Some of them sometimes being hash-identified and cache-proxied doesn’t help the case much and IMO the centralized proxying by default actually hurts it.
  - madeofpalk 1y ago
    Depends what you're trying to decentralise. Go has no centralised registry. The collective of all the packages are decentralised, but each individual package is centralised.

bananapub 1y ago

go is comically un-distributed in practice: - almost every package is hosted on GitHub and that url is baked in to consumers of those packages - the go proxy: https://flak.tedunangst.com/post/what-the-go-proxy-has-been-doing https://flak.tedunangst.com/post/what-the-go-proxy-has-been-...