singron

I will say it's not practical to have exams that long. In this case, the dorm required me to move out immediately after the exam and my parents were waiting to pick me up, so I decided to leave after 4 hours to avoid unnecessary panic or having to drive overnight. In hindsight, the professor probably would have let me make a phone call, but that didn't occur to me at the time.

This is unlike an RSU from a public company, where you can sell the value of your shares as they vest and add that to your income with minor risk of price volatility.

If you aren't sure whether to pull the trigger on a subscription, I would put $5-$10 into an API console account and use CC with an API key.

Also the semianalysis estimate is from Feb 2023, which is before the release of gpt4, and it assumes 13 million DAU. ChatGPT has 800 million WAU, so that's somewhere between 115 million and 800 million DAU. E.g. if we prorate the cogs estimate for 200 DAU, then that's 15x higher or $3.75B.

To steelman the original concept, annual revenue isn't a great measure for a young fast-growing company since you are averaging all the months of the last year, many of which aren't indicative of the trajectory of the company. E.g. if a company only had revenue the last 3 months, annual revenue is a bad measure. So you use MRR to get a better notion of instantaneous revenue, but you need to annualize it to make it a useful comparison (e.g. to compute a P/E ratio), so you use ARR.

Private investors will of course demand more detailed numbers like churn and an exact breakdown of "recurring" revenue. The real issue is that these aren't public companies, and so they have no obligation to report anything to the public, and their PR team carefully selects a couple nice sounding numbers.

A 10th amendment violation would be if the feds require the state to perform federal law enforcement.

Federal authority is relevant if they e.g. raided state law enforcement offices to take the data without consent, but in this case they are just given the data by state officers.

In this case, you might have enough dead tuples across your heap that you might get a lot of HOT updates. If you are processing in insertion order, you will also probably process in heap order, and you can actually get 0 HOT updates since the other tuples in the page aren't fully dead yet. You could try using a lower fillfactor to avoid this, but that's also bad for performance so it might not help.

Holding transactions open is an anti-pattern for sure, but it's occasionally useful. E.g. pg_repack keeps a transaction open while it runs, and I believe vacuum also holds an open transaction part of the time too. It's also nice if your database doesn't melt whenever this happens on accident.

Maybe there is an acceptable way to shift long-term storage to CAs while using CT verifiers only for short term storage? E.g. they keep track of their last 30 days of signatures for a CA, which can then get cross-verified by other verifiers in that timeframe.

The storage requirements don't seem that bad though and it might not be worth any reduced redundancy and increased complexity for a different storage scheme. E.g. what keeps me from doing this is the >1Gbps and >1 pager requirements.

"Avg. Mturker" has 77% on ARC1 and costs $3/task. "Stem Grad" has 98% on ARC1 and costs $10/task. I would love a segment like "typical US office employee" or something else in between since I don't think you need a stem degree to do better than 77%.

It's also worth noting the "Human Panel" gets 100% on ARC2 at $17/task. All the "Human" models are on the score/cost frontier and exceptional in their score range although too expensive to win the prize obviously.

I think the real argument is that the ARC problems are too abstract and obscure to be relevant to useful AGI, but I think we need a little flexibility in that area so we can have tests that can be objectively and mechanically graded. E.g. "write a NYT bestseller" is an impractical test in many ways even if it's closer to what AGI should be.

Even if you use comprehensive forward-looking language, the court can choose to strike any part they don't like under the guise that the current situation didn't exist at the time of the drafting.

I feel async communication could work this way with the right cultural hygiene (e.g. consistent labeling, brevity, novelty, and relevancy), and some places I've worked were better about this than others, but they all tend to suffer from tragedy of the commons. If anyone works somewhere where you and all your coworkers actually count on each other to read emails, please tell me where!

Consumers subscribing to the same event type are placed in a group. There is a single lock for the whole group. When publishing, the lock is taken once and the event is replicated to each consumer's queue. Consumers take the lock and swap their entire queue buffer, which lets them consume up to 128 events per lock/unlock.

Since channels each have a lock and only take 1 element at a time, they would require a lot more locking and unlocking.

There is also some frequent polling to maintain group metadata, so this could be less ideal in low volume workloads where you want CPU to go to 0%.

I could imagine the situation might actually be more nuanced (e.g. adding new tests and some of them are commented out), but there isn't enough context to really determine that, and even in that case, it can be worth asking about commented out code in case the author left it that way by accident.

Aren't there plenty of more obvious nitpicks to highlight? A great nitpick example would be one where the model will also ask to reverse the resolution. E.g.

    final var items = List.copyOf(...);
    <-- Consider using an explicit type for the variable.

    final List items = List.copyOf(...);
    <-- Consider using var to avoid redundant type name.

All the standard tools for binary rollouts and config pushes will typically do some kind of gradual rollout.

In some ways Google Cloud had actually greatly improved the situation since a bunch of global systems were forced to become regional and/or become much more reliable. Google also used to have short global outages that weren't publicly remarked on (at the time, if you couldn't connect to Google, you assumed your own ISP was broken), so this event wasn't as rare as you might think. Overall I don't think there is a worsening trend unless someone has a spreadsheet of incidents proving otherwise.

[I was an SRE at Google several years ago]

That's not true at all and is exactly what prompt caching is for. For one, you can at least populate the attention KV Cache, which will scale with the prompt size. It's true that if your prompt is larger than the context size, then the prompt size no longer affects inference speed since it essentially discards the excess.