I have been looking for the same thing. I want to connect my 2 laptops to the same dell monitor via one usb-c port, charge them, use the mouse and keyboard attached to the monitor. Now I have to move the usb-c cable from one laptop to the other, which already started to leave a mark on the port enclosure.
Edit: the only ones I could find with usb c were full KVMs and far more expensive. I would guess a female usb c to male usb 3 adapter might be a cheap workaround.
Yes they are normally isolated, however its only at a READ_COMMITTED level, and a nuance of the implementation is that you may see committed data rolled back by the protocol in the event of a failure. Its still technically READ_COMMITTED, but its an unexpected behavior from stock MySQL so we make sure to qualify our documentation.
What you describe is read uncommitted. From your own docs:
> A third party that performs cross-database reads can observe partial commits while a 2PC transaction is in progress.
Regardless of rollback status, the in-flight transaction will not be observed correctly across shards, for example, with a cross-shard join. It doesn't matter what the consistency guarantee within a shard is; this is not ACID nor is it serializable.
Its not, its still read committed. Its the same thing as if you had to read from two rows in a transaction, and your isolation was read committed, and both those rows would be modified by a different transaction. Its possible you read the first row, a transaction is committed and then you read the second row with the updates from the transaction. You have just read a partial commit. It is ACID and it is not serializable, the thing is MySQL lets you use higher levels of isolation like repeatable read or serializable which are very useful and today Vitess can't guarantee that in a 2PC.
Y'all really should hire me at some point. I've been building out transactional analysis tooling for Jepsen that can help distinguish between exactly these cases. :-)
I may be just tripping over semantics here, but how can you consider data that may still be automatically rolled back to be “committed”? I thought that’s supposed to mean the data has been fully stored such that it can only be changed/removed by a subsequent transaction.
The data will be committed, but you may get a subsequent read that has the previous value, before it is overwritten by the final value. This would only occur if the shard where the commit is occurring fails, while the promoted shard replays the transaction before the final commit is propagated to the user. Since the shard as failed is impossible for a single transaction to experience this behavior, but an outside observer would be able to see this behavior. Transactionally everything would still be isolated, but outside the transaction you would see behavior you won't expect.
There have been talks at GDC and elsewhere about this...my memory is that humans don’t like being surprised by a smart AI that silently builds up resources and suddenly and mercilessly betrays and annihilates them, which is the obvious winning strategy. Humans don’t even like the random battle results to be truly random but expect them to hew very closely to the outcome of the odds as presented. The AI is grindy and unsophisticated on purpose.
I believe you're thinking of Sid Meier's GDC 2010 keynote "Everything You Know Is Wrong" [1]. The entire talk is interesting, but section on player perception of probability is about 20 minutes in.
One takeaway is to be careful about how strength numbers translate into odds. If your strength is 100 and mine is 1, does that mean I have a 1% chance to out-and-out beat you? Your armored tank shouldn't have an even 1% chance of being completely annihilated by my club-wielding warrior (that's somehow still around by then).
The later Civ games have taken odds out of the equation, and I think it's for the better. Instead, the amount of damage each unit takes per combat depends on the difference in their strength deterministically. From my own perspective, this is overall more fun than 'randomly' having really strong units lose against weak units occasionally.
> Humans don’t even like the random battle results to be truly random but expect them to hew very closely to the outcome of the odds as presented.
Because of this Civ2 added health and firepower stats to units, random battles sometimes meant an ancient trireme could destroy a battleship, which is fun to imagine...
The classic example is a militia (the weakest unit in the game, relying on no technology at all) defeating a battleship bombarding it from the sea, causing the battleship to sink. :D
Warriors should never be able to defeat a battleship in Civ2 because of the new combat system. The AI cheats (of course); I have had armor go down to knights on deity level
This is not correct; the weakest unit in Civilization is the militia, and the unit you get from gunpowder is the musketeer. There is no unit called "warrior".
How do I know we're talking about Civilization?
> Because of this Civ2 added health and firepower stats to units
I think it's unlikely Civ II added stats in response to feedback from Civ III.
I think it is fair to say that the Calvin paper is visibly incomplete and expresses some constraints in a way that makes them seem insurmountable when they are not; specifically, they are only constraints within the log, but do not constrain the database experience overall.
Applying Calvin to traditional RDBMS workloads was a very unlikely creative exercise because it required questioning these explicit constraints.
The Spanner paper also leaves a lot unexplained, but it is less obvious until you are too far down the path to turn back. After all, it worked for Google. Calvin did not have that real-world proof. Combine that with the pessimism of the paper itself and nobody was willing to pick it up.
> Are you certain a MySQL SLA-level support contract would have solved their scalability issues?
This pitch may have been mentioned in passing to me but I don't remember. From the perspective of I and many others who ultimately solved the scalability issues, the MySQL boat was simultaneously sinking and on fire, while nobody knew who the captain was supposed to be. An insurance policy that promised that somebody with a badge would dedicate 8 hours a month to buffing out scratches was not useful.
It was less "it's OSS, we don't need to pay" and more "only God can help us now".
