Caveat buried in the abstract is that this beats BERT and non-pretrained Transformers. Looks like GPT style should still be better, but naturally requires a higher computation cost

Gzip every query with all training data can get more expensive.

… and we avoid contagion of all regional banks.

YC isn’t the only set of companies that used Svb, they’re probably representative of the distribution of startups that need banking

Roughly 50% of all venture backed startups in the US have an SVB account. So yes, it's much larger than just YC.

How could someone think that this was a really good idea? It's like joining a pension fund with the average insured being over 50. Distribute risk whenever possible.

Generally agree. I run a startup and we have a few bank accounts. Luckily we were able to pull what we had in SVB (around 35% of cash reserves) on Thursday.

I think a lot of startups are in this situation. They have SVB accounts, but likely don’t have all of their money in there.

One thing to remember, SVB is very founder friendly. Often giving companies favorable lines of credit, giving founders favorable mortgages, etc. They helped us tremendously with our PPP loan, and are also deeply integrated with products like Stripe Atlas.

We use it at Pixie to easily setup certs for our self hosted users. Amazing tool.

or coordinate them so that doesn’t happen?

This gets into the utility frequency... that information is already out there, on the grid. https://en.wikipedia.org/wiki/Utility_frequency#Frequency_an... and https://en.wikipedia.org/wiki/Dynamic_demand_(electric_power...

The way that power companies "communicate" about load is by slightly changing the frequency.

If the frequency is 60.5, then there's an abundance of energy on the grid and some less profitable generators can cut back or storage systems can charge. If the frequency is 59.5 then there's a lack of available power on the grid and other generators should go on line and unnecessary load should stop doing its thing (and if it has the ability, it could discharge instead).

That's how it works already in Australia

People in US were so flipped when they heard this

I'm trying not to be smug, but are you under the assumption that the delivery of physical forms of energy is simple? Distributing, on average, ~1.5B liters of gasoline, with different qualities/chemistries/regions/etc, every day in the US has immense amounts of complexity. Now do that for coal, natural gas, heating oil, etc.

Managing time of day for charging isn't a more complicated problem than any of those.

Sorry, it's not even hard. Coordination isn't even necessary. You just locally randomly choose a timeslot and there will be a uniform distribution.

if the org has funding and you made a thoughtful contribution, I can’t imagine a better signal for knowing you’d be a good hire

That article is very interesting! Looks like a similar approach to: https://sysdig.com/blog/hiding-linux-processes-for-fun-and-p...

I wouldn't feel bad about it. The article provides info for security experts about a potential attack vector that exists. That doesn't change if you unpublish the post.

Keep it up!

I'm not quite sure the flavor of your problems, but I imagine some of them were caused be the confusion between v1beta1 and v1 apis. Users would continue to use beta versions of APIs despite the availability of the GA APIs.

Hopefully this becomes easier with the beta lifecycle policy: https://kubernetes.io/blog/2020/08/21/moving-forward-from-be...

Unfortunately this also means you'll see similar issues in the short term.

One way to avoid these might be to opt for only GA k8s APIs for your infra.

I think the machine learning community at Berkeley is pretty cool. Thanks for putting out great work guys!