Live data from Hacker News

Sourcehut will blacklist the Go module mirror

sourcehut.org

251–260 of 365 posts

Re: Sourcehut will blacklist the Go module mirror

#251

Earlier quoted context omitted.

> Google has quite a reputation for wrongfully banning people from things. Extraordinary claims require extraordinary evidence.

Here's some evidence: https://news.ycombinator.com/item?id=3803568 https://news.ycombinator.com/item?id=15066518 https://news.ycombinator.com/item?id=19124324 https://news.ycombinator.com/item?id=20826618 https://news.ycombinator.com/item?id=20841586 https://news.ycombinator.com/item?id=21247759 https://news.ycombinator.com/item?id=24791357 https://news.ycombinator.com/item?id=24965432 https://news.ycombinator.com/it…

None of that bears any relation to what happens in the Go community.

Google is not a monolithic entity. The Go team operates pretty much independently from gmail and other stuff. Yes, there is a problem with Google randomly disabling accounts, but this doesn't really extend to Go, who make their own decisions on who to ban or not, and which are all manual. Just as you can comment on, say, github.com/facebook/zstd without a Facebook account, you can also comment on github.com/golang/go without a Google account.

Re: Sourcehut will blacklist the Go module mirror

#252
post #125

Earlier quoted context omitted.

> personal vendetta This is a weird definition of "personal", like PGP kicked his dog or something. The arguments he makes against it are detailed and the agreement of most working cryptographers, even if they don't agree with his specific deprecation schedule. Some people would call that "good engineering".

“Good engineering” would be to meticulously develop and standardize a replacement before idealistically purging the world of alleged “bad software”. Since this endeavor has yet to be undertaken, PGP it is. Good engineers understand this reality. Look, you can make solid arguments till you are blue in the face about why PGP is unclean and unfit for modern cryptography. And you can be 100% right. But that doesn't mean…

> rip it out of existence

Come the fuck off this "mature personality" shit if you're going to write like this. He proposed freezing a module no one wanted to maintain in a library specifically meant to host stuff with weaker compat guarantees, he didn't hop in a DeLorean and kill Zimmermann's grandpa.

Meanwhile, the critical project Drew insisted he keep it for is... deprecated and unmaintained!

Re: Sourcehut will blacklist the Go module mirror

#253
post #215

Earlier quoted context omitted.

Virtually nobody uses PGP, and it is not at all pivotal. It is one of the least important widely-known cryptosystems on the Internet; like the book "Applied Cryptography", it has a cheering section because of the era in which it was released, and a generation of lay-engineers has taken PGP as a synecdoche for all privacy cryptography. It is also badly broken and has an archaic design. Most notably: Filippo had nothin…

I am no cheering fan, for sure, but I think it's disingenuous to say PGP is one of the least important systems on the internet. Debian package distribution, notably, depends rather pivotally on PGP to ensure authenticity. Keybase uses PGP as it's root trust mechanism. There are plenty of email services that use PGP to secure messages. I've even come across some recent (as in the last few years) startups using PGP to…

Does Debian depend on Go's official non-stdlib to support PGP? (No, it does not.)

> So why haven't they?

They are: https://wiki.debian.org/Teams/Apt/Spec/AptSign

Mandatory aptsign by 2025 and GPG tentatively removed by 2027: https://gemmei.ftp.acc.umu.se/pub/debian-meetings/2022/DebCo...

> my argument is neither for nor against PGP... I'm tired of hearing about how much PGP sucks without also hearing about the solution.

If you're not actually paying attention to what happens in the world around you, your argument is for PGP.

Re: Sourcehut will blacklist the Go module mirror

#254

Earlier quoted context omitted.

> 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…

In general, humans don't like working with assholes. Once the asshole limit is reached, we shun people who are assholes. https://i.kym-cdn.com/photos/images/newsfeed/002/212/873/d5f...

This could be rephrased as "people who are different than me" and be just as accurate. It's not a good look.

Re: Sourcehut will blacklist the Go module mirror

#255

From 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…

[deleted]

Re: Sourcehut will blacklist the Go module mirror

#256
post #209

The Go team has been making progress toward a complete fix to this problem. Go 1.19 added "go mod download -reuse", which lets it be told about the previous download result including the Git commit refs involved and their hashes. If the relevant parts of the server's advertised ref list is unchanged since the previous download, then the refresh will do nothing more than the ref list, which is very cheap. The proxy.go…

Thanks for the insight, Russ. Would you comment on what the potential consequences of opting out of background refreshes would be? Could there be any adverse effects for users?

