For non-Centaur features, we tried to match Intel since some software would hang or crash if we did something that was correct according to the manual but didn't match an actual Intel processor, so other things should be pretty standard (other than the obvious, like CentuarHauls vendor ID, etc.

Hah. Sorry, I don't have data sheets squirrelled away that aren't just the stuff you can find online.

For non-secret Centaur-specific feature flags, I don't know if there's a better still existing resource than looking at the 0xC0000001 section in git.kernel.org/pub/scm/linu...

This is great! Thanks for the pointer!

The commentary I've seen says Teslas are safe so it must be the drivers but, per danluu.com/car-safety/, maybe it's the cars. The most fatal rated manufacturers (Kia/Hyundai, Dodge, Tesla) all did poorly — Kia/Hyundai, Dodge got the lowest rating and there's a strong case Tesla should have as well.

i can speak with a little authority on this, i work in this field

DCs expend water by evaporation, either in cooling towers or evaporative coolers (water becomes vapor, taking latent heat energy with it into the air and leaving cooler liquid water behind)
so we expend liquid water resources 1/

Great! I'm looking forward to reading the blog post!

I've noticed that you sometimes turn your social media comments into blog post, which is something I should probably do more of.

Thanks for the comments. As someone who doesn't really work on this stuff, I find this super interesting!

As an outsider, it seems like wasm might become mainstream whether or not it delivers benefits to end users, just like heavy SPAs became mainstream regardless of the benefits.

I recently tried Blazor and the performance is incredibly bad (like, 5s to 10s initial load time for very simple apps, which you can push down to maybe 3s or something via various config options).

From news.ycombinator.com/item?id=3836..., I guess people still like it because it's nice for devs.

The effort to do this kind of work ended up getting defunded after a while even though the gains were measurable and very large, so even showing huge gains here wasn't sufficient.

On Ember, I didn't know it was such a performance problem. I think that's interesting.

We did see much larger impacts in the long-term holdback than in the initial test for the reason you mentioned — if someone thinks the app takes 60s to open, they probably won't open it very often, and you've already lost a huge fraction of users who've previously used the app and found it too slow

On a slow device, this decreased time from opening the app to seeing a tweet from something like 60s to 48s. It's incredible that people in that range would even use the app, but apparently some did, and it got more people into the range where they'd use the app or got them to use the app more.

on mobile, changes that made the app go from extremely slow to only very slow had large, measurable, impacts on retention/engagement/revenue. I forget the exact numbers, but a change that reduced the loading time of feature flags ended up increasing revenue something like 0.7%.

It's interesting that the impact wasn't easily observable on mobile. For Twitter, there was an experiment where (I forget the exact number) 500ms or 1s of delay was added on web and the impact was huge, and it was clear we could easily reduce latency by that much (but never did), and

Yeah, I've seen the Discourse people say that Discourse is super fast after the initial load because it's an SPA, but it's not, even my laptop, which is a faster machine than almost anyone has who isn't on a real workstation.

They seem to genuinely believe they have good performance.