> The depositors did nothing here but put their own money in a bank account?
I'm guessing the mistake parent is implying to is that they put more than what was insured, knowing very well the risk that if the bank fail, they might only get back 250K USD, as it's only insured up to that.
Well, in theory at least. In practice it seems the insurance was actually a unspecified "unlimited" amount, as they'll get all their funds back now.
Bank offers you very favorable rates for cash, better than competitors.
You put lots of cash into bank account, "what could go wrong?"
Bank implodes.
Federal government bails you out and goes to collect the money to do so from other banks who offered more reasonable rates and thus didn't get your business.
Can we all just be reasonable here? There is no black and white.
SVB clearly offered services that other banks couldn't or wouldn't provide - whether that be loans, credit cards, interest, or anything else.
They clearly fought to not be subject to specific regulations that bigger banks were subject to.
Was every depositor thinking about all this when choosing their banking decisions or were they just going with the bank their VC recommended? Probably the latter, but there's definitely some wiggle room here.
I should've said "terms", I suppose. They were offering package deals where you have to exclusively bank with them and in return you get below-market loans, line of credit and potentially investments, and allegedly also for your personal financing needs. Give all your cash, accept the FDIC-limit risk, get favorable terms in return.
Why else would anyone put all their money into a single account, and why would VCs even enforce doing so contractually?
When someone offers you something the market doesn't, you should understand that there's risk attached, especially when you're a company with millions or hundreds of millions in cash. When someone falls for some crypto "18% per year, no risk" scam, that's how we view it.
Binning is definitely a possibility. Separately from binning, there are often just features that don't work right and get disabled with "chicken switches" or "feature enable bits."
Any two-ANE design would have a lot of control logic that has to be right, e.g., to manage which work gets sent to which ANE, which cache lines get loaded, etc. It's easy to imagine bugs in this logic which would only show up when both ANEs are enabled. So it's likely that there is a chicken bit that you could use to disable one of the ANEs and run in single-ANE mode.
Counter-opinion: industry simply has no plausible alternative to Verilog/SystemVerilog and succeeds in producing chips only in spite of the language's glaring flaws.
I worked for several years at a world class company verifying CPU designs. Even into the late 2010s, designers were afraid to use basic features like structs because who knows what tool might not support it correctly. They emulated structures using piles of defines that set all the bit offsets. I wouldn't know how to begin to estimate the amount of senseless work that this led to during debugging. The lack of any type safety was appalling. If you were lucky, you could catch gross type confusion by having a linting tool notice a size mismatch. These tools found hundreds of real errors that should never have compiled in the first place. I could go on and on...
But there's no escaping it. There are so many amazing tools built around it. The vendors love the moat the complexity gives them. The IP developers have huge investments in legacy code bases. Compatibility is worth too much.
The industry is extremely conservative. Costs of designing and taping out a modern chip range from $100M to $1B; these are the type of costs that will kill most companies if it goes wrong and very few companies can afford to have it go wrong more than once.
Tried and true approaches, small incremental developments are the only way things get done in this space. And the technological moat has many sources, not just Verilog etc. Process technology is continuously evolving and tools need to adapt to all the new physical rules and constraints. What gates are most efficient depends on the problem and the process and even by what the team means by efficient (least power? least energy? most mips/sec? least time to solve a problem? ...)
Everyone loves to complain about the tools though, that is universal. They'll just never adopt a new tool that hasn't survived the test of time and had enough successful designs "by someone else" that it doesn't make them nervous about being the first.
If you move that slider even just a few months to March 2020 you capture a doubling of the stock price, 1.5 years seems incredibly arbitrary as a cutoff point
FWIW -- A later, vaguely related project was Jitawa[1]. Its Lisp dialect was not as fancy as VLISPs, but its verification was much more thorough (machine checked proofs down to the X86 code for the runtime.)
Today, ongoing, CakeML[2] extends these techniques to an ML language and is just generally super awesome.
> The US is suffering another 9/11 every few days.
Except no, it is not 9/11. People with a year or two of life expectancy dying is not the same as what happened with 9/11 & not the same as Vietnam. Millions of people die every year in the US, it's what happens to the old, the sick and eventually to us all.
Please stop saying that 1 or 2 years life expectancy does not matter. It matter a LOT for their families and for them it is almost the same as loosing someone with 20 years life expectancy.
"Penalties in this section do not apply to users of tiktok"
https://leg.mt.gov/bills/2023/billpdf/SB0419.pdf