10 ms·

> In the meantime, if you would prefer, we can turn off all refresh traffic for your domain while we continue to improve this on our end. That would mean that t

> In the meantime, if you would prefer, we can turn off all refresh traffic for your domain while we continue to improve this on our end. That would mean that the only traffic you would receive from us would be the result of a request directly from a user. This may impact the freshness of your domain's data which users receive from our servers, since we need to have some caching on our end to prevent too frequent fetches. https://github.com/golang/go/issues/44577#issuecomment-856928441 https://github.com/golang/go/issues/44577#issuecomment-85692... > "EFAIL" is an alarmist puff piece written by morons to slander PGP and inflate their egos. [...] https://github.com/golang/go/issues/30141#issuecomment-464278183 https://github.com/golang/go/issues/30141#issuecomment-46427... Disclosure: I was on the Go team at Google until earlier this month. Dealing with DeVault's bad faith arguments is one of the few things I won't miss of that job.

reidrac 4y ago
So what is your opinion on the proxy behaviour then? I know is not like knowing what Google thinks about this, but I'm curious about how something like what is described in the post is allowed to happen.
- striking 4y ago
  I would be surprised if their opinion differs from that of the first link they sent.
cookiengineer 4y ago
How are his arguments in bad faith if he is the one that gets DDoSed by your software for over a year, and still tries to be helpful? Not sure if you realize the absurdity of this, but he has to pay traffic and server costs. Like everyone else, except probably Google as it seems!? I mean, you didn't even consider implementing a simple fetch of an already cloned repository in your mirroring server code. So yeah, I'd argue that the bad faith part is actually justified.
- rfoo 4y ago
  > and still tries to be helpful "Assuming everyone else have exactly same design choice and architecture as yourself, making suggestion on this ground and calling other people crazy because they can't implement what you suggest them to do" is not trying to be helpful. Well, or maybe I'm just frustrated reading his repeated "please keep a copy 'locally' somewhere and run git fetch". Just like how I'm frustrated arguing with him on HN about whether sending patch to mail list is better than GitHub pull request. Don't get me wrong, I understand this is a real Google-scale system v.s. individual code hosting website issue, I just don't see how his "please stop being Google and instead try my works-fine-on-one-box solution" take is helpful.
  - ocdtrekkie 4y ago
    Cloudflare manages to cache things and then serve them to lots of people, without having to request the same content 50 times an hour. Maybe Google should move some of their services over to a better content delivery platform? o.O This is a scenario where anyone who isn't a Googler can see that "being Google" is not a justification for bad engineering. Do better.
  - cycomanic 4y ago
    I often don't agree with DeVaults opinions, however the design decision here is actually costing other people real money and I have not seen a convincing argument why it is necessary. Instead they acknowledge it's an issue, but then continue that behavior for nearly a year, which IMO shows complete disregard for smaller services or individuals hosting their own repositories.
  - thaway2839 4y ago
    Suggesting ideas is not the same as assuming everyone else should have the exact same design choice and architecture. The problem is that the actual issue owner on the Google side does not appear to have any solutions (or is burying solutions because they may be too complex). It's pretty clear that the issue owner agrees there is something wrong here. That's why the issue is kept open and their only reason for not fixing it is that it's a complicated fix which requires effort. As a workaround, they offer Drew the opportunity to essentially disable his service from being used as a useful source of Go modules.
