mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
mnutt has quit [Ping timeout: 240 seconds]
mnutt has joined #sandstorm
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
mnutt has quit [Ping timeout: 240 seconds]
mnutt has joined #sandstorm
<TimMc>
Drew has a history of pissing people off, so I'm not surprised that he was banned from the issue tracker "for mysterious reasons". But Google doesn't come across well in that issue discussion.
<Corbin>
Reading https://github.com/golang/go/issues/35699 I'm struck by the degree to which the UA header has turned into an "evil bit"; it seems like lying in the UA header is game-theoretically preferable.
<ocdtrekkie>
It's frustrating because I find the User-Agent such a helpful standard, particularly for non-web-browsers.
cwebber has quit [Read error: Connection reset by peer]
xet7 has joined #sandstorm
<isd>
"this is why we can't have nice things"
<Corbin>
There's an obvious way for the Go community to punish Google, but it only works if the ecosystem is large and diverse, which isn't the case. Go code hosts could deliberately make the Google proxy crawlers slower, forcing Google to allocate exponentially-large amounts of resources or leave those packages uncached. If enough large code hosts participate, then Google would be forced to exclude them, making the proxy worthless.
<isd>
I don't think trying to beat google via resource exhaustion is a particularly good strategy.
<isd>
Though I'm half tempted to see if there's an easy way for the redirect at capnproto.org/go/capnp to block that user agent. Might be annoying, since it's otherwise a static site.
<Corbin>
It's not about exhausting their resources. It's the next-best option after just blocking the crawlers. It sounds like the proxy will report upstream code as unavailable if the crawling action fails. So, don't let it fail, but don't let it use unlimited amounts of bandwidth, either.
* isd
looks at .bashrc
<isd>
I see I have already set GOPROXY=direct
<isd>
Honestly, I think just blocking it and telling users they need to set GOPROXY=direct to use your library is more likely to have an impact.
<isd>
I might set up a rule for zenhack.net/go
<TimMc>
Yeah, just make that part of the installation instructions.
<isd>
exactly
<TimMc>
It's an extremely weird thing that Google is doing here.
<TimMc>
Is there any other language ecosystem like that?
<isd>
I mean, most other language ecosystems just have a centralized repository to begin with
<TimMc>
True. Installing from random Git repos is unusual.
<TimMc>
as part of a package manager
<Corbin>
TimMc: Copying from a recent #plt conversation (which I think forked from an #ocaml discussion?) there are some other languages where one outsized corporate participant distorts the ecosystem: Clojure and PHP come to mind.
<Corbin>
(In #ocaml, folks were arguing about how Jane Street distorts OCaml. I think it's relevant; it's another example of the same pattern.)
<TimMc>
Corbin: Yeah, but the proxying thing?
<TimMc>
I wonder what their goal is. I didn't see a justification in the thread. Do they want to be able to quickly block malicious versions?
xet7 has quit [Remote host closed the connection]
<Corbin>
TimMc: I could point to npm as an example where a community was even more controlled by a single corporation. ISTR that npm changed their tax structure, but I don't know how.