They are heavily debt financed I believe, almost $5 billion worth last I checked.

So they really are like the Private Equity of the software world.

More like following the Computer Associates model, a tale as old as time. Find a mature platform with a captive user population with a fat, lazy management team, buy them out, slash headcount, and open the taps. Someone in the thread mentioned Atlassian, that is a perfect target for this kind of strategy.

Yes but focussing more on long-term ownership, as opposed to the usual turn-around and flip or asset stripping methodology.

You see this in many things. Look at climbing for instance, or running. Once the first v17 had been done, suddenly many people did them. Or running with a sub 2 hour marathon.

Griffin and citadel less bailed him out, and more circled like sharks and made out with a good deal TBF.

That's a fair point. I suppose the difference is if a rando is about to get blown out of the water, no one is coming to save them. If someone connected is going to get blown out of the water, calls are going to be made, people are going to meet, and it's going to "be taken care of" even if it's a good deal for whomever is Winston 'The Wolf' Wolf in the situation. Caveat being that sometimes, even if well connected, you're still toast (Archegos Capital Management and Bill Hwang).

Don't they just share the colossus 1 data center?

The data is from the federal reserve.

From the Fed's own description of the dataset "The Survey of Consumer Finances (SCF) is normally a triennial cross-sectional survey of U.S. families. The survey data include information on families' balance sheets, pensions, income, and demographic characteristics."

Families would suggest household, not personal.

It was superseded by the antigravity CLI.

It's actually crazy that a music app struggles to play music many times. By far my worst big app experience.

Usually the ideas it that the theoretical maximum is not a local optima though, but some ideal global optima which you know you realistically cannot reach.

That is you know the data is some size, and memory throughput is some rate, and clock cycles is some rate etc...

You are entirely correct about the line of thinking if your assumptions are down a different line of thinking such as algorithmic estimates though, where you might miss some better way of doing things.

I've always used this method of working and can stand by it. For instance let's say you are working on a high-speed real-time image processing system. If you know that each image is 1080p for instance, that's 2 million pixels, and we will have 3 bytes per pixel for colour, then that's like 6MB per image (without compression). If you have 25 GB/s of RAM bandwidth, then there is a hard limit of ~4 thousand frames per second if you aren't even doing any processing. Therefore if you strip out your processing and are only getting say 400 frames per second, you know something is going wrong.

This can be applied roughly to anything. I find it very handy when thinking about CPU/GPU performance as well. For instance knowing that at 5GHz you have 5 billion clock cycles per second, which depending on instructions and pipe lining etc... can be roughly 5-30 billion operations per second per core tells you how long some process should take if you know roughly how many operations are required and the data size you are operating on.

Obviously as you drill down things get much more complicated, but they give you some rough idea about how fast things could be under some set of assumptions. Very similar to how a physicist works with models and assumptions.