61–64 of 64 posts
Earlier quoted context omitted.
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!
I went to https://sim.tigerbeetle.com/#evolution but nothing happened.
Earlier quoted context omitted.
Oh the sprites are great, don't get me wrong, but I mean how the graphical game system was made.
We use NanoVG: https://github.com/fabioarnold/nanovg-zig
Earlier quoted context omitted.
We use NanoVG: https://github.com/fabioarnold/nanovg-zig
Nice! Looks pretty rad. I've never used Zig but it sure looks like an interesting language. Did NanoVG help with the animation stuff like the little text that pops out of the beetles and the lines that zip between them?
{ vg.save(); defer vg.restore(); // undo all transformations at the end of the block
vg.translate(...);
vg.rotate(...);
vg.scale(...);
// draw spriteEarlier quoted context omitted.
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…
> 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)? 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 r…
Yes, and in fact we do this already in TigerBeetle (specifically towards solving misdirected I/O, along with hash chaining). Coincidentally, we used to use Blake3 but have since moved to AEGIS for hardware acceleration.
However, and this begins to hint at the problem, but redundancy alone is not sufficient. For misdirected I/O, we are already encoding more into the checksum...
And, PAR goes beyond this. For example, how do you disentangle corruption in the middle of the committed write ahead log, from a torn write at the end of the WAL due to power loss? For this, to solve this correctly (to decide whether to repair a committed operation or truncate an uncommitted operation respectively, for correctness and high availability), you really do need two WALs... and integration with (or awareness of) the invariants of the global consensus protocol—as the paper motivates.
This is a foundational design change.