51–60 of 64 posts
Earlier quoted context omitted.
There are tools in the upper right corner. You can pick one and use it on a beetle. ;) This introduces various faults in the simulation that the database has to recover from. Minor spoiler: there's another tiny game hidden at the end of the third level.
Out of curiosity what did you use to write the graphical part of this game?
Earlier quoted context omitted.
never played "walking simulators" then? plenty of games don't feature traditional win-lose mechanics.
No, I hadn't even heard of that genre. They sound potentially fun, though, since at least they have an environment to explore.
Only if the setting is something other than present-day reality - after all, the genre is called "walking simulator", not "trespassing simulator".
This is pretty cool from a database perspective but I'm really interested in what they used to write this 'game.'
It's covered a little bit in the Evolution section (add #evolution to the URL and hit enter). If that doesn't answer everything (it's not a long section, granted) Fabio (captainhorst) is on HN answering questions in this thread already so feel free to ask!
Earlier quoted context omitted.
Thanks, great to hear you enjoyed it! The round robin "view change" in VSR is still consensus, and uses quorums to do fault isolation of the old primary, and to preserve the intersection property, to ensure that the committed log survives into the new view. What's cool about VSR's consensus though, is that the dice is also preloaded, ahead of time, so that there's more information baked into the protocol than with Ra…
Thanks for the details. A coworker pointed me at Heidi Howard (of Flexible Paxos, etc) and Diego Ongaro (Raft) discussing this very question! https://groups.google.com/g/raft-dev/c/cBNLTZT2q8o?pli=1
(TB implements Flexible Paxos and we're fans of Heidi Howard's work!)
This is awesome!
This is insanely cool!
> Sure, we’re not yet injecting storage faults, but then formal proofs for protocols like Raft and Paxos assume that disks are perfect, and depend on this for correctness? After all, you can always run your database over RAID, right? Right? > If your distributed database was designed before 2018, you probably couldn’t have done much. The research didn’t exist. I'm trying to understand this part but something seems of…
Not an expert in this area, but I think disks have correlated failure modes whereas CPUs and memory generally don't. Especially spinning platter disks, not sure about SSDs. The difference in failure rates could be orders of magnitude ... Memory will have random bit flips but I think they are pretty randomly distributed (or maybe catastrophic if there is some cosmic event) But disks will have non-random manufacturing…
Cosmic rays cause random bit flips, sure.
However, DIMMs going bad results in the same areas corrupting over and over. If you've run memtest or such with bad DIMMs, you'll see it telling you exactly which DIMM is bad, etc.
Now, dynamic memory management and virtual memory mapped onto physical memory complicate that picture... but you could easily end up with a single buffer used for e.g. TCP receive that lives in the same physical RAM region for the lifetime of the process.
Similarly, firmware bugs have resulted in very deterministic corruptions.
Earlier quoted context omitted.
Thank you for the detailed response! > However, while checksums can be used under the “Crash Consistency Model” to solve consistency through power loss, PAR showed that checksums are not sufficient to be able to distinguish between a torn write at the end of the (uncommitted) WAL caused by power loss, and a torn write in the middle of the (committed) WAL caused by bitrot. The PAR paper states that "although Crash pre…
Huge pleasure, thanks again for the question! The crux of the problem: How do you solve misdirected read/write I/O? Where the firmware writes/reads to/from the wrong disk sector (but with a valid checksum)? PAR shows how both global consensus protocol and local storage engine need to be modified for this, with foundational design changes at the protocol-level, if a distributed system is to not only preserve correctne…
Can't you make the expected location of the data part of the checksum?
Concretely,
- switch from checksums to hashes
- use something like Blake3 as keyed hash with the WAL offset as key.
Now, you can't accidentally read WAL block #5 instead of #7, as it's recorded hash won't match H(data, key=7).
Similar more old school technique: storing the expected role & id of a block inside the block can make storage more robust.
Earlier quoted context omitted.
They're handmade by Joy Machs! We credit him in the post. :) https://twitter.com/joymachs
Oh the sprites are great, don't get me wrong, but I mean how the graphical game system was made.