You didn't answer my question. What's the problem with the Go team's workaround? I get that DeVault would like to redesign the Go modules system to suit his own preferences, but that's not on the table.
The issue isn't the Go module system but rather their proxy which is not part of Go and should respect server resources but doesn't. The workaround makes any 3rd party host for go modules a bad choice as packages will always be stale.
The issue has nothing to do with DD other than him raising the issue and being ignored. The fault is with google.
What would be the problem with the go team doing a quick `git ls-remote` instead of jumping to a full clone? All it would take is tracking the last `ls-remote` result in any of the Google's many options for databases, and only doing a clone when the remote updates.
Maybe there's no problem? It's totally fair to critique the design of the current module proxy. The odds of them developing precisely the right proxy were low; of course we'll be able to come up with things they can do better. That's how open source works.
It's when we turn this into a morality play that we go off the rails.
Considering they don't want caching, la what is considered basic rudimentary politeness, (and noting that the change increased traffic, so the proxy was intentionally doing busywork that no-one wanted or needed), The odds of them developing an unacceptable proxy were 100%
Its akin to putting up an open exploitable DNS resolver in 2022 despite, with 2 seconds of research, the entire world telling you not to do that
no one needs to full clone 2 times a minute just to check if a security update exists
one of the top money generating machines does not need a devil's advocate
Yeah so basically none of this is true? "Caching" is not considered basic rudimentary politeness, and what they did is not at all like putting up an "open exploitable DNS resolver" (also: putting up an "open exploitable DNS resolver" is pretty much still an industry norm). The "money generating machines" stuff doesn't add to the credibility of this argument.
I get that you feel like you could design a better Go module proxy. It would be weird if you couldn't, because you have the benefit of seeing what happened when we deployed this one†. Congratulations? It's an achievement, I guess?
For my part, I'd be thrilled if just a single person could articulate exactly what the impact to DeVault's code hosting service would be if he took the Go project's offer up on just not having them clone modules hosted on his service so often. Anybody at all, if you could just explain what the problem would be here, I'd be forever grateful.
† (to wit: Go got a lot better, and apparently just 2 source hosts on the entire Internet had a problem with it, one of whom was fixed directly and the other of whom is apparently still mulling whether they want to burn the extra bandwidth for a cacheing benefit that literally nobody on the Internet seems to be able to describe).
> I get that you feel like you could design a better Go module proxy.
I add "sleep 1" at minimum to all my scraping loops, and refuse to use clients that don't keepalive and cache (if I'm hitting the same endpoint), I've done this always, so yes I could have designed a better proxy today, and a year ago, and two years ago, and three years ago, et, al.
> Money generating
They can pay people, I'm not doing it for free for a language I don't use
> if he took the Go project's offer up on just not having them clone modules hosted on his service so often.
Do you know that he hasn't tried? considering how well google responds to emails
Some people have principles that you might not understand, I too would not ask someone to not DDoS me, because I feel that is an absurd request.
So not a impact to the technical aspects but to the administrative aspects. People are paying devault to run a service as devault would, it would be improper for him to not run the service as expected of him.
> burn the extra bandwidth for a cacheing benefit that literally nobody on the Internet seems to be able to describe
bandwidth and CPU time both cost money
- - -
There are alternative approaches that have existed before 1.16, Deno with its pull once then pull only when told to approach, has not had a crisis of security, Every other language works on demand, NPM at most checks a dedicated security issues API designed for mass consumption. These things existed, none of them were referenced.
Do you know that he hasn't tried? considering how well google responds to emails
You can't reasonably build an argument by just making stuff up. Maybe, against all evidence, Google offered to stop hitting sr.ht with Go proxy cache refresh requests and then ignored DeVault when he took them up on it. But I'm not required to assume that very weird situation is what actually happened.
The issue has nothing to do with DD other than him raising the issue and being ignored. The fault is with google.