The data-race-free memory model was an observation back in the early 90's that a correctly-synchronized program that has no data races will, even on a weak memory model multiprocessor, be indistinguishable from a fully sequentially-consistent memory model. This was adapted into the Java 5 memory model, with the happens-before relation becoming the definition of correctly-synchronized, and then C++11 explicitly borrowed that model and extended it to include weaker atomics, and pretty much everybody else borrows directly or indirectly from that C++ memory model. However, C++ had to go back and patch the definition because their original definition didn't work, and it took C++ standardizing a model to get the academic community to a state where we could finally formalize weak memory models.
In Java, happens-before is composed essentially of the union of two relations: program order (i.e., the order imposed within a single thread by imperative programming model) and synchronizes-with (i.e., the cross-thread synchronization constructs). C++ started out doing the same. However, this is why it broke: in the presence of weak atomics, you can construct a sequence of atomic accesses and program order relations across multiple threads to suggest that something should have a happens-before relation that actually doesn't in the hardware memory model. To describe the necessary relations, you need to add several more kinds of dependencies, and I'm not off-hand sure which dependencies ended up with which labels.
Note that, for a user, all of this stuff generally doesn't matter. You can continue to think of happens-before as a basic program order unioned with a cross-thread synchronizes-with and your code will all work, you just end up with a weaker (fewer things allowed) version of synchronizes-with. The basic motto I use is, to have a value be written on thread A and read on thread B, A needs to write the value then do a release-store on some atomic, and B then needs to load-acquire on the same atomic and only then can it read the value.
> To describe the necessary relations, you need to add several more kinds of dependencies, and I'm not off-hand sure which dependencies ended up with which labels.
No, that's not the thing I'm talking about. Those are the different ordering modes you can specify on atomic operations.
Rather, there's a panoply of definitions like "inter-thread happens-before" and "synchronizes-with" and "happens-before", and those are the ones I don't follow closely. It gets even more confusing when you're reading academic papers on weak memory models.
it builds as a docker image which has stockfish and maia (maiachess.com) together with different weights so it can simulate lower-level players.
It was a fun exercise, I tried a bunch of local models with this MCP server, which isn't particularly optimized, but also doesn't seem that bad. And the results were quite disappointing, they often would invent chess related reasoning and mess up answering questions, even if you'd expect them to rely on the tools and have true evaluation available.
It was also fun to say things: fetch a random game by username 'X' from lichess, analyze it and find positions which are good puzzles for a player rated N.
and see it figure out the algorithm of tool calls:
- fetch the game
- feed the moves to stockfish
- find moves where evaluation changed sharply
- feed it to maia at strength around N and to stockfish
- if these disagree, it's probably a good puzzle.
I don't think I got to have a working setup like that even with managed cloud models. Various small issues, like timeouts on the MCP calls, general unreliability, etc. Then lost interest and abandoned the idea.
It is shockingly difficult to use LLMs in chess study. I don't need it to be a better (or worse) Stockfish; an LLM should be great at taking a FEN or multiple lines from Stockfish via MCP or tool call and explain why positions are evaluated the way they are, typical plans in the position (drawing from pretraining knowledge of a vast archive of games), and how to explain to a human to study these positions.
I suspect that the large amount of chess pretraining data is not well synchronized with positions, because in books and articles the text is typically accompanied by pictures of the positions, NOT FENs / PGNs. So the training on the text is decoupled from the representation of the position.
Regarding your tool call thing with stockfish/maia, I made a tool like this for myself called Blunder Sniper which iteratively feeds positions - that I'm likely to get given my openings - and recursively calls the lichess DB and finds the first time in the top 80% played moves in each chain where the opponents in the rating range blunder as the most common move in the chain.
It was a fun way to use an alternative to engine-based preparation that many strong players use, which is something like Nibbler + lc0 and using contempt high values to find higher variance lines rather than game theory optimal ones.
Some day I'll expand on the gpt-chess articles [0] that I found super interesting, fine-tune models... well, I keep telling myself that, anyway...
Saying CI is a developer experience thing is completely misunderstanding the point.
AI workflows, vibe coding and such only emphasize the need for proper test suites and for a measured release process, where you don't actually delete your production databases on the whim.
It took me an embarrassingly long time to internalize what the reverse proxy is. My brain got stuck on the fact that it is just proxying requests. What's so reverse about this? Silly.
It's one of the classic cases of a thing being named relative to what came before it, rather than being named on its own merit. This makes sense to people working at the time the new thing is introduced, but is confusing to every other learner in the future.
Forward proxies, proxies where client machines were configured to route all their outbound traffic through (similar to a router). Usually performed caching back in the day when the Internet tube was slow, later on got SSL decryption capabilities and filtering lists to make sure you stay off of your naughty sites and so the proxy admin could decrypt your banking credentials.
Could be worse. All the many things named after people prevalent in some fields more than in others, biology/medicine for example. When you read, for example, "loop of Henle" or "circle of Willis" you don't even know where to begin. You either know the term or not.
True, though I think it's often a larger challenge to capture the intrinsic quality of a medicinal compound or physiological feature than a man-made tool.
How about service proxy vs web proxy rather than reverse proxy and proxy? Makes more clear that one is a proxy on the service side and the other is a proxy on the client side. Service proxy and Client proxy might be even better.
> "Closed platforms are going to lose to open ones that allow innovation"
Only if people (end-users) actually care. If you're trying to build against the momentum but misjudge your values for the community values, then you're in for a disappointment.
what a strange place to link to. Even Wikipedia has a better entry [1].
The model itself is fun to think about: preventing failures by stuffing more cheese into the system. If you're interested, the classic example of the cheese failure is Chernobyl, where many different things had to fail in order to become a catastrophe.
it's the latter: "you can actually start telling it to write a Playwright Python script instead and run that".
and while running the code might faster, it's unclear whether that approach scales well. Sending an MCP tool command to click the button that says "X", is something a small local LLM can do. Writing complex code after parsing significant amount of HTML (for correct selectors for example) probably needs a managed model.
