I don't have time to research now, but there were some well detailed breakdowns of the large payments when the bailout happened.
The first relevant link in DDG is a statement by the Chairman of the FDIC. He claims that the top ten accounts held more than 13.3B between them, which is more than 10% of the total of all deposits in the bank, and more than half of the $20B that the government is expected to payout in total. [1][2]
The FDIC would otherwise have had to pay a scant 3M of that, so there's 2/3 of the bailout just in those 10 accounts. If we include the next ten accounts, it will be much, much more. (One of the articles at the time claimed more than 85% went to 15 accounts, but I didn't want to be extreme without time to research sources.)
I think that's a misinterpretation of the data. Based on reports, SVB had around 130B of deposits when it was taken into receivership. Something like 90% of that was uninsured, so around 115B of uninsured deposits. The 20B hole means that without FDIC backing the uninsured deposits, they still could have paid out over 80 cents on the dollar. So if the top ten accounts had about 13.3B of deposits, they only received less than 2.7B of the bailout - less than 15%, not "well over half".
I strongly suspect that any sources that claimed that simply made the same error that you did.
Looking at the source you provided from the Chairman of the FDIC, it actually says that the top ten accounts held $13.3B - not _more than_ $13.3B, as you claimed. The next ten accounts necessarily held less than that, so say a generous upper bound at $26.6B for the top twenty accounts. In order for them to get at least half of the bailout, they would have needed to hold north of $55B in aggregate. The FDIC itself would have to have gotten the size of SVB's largest depositors wrong by over double in order for your original claim to be true, in the absolute most generous case.
Can you elaborate on this? What is the input to the GPT in that case? I was under the impression that GPT is given an array of tokens and it produces one token as its output.
There’s no way I’m logging into rando apps using my GitHub id. Aside from their bad UX and the potential to accidentally over grant permissions, the app could abuse GitHub ToS with my credentials and get me banned.
Not worth the risk just to play around with a site.
The sign-up form doesn't seem to allow passwords with non-alphanumeric characters in them. Ironically, when it sees one, it complains that "password must have at least one number and at least one letter" (even though it already does) - I suspect that's just a catch-all message for invalid passwords?
In any case, the restriction makes it incompatible with pretty much all password generators, including the built-in ones in modern browsers. To improve matters, I would suggest dropping all restrictions on what cannot be included altogether.
Cloudflare's RFO blog posts are incredibly detailed. Each time I read one, I feel reasonably confident that they have learnt from the mistakes that lead to that outage and that it shouldn't happen again.
TreeCard | Mobile and Backend Engineers | Full-Time or Contract to Hire | Remote
TreeCard is a debit card which reforests the planet when you spend, backed by Ecosia. We have over 150,000 people on our waiting list, we’ve just closed a $5mn seed, and our ambition is to be the leading green finance brand for the 21st century. By 2026, we aim to have planted 1bn trees.
Hiring for mobile (React Naive) and backend (Go) engineers, please reach out at gary AT treecard.org
FluidStack has built technology to turn any device into a cloud server, creating a massively distributed cloud platform running on consumer devices. We leverage under-utilised capacity to provide lower cost and higher performance cloud services. Long term, we want to create a distributed AWS.
We are VC-backed (Episode 1, Seedcamp, Founders Factory), and are seeking world-class engineers to help us scale the platform as we work towards our Series A at the end of the year.
Drop me an email on gary [AT] fluidstack.io if you are interested in learning more!
FluidStack | Peer to Peer (P2P) Networking Engineer, Infrastructure Engineer | London | ONSITE | Full-time | http://www.fluidstack.io
FluidStack is building technology to turn any device into a cloud server, creating a massively distributed cloud platform, cheaper and faster than incumbents.
We are VC-backed (Episode 1, Seedcamp, Founders Factory), and are seeking world-class engineers to help us build out and scale the platform.
More detailed job details on our site.
Drop me an email on gary [AT] fluidstack.io if you are interested in learning more!
Flare | Peer to Peer (P2P) Networking Engineer, WebRTC Engineer, Cloud Systems Engineer | London | ONISTE | Full-time | http://www.flare-global.com
Flare is building technology to turn any device into a cloud server. We aim to use this to build a cheaper, faster, and more ethical internet.
We are VC-backed (Episode 1, Seedcamp, Founders Factory), and have built out a working first version. We are now seeking world-class engineers to help us build out and scale the platform.
Do you have a source for this?