[tptacek]

How exactly does this workaround degrade service for DeVault's Go users? I'm not saying it doesn't; I'm saying nobody has given a simple explanation of what the impact would actually be, except for some people who have given clearly false explanations.

It's OK to just not know, but if you don't know, it's weird to have strong opinions about it.

[voxtech]

I'm more weirded out by the fact that you believe google is performing this DDOS for no actual benefit and are choosing to defend it anyway.

[tptacek]

Is that an answer to some other question I asked? It doesn't seem to be responsive to what I just wrote.

I feel like what I'm sticking up for here is the practice of software development. Building an automated system that generates unexpectedly unwelcome load on someone else's service is... not exactly front-page news? It happens basically all the time? The idea that because the Go team is sponsored by Google, nothing like this should ever happen seems deeply unrealistic. "We can push a button to make this stop happening; the tradeoff is that other hosting services that don't care about this load might currently have fresher cache entries [whatever that means]" seems like a perfectly cromulent response.

He should just tell them to push the button. If you think he shouldn't, you should be able to say why.

I do have a mild rooting interest here: I think the Go module proxy is pretty neat, and does something interesting for the security of the ecosystem. DeVault disagrees. That's fine, disagreement keeps things interesting.

[kcartlidge]

> He should just tell them to push the button. If you think he shouldn't, you should be able to say why.

Accepting that Drew should get them to just push the button is accepting that it is the responsibility of each victim individually to cope with the abusive load being sent their way by engaging directly with their abuser. Rather than the sender, who is truly the one responsible, fixing it for every target by reducing their polling at source.

[voxtech]

More importantly, there is no threshold of usefulness where continuing the behavior is justified.

If the behavior is unimportant enough that drew should accept eliminating it, then its value does not justify the load.

If the behavior is important enough to justify the load, then eliminating it is no solution.

[tptacek]

I don't understand how this logic is meant to hold. The behavior can be of enough value to justify it where the cost to source hosts is low, but not of enough value to justify it for all hosts. Which is where we are now.

It feels like some comments here are trying to reconstruct what happened axiomatically purely from comments on the thread, without any empirical input from, like, how the Go module proxy actually works, and ending up in weird places as a result.

[kcartlidge]

Personally I'm trying to keep it tied down to an issue of responsibilities.

The abuser of resources should stop abusing. It isn't the fault of the victims and they shouldn't each individually need to address it. Stop the issue at source for everyone by stopping being anti-social/parasitical on the use of resources through excessive polling. I think that's the extent of my own argument here.

[jum1p]

> How exactly does this workaround degrade service for DeVault's Go users?

I think you don't always get the latest stuff due to caching or so.