Opting out of background refreshes would mean that fetching a module version that (1) no one else had fetched in a few days and (2) does not use a recognized open-source license might not be in the cache, which would make 'go get' take a little extra time while the proxy fetched it on demand. The amount of time would depend on the size of the repo, of course.

The background refresh is meant to prefetch for that situation, to avoid putting that time on an actual user request. It's not perfect but it's far less disruptive than having to set GOPRIVATE.

Re: Sourcehut will blacklist the Go module mirror

#257
post #245

Earlier quoted context omitted.

This reminds me a bit of a disfunctional relationship: clearly Sourcehut wants Google to stop DDoS their servers; clearly Google don’t actually want to DDoS Sourcehut, but Sourcehut also doesn’t want to ask Google to stop, and Google also want to be asked to stop. And so nothing gets done. The question is who will swallow their pride first: Sourcehut or Google.

This isn't true. Sourcehut reported a bug, and since the bug is somewhat involved to fix entirely, we asked what the impact of the bug is to them and offered to make a custom change for the site in the interim. The impact matters: the appropriate response is different for "I saw this in my logs and it looks weird but it's not bothering me" versus "this is causing serious problems for my site". We have been getting mi…

Your comment in this thread is the first time I've seen anyone mention that it was being worked on since... June 2021? This despite repeatedly raising the issue up until I was banned without explanation. I was never told, and still don't know, what disabling the refresh entails, the ban prevents me from discussing the matter further, and I was under the impression that no one was working on it. We have suffered a serious communication failure in this incident. That said, I am looking forward to your follow-up email and seeing this issue resolved in a timely and amicable manner.

Re: Sourcehut will blacklist the Go module mirror

#258

Earlier quoted context omitted.

This is obviously untrue because we know that Google does write significant portions of its backend in Go and that Google derives ~0% of its revenue from Go (the very definition of a side project). My guess is that you're assuming that a side project for Google is the same as a side project for a lone developer or a small team, which is (pretty obviously, IMHO) untrue.

> that Google derives ~0% of its revenue from Go AdWords is mainly written in Go. YoutTube is mainly written in Go. Just because they have strategic reasons for not directly monetizing Go doesn't make it a side project more than any other internal tooling. It's core to their ability to pull in revenue now. If they were somehow immediately deprived access to Go, the company would go under. That's how you know it's not…

> AdWords is mainly written in Go. YoutTube is mainly written in Go

Can you source these claims? Last I checked, YouTube was primarily written in Python, and I doubt that's changed dramatically in the intervening years given the size of YouTube. I assume there's some similar thing going on for AdWords.

> Just because they have strategic reasons for not directly monetizing Go doesn't make it a side project more than any other internal tooling.

Agreed, but all internal tooling is a side project pretty much by definition.

> It's core to their ability to pull in revenue now.

No, it's just the thing that they implemented some of their systems in. I'm a big Go fan, but they could absolutely ship software in other languages for a marginal increased operational overhead.

> If they were somehow immediately deprived access to Go, the company would go under. That's how you know it's not a side project.

I don't know what it means to be "deprived access to Go", but this is a pretty absurd definition of "side project" since it applies to just about everything Google does and a good chunk of the software Google depends on whether first party or third party (Google depends much more strongly on the Linux Kernel; that doesn't mean contributing to the Linux Kernel is Google's primary business activity). It seems you have a bizarre definition of "side project" which hinges on whether or not a business can back out of a given technology on a literal moment's notice irrespective of how likely it is that said technology becomes unavailable on that sort of timeline, and that these unusual semantics are at the root of our disagreement.

Re: Sourcehut will blacklist the Go module mirror

#259
post #209

The Go team has been making progress toward a complete fix to this problem. Go 1.19 added "go mod download -reuse", which lets it be told about the previous download result including the Git commit refs involved and their hashes. If the relevant parts of the server's advertised ref list is unchanged since the previous download, then the refresh will do nothing more than the ref list, which is very cheap. The proxy.go…

Why does the Go team and/or Google think that it's acceptable to not respect robots.txt and instead DDoS git repositories by default, unless they get put on a list of "special case[s] to disable background refreshes"?

Why was the author of the post banned without notice from the Go issue tracker, removing what is apparently the only way to get on this list aside from emailing you directly?

Do you, personally, find any of this remotely acceptable?

Re: Sourcehut will blacklist the Go module mirror

#260

From 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…

Is the source code of the service behind proxy.golang.org actually open-source?
Post reply on HN