generalizations 4y ago
I see the fairly civil communication you had with Drew in the first link, but your inclusion of the second (given it's an unrelated issue) just feels like you're throwing mud in order to minimize the technical concerns he raised. It seems like the only solution suggested there is one that makes the "small fish" service less useful as a go repository. I'm not surprised he didn't like it.
- joshuamorton 4y ago
  It speaks to why he might have been banned, which is the context of this thread.
  - voxtech 4y ago
    We shouldn't have to speculate as to why he was banned, as the CoC requires communication to him about why. If they're breaking CoC to get rid of the guy (and likely because the CoC prevented them from doing so in the past), it's hard to justify no matter the reason. And to be frank, filippo's contribution to this thread places a clear reason why- drew was incredibly rude in the second link, but his arguments were not bad faith. He clearly meant everything he said, and I would even argue that he was right, although his method of engagement was unacceptable. More importantly, the exchange was 3 years ago, and the more recent exchange showed him engaging exactly how I would expect a professional to. If the 3 year old exchange is the best filippo could find, it indicates that drew has changed his tactics for the better. So why the ban?
    - coldacid 4y ago
      Because Google's full of assholes who just don't give a damn that the rest of the world doesn't have the unlimited bandwidth and storage of the Big G.
cycomanic 4y ago
> Disclosure: I was on the Go team at Google until earlier this month. Dealing with DeVault's bad faith arguments is one of the few things I won't miss of that job. So does or does not the problem persist? Second was or was he not banned from the commenting issue tracker. Third does the CoC require that a person gets notified by the moderator and was DeVault notified? If the answers are yes to all those problems I wonder who is makeing bad faith arguments? Note: I have absolutely no skin in this game, except for being a sway and gmail user.
- tptacek 4y ago
  The subthread we're commenting on is about the ban, not about the proxy.
  - cycomanic 4y ago
    The OP specifically said: > Dealing with DeVault's bad faith arguments is one of the few things I won't miss of that job. They didn't say bad faith argument about banning, they said argument_s_. So he is not just talking about a single one. Which are the bad faith arguments? I asked if any of the things were not true, nobody said they were untrue. How can any of the arguments (I did not just talk about the proxy, I also talked about the banning) be bad faith if they are true?
    - joshuamorton 4y ago
      The bad faith arguments being referred to are ones made on the issuetracker, not in the article.
thaway2839 4y ago
The second link is irrelevant to the issue at hand. I'm sure there are a lot of shitty Google devs who have behaved shittily with others. I don't think that's reason for, say, an ISP, to ignore any issues Google might face as an entity. The relevant first link clearly lays out an implementation problem. It's not just git.sr.ht that's facing it, but another user also comes in to point out a tremendous amount of traffic. An amount of traffic that is fairly irresponsible to say the least. The issue owner doesn't deny the problem. They simply say it requires work. It appears they are unwilling to do the work to resolve the unsavory behavior, and instead are asking the host of Go modules to disable the ability for their service to be used as a Go module host, or instead suck it up and deal with the cost and complications of Google not putting in the effort to fix their architecture's DDoSish behavior. Google and Go have the market power to pull this off, but let's not pretend this isn't bad behavior. An appeal to Drew's terrible personal communication style does not change that.
- Beltalowda 4y ago
  > The second link is irrelevant to the issue at hand. It's relevant to the issue of the ban, which is what the (sub)thread is about. I think the reason it was posted was to demonstrate a pattern, and I think that's pretty relevant. Every single disagreement I've had with Drew escalated and I don't think that's my fault since it never happens with anyone else (Never? Well, hardly ever) and I've seen it happen with various other people too. Not that I'm perfect by any means or couldn't have done things better, but there's certainly a pattern here. As for the actual issue at hand: I mostly agree with Drew, however, I don't really have enough information to be sure here, and Drew has misrepresented things in the past and does so here in this post (a reader unfamiliar with Go would be left assuming that Go "phones home" just for the sake of "phoning home" after reading this article, which is really a misrepresentation IMHO), so there's not a lot of trust here (again, a pattern).
randomtwiddler 4y ago
Seems like recrimination to bring up unrelated items.
spacexsucks 4y ago
quadrifoliate 4y ago
I do not understand why the issue is not discussing DeVault's straightforward robots.txt suggestion: > Have you considered the robots.txt approach, which would simply allow the sysadmin to tune the rate at which you will scrape their service? The best option puts the controls in the hands of the sysadmins you're affecting. This is what the rest of the internet does. The only explanation I see later in the thread is: > For boring technical reasons, it would be a fair bit of extra work for us to read robots.txt, so rather than going to a bunch of work to do that, we implemented a trivial list and offered to add sr.ht to it. This is...not a satisfactory technical explanation. Perhaps the Go team should consider providing more openness and transparency about why it's "a fair bit of extra work" to implement an internet standard like DeVault suggests. Honestly, DeVault is an abrasive person and not necessarily someone I would go out of my way to work with, but I don't see how the Golang team isn't at least somewhat at fault here for brushing off a community member with "Eh, it's too complicated for you to understand". That's not how you build a thriving community around a language.
- tptacek 4y ago
  They didn't brush him off. They gave him an immediate workaround, which --- contra some messages on this thread --- did not entail making sr.ht unusable for Go projects. At the time he posted this, he had not taken the Go team up on that workaround; doing so appears to involve only DeVault saying "go ahead" to the Go team.
  - quadrifoliate 4y ago
    > They didn't brush him off. I disagree, the "for boring technical reasons..." is as close to a brush-off as I can see. This is a technical issue tracker, why not be open and honest about the reasons? I feel like these days people just seem to take it on faith that "Oh, it's Google, surely they know best when they say it's a mysterious technical issue that's too hard to solve". Also, banning someone from the issue tracker in violation of their own CoC does not seem like good faith behavior either. Note that the message from 'FiloSottile does not clearly spell out whether DeVault's ban was following a CoC, it just obliquely quotes some nasty stuff that he's apparently said in the past. I think other commenters are correct to call it irrelevant, it's about as relevant as it would be if I started randomly quoting Rob Pike's notorious comments about syntax highlighting [1]. Overall, I totally acknowledge the Golang team is providing a workaround that will solve the (admittedly abrasively spoken) user's problems. What I'm saying is that that is not enough. If you want an open language that will not turn into .NET, you have to do better by your community and also be transparent as to how and when you're planning to solve your users' problems. And preferably also be transparent about CoC bans, especially if there is a technical discussion involved. For example, this sounds like a reasonable response to me: "We have written up a task to make our proxy code parse robots.txt correctly, but there are N other tasks above it, and it looks like we won't be able to work on it for approximately the next six months. Until then, a workaround is..." ---------------------------------------- [1] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ1RDiio8J https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ....
conioh 4y ago
> Disclosure: I was on the Go team at Google until earlier this month. Dealing with DeVault's bad faith arguments is one of the few things I won't miss of that job. Speaking of bad faith arguments, aren't Google and its employees the ones that: - Claimed that scrolling screenshot on Android are "infeasible" [INFEAS] despite Samsung, LG, HTC, etc. already implementing the feature in their forks/distributions of Android? - Claimed "[t]he generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?" as an excuse for not implementing Generics in Go? - After years of claiming this nonsense finally implemented Generics in exactly those ways? [GoLang_GenImpl] - Even when implementing Generics in exactly those old and previously known ways claim that "Russ Cox famously observed that generics require choosing among slow programmers, slow compilers, or slow execution times. We believe that this design permits different implementation choices." [GoLang_43651] - "Loses" or "loses track" of their customer's mobile phones, and when said customers cancel the credit charges for the phones they never received or otherwise disappeared, block their Google accounts, including their access to email? [Google_Criminals] Drew DeVault certainly deserves some or even a lot of criticism, but Google and its employees attacking other for "bad faith"? This should be acceptable in a civilized society. [GoLang_43651]: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#implementation https://go.googlesource.com/proposal/+/refs/heads/master/des... [Google_Criminals]: For example: https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_permanently_banned_my_account_because/ https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_... and https://www.reddit.com/r/GooglePixel/comments/84sysx/update_google_permanently_banned_my_account/ https://www.reddit.com/r/GooglePixel/comments/84sysx/update_... There have been other documented cases of the same so this is not a single uncharacteristic incident. [GoLang_GenImpl]: https://go.googlesource.com/proposal/+/e0113ba8479092562cf9d6d4e0e65d3268c2067a/design/generics-implementation-dictionaries-go1.18.md https://go.googlesource.com/proposal/+/e0113ba8479092562cf9d... [INFEAS]: https://issuetracker.google.com/issues/80491647#:~:text=Status%3A%20Won%27t%20Fix%20(Infeasible) https://issuetracker.google.com/issues/80491647#:~:text=Stat...

reidrac 4y ago

So what is your opinion on the proxy behaviour then? I know is not like knowing what Google thinks about this, but I'm curious about how something like what is described in the post is allowed to happen.

striking 4y ago
I would be surprised if their opinion differs from that of the first link they sent.

cookiengineer 4y ago

How are his arguments in bad faith if he is the one that gets DDoSed by your software for over a year, and still tries to be helpful? Not sure if you realize the absurdity of this, but he has to pay traffic and server costs. Like everyone else, except probably Google as it seems!? I mean, you didn't even consider implementing a simple fetch of an already cloned repository in your mirroring server code. So yeah, I'd argue that the bad faith part is actually justified.

rfoo 4y ago
> and still tries to be helpful "Assuming everyone else have exactly same design choice and architecture as yourself, making suggestion on this ground and calling other people crazy because they can't implement what you suggest them to do" is not trying to be helpful. Well, or maybe I'm just frustrated reading his repeated "please keep a copy 'locally' somewhere and run git fetch". Just like how I'm frustrated arguing with him on HN about whether sending patch to mail list is better than GitHub pull request. Don't get me wrong, I understand this is a real Google-scale system v.s. individual code hosting website issue, I just don't see how his "please stop being Google and instead try my works-fine-on-one-box solution" take is helpful.
- ocdtrekkie 4y ago
  Cloudflare manages to cache things and then serve them to lots of people, without having to request the same content 50 times an hour. Maybe Google should move some of their services over to a better content delivery platform? o.O This is a scenario where anyone who isn't a Googler can see that "being Google" is not a justification for bad engineering. Do better.
- cycomanic 4y ago
  I often don't agree with DeVaults opinions, however the design decision here is actually costing other people real money and I have not seen a convincing argument why it is necessary. Instead they acknowledge it's an issue, but then continue that behavior for nearly a year, which IMO shows complete disregard for smaller services or individuals hosting their own repositories.
- thaway2839 4y ago
  Suggesting ideas is not the same as assuming everyone else should have the exact same design choice and architecture. The problem is that the actual issue owner on the Google side does not appear to have any solutions (or is burying solutions because they may be too complex). It's pretty clear that the issue owner agrees there is something wrong here. That's why the issue is kept open and their only reason for not fixing it is that it's a complicated fix which requires effort. As a workaround, they offer Drew the opportunity to essentially disable his service from being used as a useful source of Go modules.

generalizations 4y ago

I see the fairly civil communication you had with Drew in the first link, but your inclusion of the second (given it's an unrelated issue) just feels like you're throwing mud in order to minimize the technical concerns he raised. It seems like the only solution suggested there is one that makes the "small fish" service less useful as a go repository. I'm not surprised he didn't like it.

joshuamorton 4y ago
It speaks to why he might have been banned, which is the context of this thread.
- voxtech 4y ago
  We shouldn't have to speculate as to why he was banned, as the CoC requires communication to him about why. If they're breaking CoC to get rid of the guy (and likely because the CoC prevented them from doing so in the past), it's hard to justify no matter the reason. And to be frank, filippo's contribution to this thread places a clear reason why- drew was incredibly rude in the second link, but his arguments were not bad faith. He clearly meant everything he said, and I would even argue that he was right, although his method of engagement was unacceptable. More importantly, the exchange was 3 years ago, and the more recent exchange showed him engaging exactly how I would expect a professional to. If the 3 year old exchange is the best filippo could find, it indicates that drew has changed his tactics for the better. So why the ban?
  - coldacid 4y ago
    Because Google's full of assholes who just don't give a damn that the rest of the world doesn't have the unlimited bandwidth and storage of the Big G.

cycomanic 4y ago

> Disclosure: I was on the Go team at Google until earlier this month. Dealing with DeVault's bad faith arguments is one of the few things I won't miss of that job. So does or does not the problem persist? Second was or was he not banned from the commenting issue tracker. Third does the CoC require that a person gets notified by the moderator and was DeVault notified? If the answers are yes to all those problems I wonder who is makeing bad faith arguments? Note: I have absolutely no skin in this game, except for being a sway and gmail user.

tptacek 4y ago
The subthread we're commenting on is about the ban, not about the proxy.
- cycomanic 4y ago
  The OP specifically said: > Dealing with DeVault's bad faith arguments is one of the few things I won't miss of that job. They didn't say bad faith argument about banning, they said argument_s_. So he is not just talking about a single one. Which are the bad faith arguments? I asked if any of the things were not true, nobody said they were untrue. How can any of the arguments (I did not just talk about the proxy, I also talked about the banning) be bad faith if they are true?
  - joshuamorton 4y ago
    The bad faith arguments being referred to are ones made on the issuetracker, not in the article.

thaway2839 4y ago

The second link is irrelevant to the issue at hand. I'm sure there are a lot of shitty Google devs who have behaved shittily with others. I don't think that's reason for, say, an ISP, to ignore any issues Google might face as an entity. The relevant first link clearly lays out an implementation problem. It's not just git.sr.ht that's facing it, but another user also comes in to point out a tremendous amount of traffic. An amount of traffic that is fairly irresponsible to say the least. The issue owner doesn't deny the problem. They simply say it requires work. It appears they are unwilling to do the work to resolve the unsavory behavior, and instead are asking the host of Go modules to disable the ability for their service to be used as a Go module host, or instead suck it up and deal with the cost and complications of Google not putting in the effort to fix their architecture's DDoSish behavior. Google and Go have the market power to pull this off, but let's not pretend this isn't bad behavior. An appeal to Drew's terrible personal communication style does not change that.

Beltalowda 4y ago
> The second link is irrelevant to the issue at hand. It's relevant to the issue of the ban, which is what the (sub)thread is about. I think the reason it was posted was to demonstrate a pattern, and I think that's pretty relevant. Every single disagreement I've had with Drew escalated and I don't think that's my fault since it never happens with anyone else (Never? Well, hardly ever) and I've seen it happen with various other people too. Not that I'm perfect by any means or couldn't have done things better, but there's certainly a pattern here. As for the actual issue at hand: I mostly agree with Drew, however, I don't really have enough information to be sure here, and Drew has misrepresented things in the past and does so here in this post (a reader unfamiliar with Go would be left assuming that Go "phones home" just for the sake of "phoning home" after reading this article, which is really a misrepresentation IMHO), so there's not a lot of trust here (again, a pattern).

randomtwiddler 4y ago

Seems like recrimination to bring up unrelated items.

spacexsucks 4y ago

quadrifoliate 4y ago

I do not understand why the issue is not discussing DeVault's straightforward robots.txt suggestion: > Have you considered the robots.txt approach, which would simply allow the sysadmin to tune the rate at which you will scrape their service? The best option puts the controls in the hands of the sysadmins you're affecting. This is what the rest of the internet does. The only explanation I see later in the thread is: > For boring technical reasons, it would be a fair bit of extra work for us to read robots.txt, so rather than going to a bunch of work to do that, we implemented a trivial list and offered to add sr.ht to it. This is...not a satisfactory technical explanation. Perhaps the Go team should consider providing more openness and transparency about why it's "a fair bit of extra work" to implement an internet standard like DeVault suggests. Honestly, DeVault is an abrasive person and not necessarily someone I would go out of my way to work with, but I don't see how the Golang team isn't at least somewhat at fault here for brushing off a community member with "Eh, it's too complicated for you to understand". That's not how you build a thriving community around a language.

tptacek 4y ago
They didn't brush him off. They gave him an immediate workaround, which --- contra some messages on this thread --- did not entail making sr.ht unusable for Go projects. At the time he posted this, he had not taken the Go team up on that workaround; doing so appears to involve only DeVault saying "go ahead" to the Go team.
- quadrifoliate 4y ago
  > They didn't brush him off. I disagree, the "for boring technical reasons..." is as close to a brush-off as I can see. This is a technical issue tracker, why not be open and honest about the reasons? I feel like these days people just seem to take it on faith that "Oh, it's Google, surely they know best when they say it's a mysterious technical issue that's too hard to solve". Also, banning someone from the issue tracker in violation of their own CoC does not seem like good faith behavior either. Note that the message from 'FiloSottile does not clearly spell out whether DeVault's ban was following a CoC, it just obliquely quotes some nasty stuff that he's apparently said in the past. I think other commenters are correct to call it irrelevant, it's about as relevant as it would be if I started randomly quoting Rob Pike's notorious comments about syntax highlighting [1]. Overall, I totally acknowledge the Golang team is providing a workaround that will solve the (admittedly abrasively spoken) user's problems. What I'm saying is that that is not enough. If you want an open language that will not turn into .NET, you have to do better by your community and also be transparent as to how and when you're planning to solve your users' problems. And preferably also be transparent about CoC bans, especially if there is a technical discussion involved. For example, this sounds like a reasonable response to me: "We have written up a task to make our proxy code parse robots.txt correctly, but there are N other tasks above it, and it looks like we won't be able to work on it for approximately the next six months. Until then, a workaround is..." ---------------------------------------- [1] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ1RDiio8J https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ....

conioh 4y ago

> Disclosure: I was on the Go team at Google until earlier this month. Dealing with DeVault's bad faith arguments is one of the few things I won't miss of that job. Speaking of bad faith arguments, aren't Google and its employees the ones that: - Claimed that scrolling screenshot on Android are "infeasible" [INFEAS] despite Samsung, LG, HTC, etc. already implementing the feature in their forks/distributions of Android? - Claimed "[t]he generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?" as an excuse for not implementing Generics in Go? - After years of claiming this nonsense finally implemented Generics in exactly those ways? [GoLang_GenImpl] - Even when implementing Generics in exactly those old and previously known ways claim that "Russ Cox famously observed that generics require choosing among slow programmers, slow compilers, or slow execution times. We believe that this design permits different implementation choices." [GoLang_43651] - "Loses" or "loses track" of their customer's mobile phones, and when said customers cancel the credit charges for the phones they never received or otherwise disappeared, block their Google accounts, including their access to email? [Google_Criminals] Drew DeVault certainly deserves some or even a lot of criticism, but Google and its employees attacking other for "bad faith"? This should be acceptable in a civilized society. [GoLang_43651]: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#implementation https://go.googlesource.com/proposal/+/refs/heads/master/des... [Google_Criminals]: For example: https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_permanently_banned_my_account_because/ https://www.reddit.com/r/GooglePixel/comments/7nrx07/google_... and https://www.reddit.com/r/GooglePixel/comments/84sysx/update_google_permanently_banned_my_account/ https://www.reddit.com/r/GooglePixel/comments/84sysx/update_... There have been other documented cases of the same so this is not a single uncharacteristic incident. [GoLang_GenImpl]: https://go.googlesource.com/proposal/+/e0113ba8479092562cf9d6d4e0e65d3268c2067a/design/generics-implementation-dictionaries-go1.18.md https://go.googlesource.com/proposal/+/e0113ba8479092562cf9d... [INFEAS]: https://issuetracker.google.com/issues/80491647#:~:text=Status%3A%20Won%27t%20Fix%20(Infeasible) https://issuetracker.google.com/issues/80491647#:~:text=Stat...