isignal

Some individual has an understanding of each of those areas. Why does one individual need to know the entire food chain? The discussion point is about each specific area.

Even for the COBOL based systems someone understands it well enough at the conceptual and business level. And when there's no one to the company migrates and modernizes.

You are conflating the subject matter expert who understands one area well and others not so well with a general newbie who understands nothing well

One explanation could be that they know Western consumers will never use the llms directly, so they can open weight the models and collect licensing fees from hosting providers in US who run it. Moonshot seems to have such terms in their open weights releases.

But it does not explain publishing techniques like the ones referenced here in this article.

You can use a distributed database like yugabytedb or crdb. They are horizontally scalable, support postgres (yugabytedb has much better postgres compatibility). Yugabytedb also supports the Cassandra API.

Two concurrent deductions of inventory do contend but only during the actual DB update. That is just normal DB locking for SQL isolation levels. The blog refers to explicit locking by the app, which is where skip locked comes in.

Yes, at a high level. It doesn't rely on skip locked, which is not cheap at DB level. DB has to still typically run query and keep going until it finds an unlocked item. Deducting and checking inventory counts are simpler ops inside the DB.

It seems there could be a simpler solution.

1. Deduct the reservation from the inventory when the user starts to order, but in the same txn also maintain a separate row for the in progress order flow. 2. If the order flow is aborted or times out have a background process that returns these to the inventory.

That seems simpler than this approach and involves no locking. Though their presented approach is also reasonable, there must be some reason not to choose a simpler flow. It is not that difficult to have a gc service that scales, but may be they didn't want to separate that.

The EB5 visa, by comparison, has much more clear requirements. It is not sure if this intended as a backdoor to EB5 or a replacement.

There already was such a system with more concrete requirements. It is called the EB5 visa and has a path to green card. What does this new method bring to the table?

Processes can die independently so the state of a concurrent shared memory data structure when a process dies while modifying this under a lock can be difficult to manage. Postgres which uses shared memory data structures can sometimes need to kill all its backend processes because it cannot fully recover from such a state.

In contrast, no one thinks about what happens if a thread dies independently because the failure mode is joint.

Thanks for the pointers!

Aren't the alternatives you mentioned - icerberg and duckdb - both storage solutions while spark is a way to express distributed compute? I'm a bit out of touch with this space, is there a newer way to express distributed compute?

The transaction log maintained from time 0 would be equivalent but too expensive to store compared to the tables.

Resale values are lower in US because they factor in the 7.5k USD tax credit and the state tax credit mostly, there is plenty of demand for used teslas for example.