201–210 of 225 posts
I'm wondering how much load this is sending to github. Github has a ton of golang packages, including many non-popular ones that wouldn't otherwise get much traffic. A refresh job running full clones many times a day must be burning up bandwidth and compute over there as well. I suppose it's a drop in the bucket for Github's usage, but it's got to be a huge number.
The fact that a programming language calls home to by Google by default should make it a non-starter for most sane developers. The fact that it calls home so it can DDoS other sites is low-key hilarious. And you'd think Google would know how to like... operate an efficient CDN, perhaps? Like, if this was managed by a competent company, you'd think this service would be akin to putting Cloudflare in front of your serv…
The website focused on the programming language, was basically in Plan 9 style, no nonsense, the programming language sane and very cross-platform.
Things changed. Now one has to scroll through big company brands and marketing blabla to even get a glimpse of the language, there's big Google logos, everything is JavaScript heavy, really well written[1] tutorials got hidden and there is now tutorials with mistakes and bad code that got pointed out[2], but are "won't fix", a programming language where people used to admit that new() is kind of redundant and maybe wasn't the idea tries to pull in random programming language features[3]. On top of that it was a programming language starting out to embrace the fact that there are many different operating systems officially supporting even Plan 9, DragonFly, etc., but after already having started to hollow that out creating tiers it seems they now completely want to shift away from that[4]. And then of course there's things like the module proxy causing issues.
People got their hopes up, but it almost feels like Google is pulling an embrace, extend, extinguish on Go - or at least its original design. But I still hope that I am just seeing things that aren't there.
[1] https://go.dev/doc/effective_go
[2] https://groups.google.com/g/golang-dev/c/kC7YZsHTw4Y/m/u0_d9...
[3] https://github.com/golang/go/issues/21498#issuecomment-11322...
Earlier quoted context omitted.
In what way would it be "far from great"?
Well, why have that proxy/functionality in first place if the best option is to disable it?
It's OK not to know the specifics of what this is about, but it's weird to have strong opinions about it if you don't.
Regardless of whether or not Drew is abrasive (I've never dealt with him so have no opinion), this is on Google . If a single service (Go's module crawler) is doing this to multiple third parties (and it is, by design) then requiring Drew to implement a workaround is the same thing as relying on every (relevant to the issue) third party to do the same thing. Which is bad design. This should be fixed at source or swit…
Can you help me understand the problem with the workaround, which is precisely to have Google's proxy not excessively poll DeVault's service? It really seems like DeVault's real argument here isn't about the impact of this on his service, but that he doesn't like the design of the proxy. He has a lot of standing to complain about impacts on his service, but essentially no standing to complain about designs he finds s…
Earlier quoted context omitted.
Self hosting costs money, for this one user it would seem the options of blocking or other options are more tenable If money was a problem, I'd expect this individual to ha e rectified it on their end
So tell me why do people use DDoS protection? It's just money. If you run a server you should be able to eat all the cost! Seriously do you follow through what your arguments actually mean if applied in general?
Should every language be responsible for paying the bandwidth bills for dependencies?
You might look at the most recent comment from the Go team on the issue, there have been no additional requests or events since they last resolved it for both of the effected parties
Earlier quoted context omitted.
Can you help me understand the problem with the workaround, which is precisely to have Google's proxy not excessively poll DeVault's service? It really seems like DeVault's real argument here isn't about the impact of this on his service, but that he doesn't like the design of the proxy. He has a lot of standing to complain about impacts on his service, but essentially no standing to complain about designs he finds s…
You shouldn't have to opt-out of a DOS.
From https://github.com/golang/go/issues/44577#issuecomment-85107... > Yesterday, GoModuleMirror downloaded 4 gigabytes of data from my server requesting a single module over 500 times (log attached). As far as I know, I am the only person in the world using this Go module. From https://github.com/golang/go/issues/44577#issuecomment-78924... > yes we make a fresh clone every time I like golang as a developer, but thi…
From https://github.com/golang/go/issues/44577#issuecomment-11378... > Anyone who's receiving too much traffic from proxy.golang.org can request that they be excluded from the refresh traffic, as we did for git.lubar.me. Nobody asked for sr.ht be added to the exclusion set, so as far as it's concerned nothing has changed.
Earlier quoted context omitted.
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.
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
Earlier quoted context omitted.
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…
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).