People on HN have a very, very strange idea of what a "CTO" does. Kurtz was the CEO of Foundstone when MCAF bought him. Foundstone was not small. The most important skill most CTOs have is identifying themselves as "the CTO" on calls with customer prospects.
attritioning out staff is one of the dumbest strategies imaginable- it's not a good job when the market isn't competitive either because your highest performers are STILL going to be the first go and you can't even replace them.
It never works but companies always try it and then HAVE to do a shady layoff just to rebalance their teams.
Stack switching isn't that much of the overhead. "ordinary" cgo overhead is <100ns now, has been for a few years, and is much closer to 30 than 80 on recent processors. Most of the overhead is a set of 4 CAS operations (incidentally this means that AMD has measurably lower cgo overhead because of something with its caching model I don't understand).
If cgo's only overhead was the "ordinary" overhead, most people wouldn't have an issue with it. It's downright zippy, in fact... as long as your syscall/C call takes less than 1us. If you stay under the 1us threshold, go will put the OS thread used for the syscall back where it found it and everything moves on.
The issue is that the OS thread was previously serving N goroutines that other parts of the program may be waiting on to move forward, and the OS thread is in a state where go can't pre-empt it and allow those other goroutines to move forward, and it has no idea how long it will be until it can move forward.
As a result, if a syscall/c call takes longer than 1us, go has no choice at this time but to resume a new thread, context switch all the old work onto that thread, and then suspend the syscall thread when it comes back. If you do this a lot, your performance will crater.
There's also separately a few issues around how go chooses to resume/suspend OS threads (for instance, if an os-locked goroutine does coooperative park for any reason to wait on another thread to do something, go will suspend the thread it was on, context switch to a different thread, then when the goroutine wakes up, it will realize its mistake, resume the thread it was on and context switch again).
This is all fixable stuff, but all the use cases that google cares about are working fine so it doesn't really get any attention.
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?
How exactly does this workaround degrade service for DeVault's Go users? I'm not saying it doesn't; I'm saying nobody has given a simple explanation of what the impact would actually be, except for some people who have given clearly false explanations.
It's OK to just not know, but if you don't know, it's weird to have strong opinions about it.
Is that an answer to some other question I asked? It doesn't seem to be responsive to what I just wrote.
I feel like what I'm sticking up for here is the practice of software development. Building an automated system that generates unexpectedly unwelcome load on someone else's service is... not exactly front-page news? It happens basically all the time? The idea that because the Go team is sponsored by Google, nothing like this should ever happen seems deeply unrealistic. "We can push a button to make this stop happening; the tradeoff is that other hosting services that don't care about this load might currently have fresher cache entries [whatever that means]" seems like a perfectly cromulent response.
He should just tell them to push the button. If you think he shouldn't, you should be able to say why.
I do have a mild rooting interest here: I think the Go module proxy is pretty neat, and does something interesting for the security of the ecosystem. DeVault disagrees. That's fine, disagreement keeps things interesting.
> He should just tell them to push the button. If you think he shouldn't, you should be able to say why.
Accepting that Drew should get them to just push the button is accepting that it is the responsibility of each victim individually to cope with the abusive load being sent their way by engaging directly with their abuser. Rather than the sender, who is truly the one responsible, fixing it for every target by reducing their polling at source.
I don't understand how this logic is meant to hold. The behavior can be of enough value to justify it where the cost to source hosts is low, but not of enough value to justify it for all hosts. Which is where we are now.
It feels like some comments here are trying to reconstruct what happened axiomatically purely from comments on the thread, without any empirical input from, like, how the Go module proxy actually works, and ending up in weird places as a result.
Personally I'm trying to keep it tied down to an issue of responsibilities.
The abuser of resources should stop abusing. It isn't the fault of the victims and they shouldn't each individually need to address it. Stop the issue at source for everyone by stopping being anti-social/parasitical on the use of resources through excessive polling. I think that's the extent of my own argument here.
It's not a great argument? If Github and Gitlab are fine with the polling, and the polling has even marginal benefits for Go users, why should we care how they handle Github and Gitlab? It sure looks like nobody on the Go project knew that sr.ht would care about these module clones, and when they found out, they gave DeVault the option of stopping them. I'm still not clear what the issue is.
If they knew DeVault's host wasn't going to be able to handle repeated module clones, a priori, then doing it anyways would be a problem. It doesn't look like anyone expected this to be a problem. It turned out it was, and there's a fix.
This claim is outrageous- if disabling sourcehut is a valid workaround, then google should end the refresh behavior on the proxy since it isn't providing any valuable service. If the proxy provides a valuable service, then disabling sourcehut would degrade service for sourcehut users.
That logic doesn't even cohere. If Github and Gitlab can sustain more aggressive queries from the module proxy, they may have fresher cache entries in that proxy. That's what being more capable gets you. The Go team isn't obligated to operate at the lowest common denominator of all source hosts.
If the Go team's workaround was to make sr.ht not viable for Go modules, that would be deeply problematic. But it isn't; in fact, nobody who's upset about this seems to be able to describe what the Go team's workaround would even impact. Can you?
It's an unusual situation because the document I think pretty badly misrepresents what happened right up until Peter LOST HIS ENTIRE MIND. In particular, Brendan Dube is a well-known stupid prick on the slack and he was being a stupid prick in this particular conversation. Peter's initial response was well-deserved but oh man did he lose it afterward.
Same here, toward the end of 2015. I would not have a serious high-paying job right now if it wasn't for triplebyte. I'm sad to hear the process hasn't scaled because I think that it'd help everyone out if it had.
