jordanthoms

Oh, I agree on this. People were never going to accept, nor IMO should they have, a massive reduction in their living standards. New technology is the way to make people's lives better while also reducing global warming.

I just got back from a off-grid island here in New Zealand - 20 years ago, generators were everywhere and as soon as it got dark you'd hear nothing but the buzzing of running them all around you. Now there is solar everywhere and it's completely silent.

Humans can be trusted to do the right thing, once all other possibilities have been exhausted.

Also interested in this - the Apple Watch for Kids setup seems a possibility, but it's only available in certain countries

This is dependent on the database you are using - if it's a key-sharded distributed database, you want to have insertions evenly spread across the key space in order to avoid having all the inserts go into a single shard (which could overload it)

That's kinda the point though isn't it? DownDetector is showing an early indication of a major outage in both of your examples. The issue may not be caused by the indicated service, but it's still a useful information source especially when we can correlate reports on there with what we are seeing in our internal monitoring.

We saw a big spike in latency and failures on the Google OAuth apis starting at the same time (15:21 UTC)

A single report on there is useless. A sudden flood of reports is a good sign that something interesting is happening.

It has false positives and noise for sure, but it's also very sensitive and shows issues very quickly.

I wouldn't trust it as a single source, but in a case like this where our internal monitoring shows a spike of issues with the Google APIs and we can see a huge spike in reported issues for Google on Downdetector starting at the same time, it's useful to confirm that the issues have an external source.

I guess the problem there is pretty fundamental - in reality you'd be tensing muscles and shifting your weight etc before the snappy movement, but the game only knows that you want to move when you move the stick or push a button - so it either has to show that realistic motion after your button press and introduce latency, or sacrifice the realism in the animations.

It does seem like there would be a clean boundary between each school district, but actually there's plenty of sharing and collaboration on Kami that happens with users between districts, teachers and students move schools, parents can have children in different school districts, etc. Even a single classroom assignment can cross those, e.g. when someone external comes in to do a training session.

We could have modified our application layer to handle those cases, but it's a lot of extra complexity and room for error, and we'd have had to consider and solve for all of these cross-tenant situations as we add new functionality, so I was really keen to avoid that.

Also, there are some really big districts - NYCDOE has >1.1 million students and 1,800 schools. Even with them on a dedicated shard, it's quite possible that it'd get overloaded and we'd be spending more dev effort figuring out how to safely split them onto multiple shards.

When we looked at using distributed SQL database instead it was a clear win - from the application's perspective, it just looks like a really, really big PostgreSQL box, so we didn't need to change much. (the SQL support is very close to PG - The most annoying thing for us was the lack of trigram indexes, and Cockroach has now added those now). And in terms of the operational side, upgrading and maintaining CRDB has actually been easier than PG - version upgrades are easier to do without downtime, and schema migrations don't lock tables.

We moved took a large working PostgreSQL app and switched it over to CRDB and that doesn't match my experience. Our existing schemas and query patterns moved over nicely - latency for small indexed reads and writes did increase from ~1ms to ~3ms, but the max throughput now effectively unlimited since we could add capacity by adding new nodes into the cluster and letting CRDB automatically rebalance the workload. There was an increase in cost as it will need more cores, disk etc compared to a single-primary PostgreSQL, but that makes sense when you consider that every bit of data is getting stored on 5 different nodes and there are overheads to maintain the consistency.

For the highest throughput endpoints we did make some changes to be more optimal on CRDB so we could run a smaller cluster, but it didn't require anything close to a rewrite.

They would have to have many shards per city to keep up with the level of write traffic though. And what happens when a user from SFBA goes down to LA?