| > "Caching" is not considered basic rudimentary politeness You don't consider this a truth, I do. By google's standards it is a truth, https://cloud.google.com/web-risk/docs/caching for one example > 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. |
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.