I've been reading Out of Control and it's absolutely fascinating. It's amazing that it's from 1993. I've been taking notes, so that writeup is coming. One thing that I kind of wanted to play with is the Prisoner's Dilemma game players. I understand the concept of adapatability, but I need to figure out how to express that in software.
I'm basically impossibly far behind on class. I think I'm going to have to bail on it and go for the sensor fusion class, which is not a set duration. I think I'm going to save the problems and go back and work on them after the fact.
The Jetson Nano shows up today; I still have to test out the framebuffer on the M5K. And I have to clean for the 4th.
This weekend I started on a write up for the "Fast key-value stores" paper, but I didn't quite get it done. My initial thought is that this is something that applies to Google, maybe, but not necessarily to everyone else. My intuition is that the performance hit from using a remote in-memory kv store just is probably not a high priority problem in most places, especially not balanced against the cost of building and maintaining a custom store. I never looked much into foundationDB, but I think (weakly) that it's a distributed SQLite, which might basically serve the same function. I think the biggest gain from the paper would be local caching of data, and I'm not sure to what extent FoundationDB does that. I'm not sure what a typical store size would be, but from past experience, it's under a gigabyte, which is tenable to store an entire copy locally - and I assume (quite possibly wrongly) that a distributed SQLite would have a way to share deltas , so there would an initial sync period for a new worker where the data wouldn't be local, and then it would be relatively in sync. In the past, I've used the remote KV store for both global things (e.g. a CSRF key) and for per-session stuff. As far as the per-session stuff, the work using the request data would have local access, assuming it created the data. It might be that the cost of reliably syncing this data isn't worth the trouble of the network roundtrip, and operations teams would probably have less experience with it.
It'd probably be better to invest the time in a custom library that does the translation, and then maybe keeps a local cache. There's still the sync question, though.
Anyways, this will all be in my writeup.
|||You simply just float it on a Raft, right?|