From a senior to future senior Hackers

Latest Posts

View all posts →

Latest Videos

View all videos →
Verifying a Patched Brotli Decoder in Node.js and .NET

Verifying a Patched Brotli Decoder in Node.js and .NET

Release notes say the Brotli flaw is fixed. That describes a source tree, not the binary your process is executing. This walkthrough is a method for verifying the decoder fix yourself in Node.js and .NET: check what each runtime actually vendors, hash the executable and the native compression library instead of trusting a semver, and drive a crash-only harness that spawns a child process so a decoder memory bug cannot take down the test run. From there, differential runs of the old decoder against the new one on the same bytes, an output cap you enforce in your own code, and a read of the real patch diff. The post is explicit about what the reported Brotli issue does not include: no CVE identifier, no vendor advisory, no affected version range, no proof-of-concept input, and no statement of bug class. Those gaps are named rather than filled in, so treat every detail here as scoped to a lab. All of it is defensive: generate your own hostile inputs, run them against builds you control, and measure what the process does. One architecture claim is checkable in seconds: both runtimes link the same upstream C decoder rather than reimplementing it, which is why one flaw becomes two very different patching problems. Read the full write-up: https://hackyjs.com/posts/verifying-a-patched-brotli-decoder-in-nodejs-and-net-without-trusting-the-changelog

nodejsdotnetbrotli
Why parallel agent orchestration costs more tokens than it saves: DeepSeek's Super-Agent

Why parallel agent orchestration costs more tokens than it saves: DeepSeek's Super-Agent

DeepSeek's reported Super-Agent architecture is about running multiple tasks in parallel. Parallel execution is a latency technique: it doesn't reduce the work performed, and under a token-billed API it usually makes the bill larger. This video follows the write-up's token-cost model for scheduler/worker fan-out: the shared prefix that gets duplicated across workers, the coordinator whose input grows on every merge turn, the synthesis pass that scales with total worker output, and retries or re-plans that can cost more than the original fan-out. Then it shows the Node.js harness that makes the claim testable: a single wrapper recording usage per call, a phase breakdown so you can see where the tokens went, a single-agent baseline, and a fan-out runner with a hard concurrency cap. The numbers shown are the post's dry-run arithmetic, not observed billing: an 1,800-token shared prefix fanned out to 8 workers duplicates 14,400 tokens; 3 merge rounds over 8 workers emitting 400 tokens each re-reads 9,600 tokens; at a 10% per-worker failure rate the expected worker calls are 8.9. The post is explicit that the architecture claim comes from two November 2026 reports and that the arithmetic is the author's. Three implementation choices could weaken the model: hoisting shared context into the coordinator, dropping the synthesis pass, and cache-friendly prefix ordering that lowers the price of duplicated context without lowering the token count. Read the full write-up, including the harness code: https://hackyjs.com/posts/why-parallel-agent-orchestration-can-cost-more-tokens-than-it-saves-testing-deepseeks-super-agent

deepseekai-agentsorchestration
Three.js r187 and the Tooling Gaps Between Browser 3D and Native Rendering

Three.js r187 and the Tooling Gaps Between Browser 3D and Native Rendering

Three.js r187 is evidence the browser 3D runtime is credible, not that the tooling has reached parity. This short covers pinning the revision, sampling renderer.info after warm-up, the WebGL and WebGPU split, and where asset pipelines, profiling, shader compilation, and GPU disposal still bite. Read the full write-up: https://hackyjs.com/posts/threejs-r187-and-the-tooling-gaps-between-browser-3d-and-native-rendering

threejswebgpuwebgl