But I don't see any of those having impacted the California High Speed Rail. Rather that has been harmed by lots of different groups throwing roadblocks up, sometime for ideological reasons (lots of this from State and National Republicans, sometimes with reasons, but often more political), and a whole lot of NIMBY (see: Palo Alto). What do you see the Boring Company having to do with that?
As a side note: there are some really poorly thought through parts of the project, for example they don't have a plan for actually making it over the mountains into Los Angeles. I still want it to happen, but...
You can use ent ENV variable UV_CONCURRENT_DOWNLOADS to limit this. In my case it needed to be 1 or 2. Anything else would cause timeouts.
An extreme case, I know, but I think that uv is too aggressive here (a download thread for every module). And should use aggregate speeds from each source server as a way of auto-tuning per-server threading.
And centuries of liberal democracies where the church was just one institution that had no direct rule over its subjects?
In general, the Church's political power has waned over the last 500 years or so, but there are an awful lot of calls from Republicans saying that this is where we have gone wrong.
One only look to the political donations of Opes Dei (Catholic branch dedicated to getting Cristian influence over the "Lay" sphere) to see them as major power players today. The Heritage Foundation (main writers of Project 2025) are intimately bound with the organization. And Chief Justice Roberts is also associated.
So they may not be "direct" rulers, they are major power players.
How you reconcile many copies of the same record could depend on time of action, server location, authority level of the user, causality between certain business events, enabled account features, prior phase of the moon, etc.
Whether or not offline sync can even work is very much a domain specific concern. You need to talk to the business about the pros & cons first. For example, they might not like the semantics regarding merchant terminals and offline processing. I can already hear the "what if the terminal never comes back online?" afternoon meeting arising out of that one.
But living inside of those rules (and sometimes just understanding those rules) can be a big ask in some situations, so you have to know what you are doing.
What I’d really like is an easy way to sync the SQLite database state to a cloud service. Most existing options expect you to query against a remotely hosted database and charge per read/write.
Since the database will have around 100,000 rows and you're typically working with all the data at once, streaming parts of it doesn’t make sense for my use case.
The closest I’ve found is Turso, which has offline writes in private beta, and SQLite Cloud, which lists local-first and offline sync as "coming soon."
The simplest approach might be letting users push to S3 storage with versioning. Ideally, it would also support point-in-time restores, tracking incremental updates alongside full snapshots.
Even better, I’d manage minimal server-side infrastructure and just pull the SQLite database from a service that handles syncing and management.
The one I thought of (mostly because I worked there before they went under/bought by MongoDB) is RealmDB: https://en.wikipedia.org/wiki/Realm_(database)
I have long since lost touch with the state of it, but at the time the syncing to their server was fast and had worked with a long list of environments/languages.
The one thing I will caution: their model was that you almost had to have a database-per-customer. You could have a second one that contained common information, but they had no concept of only syncing part of a database based on some logic. So many customer implications had the clients syncing multiple databases, and then a back-end client that would aggregate the data from all of those databases into one for backend processes. Extra complexity that I always thought was a real killer.
Also, the capital gains taxes ARE low and the income taxes ARE high, so just paying down the debt isn't nearly so "even-handed" as it seems.
Personal income taxes are the larges revenue source for the U.S. Government, so it is the main way we have decided to tax ourselves. Arguably it is one of the most steerable, and we have long health that progressive taxation is for the common good (as much of a mockery as some high-income individuals have made of that).
So with that as the background, the U.S. ranks towards the bottom of the OCED countries in taxes vs. GDP. Yes we get less than the citizens of the countries paying the most, but not that much less.
https://taxpolicycenter.org/briefing-book/how-do-us-taxes-co...
https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail
It is not that `set -e` is bad, it is that bash is a bit weird in this area and you have to know when things eat errors and when they don't. This is not really changed by `set -e`: you already had to know them to make safe code. `set -e` does not wave a magic wand saying you don't have to understand bash error control.
But having `set -e` is almost universally better for people who do not understand it (and I would argue also for people who do). Without it you are responsible for implementing error handling on almost every line.
As other have already said: this is one of those things that generally pushes me to other languages (in my case often Python), as the error handling is much more intuitive, and much less tricky to get right.