d4mr

I got mass nerd-sniped by Anthropic's performance engineering challenge this week and fell down the rabbit hole. This is Part 1 of a series breaking down the problem from first principles, what the simulated machine actually does, why instruction packing is hard, and where the optimization opportunities are. Built some interactive visualizations to make the concepts click (SIMD vs scalar, dependency graphs, the gather bottleneck). Currently at 2,375 cycles on the leaderboard. Planning to go deeper into tinygrad's approach in Part 2, their linearizer gets 1,340 with a "fairly generic backend" which is wild.

Author here. Was building an indexer to correlate Hyperliquid L1 transfers with HyperEVM transactions. The official RPC gave me one hash, but block explorers couldn't find it.

Turns out: Hyperliquid publishes block data to S3, and system transactions don't have hashes. nanoreth (which explorers use) has to recompute them, but uses a different encoding convention. they stuff the system address into the signature field as a "pseudo transaction."

Neither is wrong exactly, but if you're building tooling you need to know which convention your data source uses.

riveter could potentially evolve to extract high-signal compressed context out of these files. Kind of like building a RAG but modernised for long context LLMs. The compessed context would ideally just be the API exposed from the file. All function/method signatures, and comments that describe what the function body does. not sure if I'll ever get around to doing this though. There's lots of tools that try to do this advanced stuff (I see you have built one yourself). I'd imagine having riveter as the "dumb" CLI version of these tools. Do one thing and do it well.

not surprised, I agree the decision makes sense for them. It's just an unfortunate situation for the community. We don't know what the BUSL license would entail, and an open-source fork is unlikely to receive a lot of contribution (if historical contribution data is anything to judge by)

I just finished rearchitecting a core service at work to use NATS for distributed state. Really unsure about the viability of NATS as an open source product if Synadia stops contributing. It's making me reconsider our architecture change, maybe we should stick with a more stable (albeit less aligned) alternative.

summarising some context for folks;

From Synadia's Cease and Demand Letter:

> As should be clear, the NATS.io project has failed to thrive as a CNCF project, with essentially all growth of the project to date arising from Synadia’s efforts and at Synadia’s expense. It is for this reason that Synadia requests to end its relationship with the Foundation and receive full control of the nats.io domain name and Github repository within two weeks.

From Synadia's exit proposal:

> We propose that NATS.io exit from the CNCF Foundation effective immediately... Upon leaving CNCF, Synadia will adopt the Business Source License (BSL) for the NATS.io server... specific use cases (such as offering NATS as a managed service or integrating it into specific commercial offerings) will require a commercial license.

From CNCF's response:

> Let's be clear: this is not a typical license change or fork. It's an attempt to "take back" a mature, community-driven open source project and convert it into a proprietary product—after years of growth and collaboration under open governance and CNCF's stewardship.

Primary sources:

- Synadia's Cease and Demand Letter: https://github.com/cncf/foundation/blob/main/documents/nats/...

- Synadia's Exit Proposal: https://github.com/cncf/foundation/blob/main/documents/nats/...

- CNCF's Response: https://www.cncf.io/blog/2025/04/24/protecting-nats-and-the-...

Got it first try! Would be cool to play past archives