From a senior to future senior Hackers

Latest Posts

View all posts →

Latest Videos

View all videos →
Auditing Gatekeeper Dependencies Before EU DMA Cloud and AI Enforcement

Auditing Gatekeeper Dependencies Before EU DMA Cloud and AI Enforcement

A working walkthrough for auditing the gatekeeper dependencies in your stack before EU DMA enforcement changes provider behaviour. The 10% fine ceiling in Article 30 of Regulation (EU) 2022/1925 is not news — it has been in the text since 2022. What moves is the obligation schedule: once the Commission designates a gatekeeper, it has six months to comply, and that is the window where API terms, default bundling and interoperability endpoints change. In this video: - scoping the systems that actually sit behind a gatekeeper, across runtime, distribution, identity, data and model access - a YAML inventory where every dependency carries an evidence locator — the lockfile entry, the IaC resource, the DNS name - risk scoring on blast radius, switchability and contractual notice window - a short Node script that derives the mechanical half from your lockfile and infra files - why cloud computing is a DMA core platform service and model APIs are not — model risk lives in contracts and versioning, and that is a different instrument - two continuous checks: a terms-page hash diff and a CI gate on deprecation feeds and egress budget Code samples come from a synthetic fixture so the output stays deterministic. Regulation references are quoted or paraphrased from EUR-Lex. Full post: https://hackyjs.com/posts/auditing-your-stacks-gatekeeper-dependencies-before-eu-dma-cloud-and-ai-enforcement

eu-dmacloudai
Splitting Router and Worker Roles in a Node.js Coding Agent: Lessons from dsh-superagent

Splitting Router and Worker Roles in a Node.js Coding Agent: Lessons from dsh-superagent

Coverage of DeepSeek's dsh-superagent names a router-worker coding agent pattern. This short walks through the post's Node.js reference implementation: a router that decomposes goals and sets hard budgets, a worker with a filtered tool surface, and a typed handoff contract that returns artifacts instead of reasoning transcripts. The post separates what the coverage confirms from what is reconstruction, and explains why the split only pays off when the boundary is enforced in code. The before scene is a minimal single-loop illustration; the after scene uses the post's typed envelope. Full write-up: https://hackyjs.com/posts/splitting-router-and-worker-roles-in-a-nodejs-coding-agent-lessons-from-dsh-superagent

node-jscoding-agentarchitecture
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