dikei

The second issue is they're not completely equivalent. In the second case, you'd need extra memory for the `reentrantLock`, while `synchronized` works with any object. Furthermore, if you need to use `wait/notify`, then there need to be an extra `Condition` object to use in combination with the `ReentrantLock`. For sure, developers can rewrite most `synchronized` to use `ReentrantLock` and `Condition`, but javac won't do it automatically for you.

But of course, when you have thousands of Virtual Threads all deliberately pinning the carrier thread, you quickly run out.

However, it's built directly into the JVM specification, so it's difficult to change while keeping compatibility, while j.u.c.Locks is just a library. In other words, they can't change synchronized schematic, so they created j.u.c.Locks as a replacement.

Using Virtual Threads is a choice, it's not forced on to you.

Of course, the issue with all shared-storage systems is how much it costs to have a reliable and fast shared storage.

>> JIT, or “Just in Time” is a compilation design that implies that compilation happens on demand when the code is run the first time.

>> What people tend to mean when they say a JIT compiler, is a compiler that emits machine code.

A JIT compiler is a compiler that emits machine code the first time that code is run, vs an AOT compiler which emits machine code when the code is built.

Until someone accidentally run an expensive DDL on your Galera Cluster: now your cluster is down for hours without anyway to cancel that query except nuking the entire database and restore from backup.

That was the first thing come to my mind when I read the paper on Spanner and CockroachDB (haven't read the paper on YugabyteDB yet) though, and surely I'm not the only one.

* Web 1.0: independent websites, self-maintained, hard

* Web 2.0: hosted platforms like blogs and social networks, easy, but rely on providers

* Web 3.0: promise to free users from the platform providers but are mostly crypto scam currently.

I guess that's to be expected. Almost anything is more storage-efficient than Elasticsearch, FTS is so expensive.

>> The microcontrollers, running on PowerPC processors, received three commands from the three flight strings. They act as a judge to choose the correct course of actions. If all three strings are in agreement the microcontroller executes the command, but if 1 of the 3 is bad, it will go with the strings that have previously been correct.

This is a variation of Byzantine Tolerant Concensus, with a tie-braker to guarantee progress in case of absent voter.

Isn't this cause you to pay twice the already expensive Egress fee ?

In most of the world, SMS is billed per-message, so it's basically no extra effort on the Telecoms side at all. In fact, Telecoms' online charging systems are fast enough to calculate users' data usage by seconds in real time, so they don't even blink at counting SMS.

However, most of the time, we are fine with a bit of ambiguity. One of the amazing points of the current LLMs is how they can communicate almost like human, enforcing a rigid structure in command and data would be a step back in term of UX.

* Fabric: https://www.fabfile.org/

* Invoke: https://www.pyinvoke.org/faq.html

Probably just as other distributed systems implement replication: you have a leader to broadcast instruction and other followers applied the instruction to their local copy of the state.

However, there'll always be delay/stale data between the leader and followers. So, to improve performance, you can allow the followers to perform speculative decision based on their own calculation, but these local decisions will be overwritten / rollback by instructions received from the leader.

I wonder how Ruffle get it working so fast.

All pro-gamers train everyday to build this spray pattern countering movement into muscle memory. Of course, some are better than others.

If I understand this correctly, it deals with high cardinality by dropping data. The operators need to monitor for this and adjust their data to lower the cardinality.

This a zero-click exploit, which means you don't even have to open the message to get hacked.

I think you can't even do a new publish if all readers haven't finished switching to a new epoch after a previous publish. Otherwise, you risk corrupting readers that are still on the original epoch.