Earlier quoted context omitted.
From what I understand, the proxy also helps people make sure that an upstream deleting their GitHub repos doesn't result in builds breaking on new machines that don't have it cached locally. Imagine the problems that could happen if someone new joins your team, runs `go build` and then one of the vital dependencies 404s. The other problem is that it's Google so their perception of "not much traffic" is "biblical flo…
If they change the case on their username on the other hand, the Go ecosystem explodes: https://github.com/sirupsen/logrus/issues/570#issuecomment-3...
Sourcehut will blacklist the Go module mirror
141–150 of 365 posts
Re: Sourcehut will blacklist the Go module mirror
#142Earlier quoted context omitted.
Have to agree in as much banning people with legitimate issues is unhelpful. I was also taken aback when Peter Bourgon, a great programmer and contributor to the go ecosystem was banned from all go channels.
> I was also taken aback when Peter Bourgon, a great programmer and contributor to the go ecosystem was banned from all go channels. Bourgon was frequently helpful and great, but also frequently rude, condensing, dismissive, and generally just unpleasant. I've seen this countless of times first-hand on Slack, Reddit, and Lobsters. I specifically stopped interacting with him long before he was banned. Whether he's a g…
Why not? Why shouldn't we offer more leeway to more valuable contributors?
Re: Sourcehut will blacklist the Go module mirror
#143Earlier quoted context omitted.
> I was also taken aback when Peter Bourgon, a great programmer and contributor to the go ecosystem was banned from all go channels. Bourgon was frequently helpful and great, but also frequently rude, condensing, dismissive, and generally just unpleasant. I've seen this countless of times first-hand on Slack, Reddit, and Lobsters. I specifically stopped interacting with him long before he was banned. Whether he's a g…
> Whether he's a great programmer/contributor not isn't really important here. I don't see why not. Personalities fall on a broad spectrum. Still seems strange to me that the recent broad pushes for more inclusiveness, including neuro-atypicality, does not cover people that inconvenience you personally. > that would chase people out of the community with his behaviour [...] but it did make the Go community a better p…
https://i.kym-cdn.com/photos/images/newsfeed/002/212/873/d5f...
Re: Sourcehut will blacklist the Go module mirror
#144Earlier quoted context omitted.
No. It is much smaller team as far as resources go. Compared to Swift for Apple or Java for Oracle, Go is not strategic bet for Google. There is absolutely no dependency on Go to develop services for Google platform in it. Hell, large number of Google employees spend time on disparaging Go. It does not happen for other company sponsored languages.
Someone in the Go team (rsc, IIRC) commented on how a Google executive came to him in the cafeteria to congratulate him on the launch. It turns out the executive confused him with someone on the Dart or Flutter teams.
Re: Sourcehut will blacklist the Go module mirror
#145From the GitHub issue, by a Googler: > For boring technical reasons, it would be a fair bit of extra work for us to read robots.txt […] This is coming from one of the biggest, richest, most well-staffed companies on the planet. It’s too much work for them to read a robots.txt file like the rest of the world (and plenty of one-man teams) do before hammering a server with terabytes of requests. If this is too much for…
Re: Sourcehut will blacklist the Go module mirror
#146Earlier quoted context omitted.
I think Google should DDoS noone. Not everyone until they opt out.
But it’s not Google DDoSing them, it’s every user downloading packages. Without the proxy it would just be millions of users hammering their servers. Edit: Uh okay, if it's not user traffic then why wasn't the "don't background refresh" not an option?
Doing shallow clones, which are significantly cheaper.
Google is DDoSing them, by their service design. Why a full git clone, why not shallow? Why do they need to do a full git clone of a repository up to a hundred times an hour. It doesn't need that frequency of a refresh.
The likely answer is that the shared state to handle this isn't a trivial addition, it's a lot simpler to just build nodes that only maintain their own state. Instead of doing it on one node and sharing that state across the service, just have every node or small cluster of nodes do its own thing. You don't need to build shared state to run the service, so why bother? That's just needless complexity after all, and all you're costing is bandwidth, right?
That's barely okay laziness when you're interacting with your own stuff and have your own responsibility for scaling and consequences. Google notoriously doesn't let engineers know the cost of what they run, because engineers will over-optimise on the wrong things, but that also teaches them not to pay attention to things like the costs they inflict on other people.
It's unacceptable to act in this kind of fashion when you're accessing third parties. You have a responsibility as a consumer to consume in a sensible and considered fashion. Avoiding this means you're just not costing yourself money through your laziness, you're costing other people who don't have stupid deep pockets like Google.
This is just another way in which operating at big-tech-money scales blinds you to basic good practice (I say this as someone who has spent over a decade now working for big tech companies...)
Re: Sourcehut will blacklist the Go module mirror
#147Earlier quoted context omitted.
I wondered that too, but then I wondered if that's what sourcehut have actually done. I didn't notice any details about how go module mirror will be blocked. Wouldn't the effect on sourcehut users be identical?
> I didn't notice any details about how go module mirror will be blocked. It says in the post they'll check the UserAgent for the Go proxy string and return a 429 code.
Re: Sourcehut will blacklist the Go module mirror
#148Earlier quoted context omitted.
Thanks, that is indeed not the greatest of comments.
[flagged]
You could reasonably agree or disagree with Filippo take, and after quite a bit of discussion it was decided to not deprecate the opengpg[1]. I'm pretty sure that Drew's comment contributed exactly 0% to that decision.
[1]: It was deprecated a two years later as no one stepped up to maintain it, so it bitrotted even further, and there are other (better) 3rd party implementations anyway. Speaking up is nice, actually doing the work is better.
Re: Sourcehut will blacklist the Go module mirror
#149Earlier quoted context omitted.
No. The Go team offered to add sourcehat to a list that would stop background refreshes. It would still allow fetches initiated by end users. The change sourcehat is making is to break end users unless they set some environment variables. I've not seen any explanation about why the solution offered by the Go team was unacceptable. Its weird that that is completely left out of the blog post here.
[flagged]
It's about the clearest example of bad engineering justified by "developer velocity" - developer time is indeed expensive relative to inefficiency for which you don't pay because you externalize it to your users. Clearest, because there are fewer parties affected in a larger way, so the costs are actually measurable.
I do have a dog in this, in a way, because as one of the paying users of sr.ht, I'm unhappy that Google's indifference is wasting sr.ht budget through bandwidth costs.
Re: Sourcehut will blacklist the Go module mirror
#150Earlier quoted context omitted.
But it’s not Google DDoSing them, it’s every user downloading packages. Without the proxy it would just be millions of users hammering their servers. Edit: Uh okay, if it's not user traffic then why wasn't the "don't background refresh" not an option?
> Without the proxy it would just be millions of users hammering their servers. Doing shallow clones, which are significantly cheaper. Google is DDoSing them, by their service design. Why a full git clone, why not shallow? Why do they need to do a full git clone of a repository up to a hundred times an hour. It doesn't need that frequency of a refresh. The likely answer is that the shared state to handle this isn't a…
Huh? I left a few months ago but there was a widely used and well known page for converting between various costs (compute, memory, engineer time, etc).