A deep technical walkthrough of benchmarking ERNIE 5.5 Flash Base's 280B-parameter/14B-active MoE at 1M-token context, separating per-token FLOPs from KV-cache bandwidth costs.
A deep technical walkthrough for JavaScript teams on designing and testing a failover deployment path when Vercel experiences outages, covering multi-target deploys, artifact portability, rollback automation, and vendor-risk reviews.
A deep technical walkthrough of diffing Zyxel GS1900 firmware to verify whether Patch 3 actually closes the root RCE that survived an earlier fix and enabled active attacks.
A technical breakdown of Discord's Rust desktop rewrite that explains why working-set measurements matter more than headline RAM numbers when comparing Electron, Rust, and webview-based desktop clients.
Discord's Rust desktop client is being quoted at roughly 290MB of RAM, and that figure is being used to settle the Electron argument. This video doesn't argue the number up or down — it shows what to measure instead. What the video covers: - Why a single idle-RAM figure from an unnamed build, at an unspecified uptime, under an unspecified workload tells you almost nothing about framework cost. - Why summing WorkingSet64 across a Chromium process tree counts shared pages (binary, ICU data, fonts, V8 snapshot) once per process, which is how most "Electron is using 2GB" screenshots happen. - The counter to use instead: summed private working set across the process tree, sampled over time, read with Get-Counter's Working Set - Private rather than Get-Process. - Why Task Manager, Activity Monitor and ps disagree on the same app, and why mixing tools means you measured the tools. The post also walks through the repeatable rig: a fixed workload script (launch, idle, open a channel with history, join voice, hands off), a thirty minute sampling loop, and the slope calculation that separates a large baseline from an actual leak. Sample output in the article is labelled illustrative — there is no measured Discord-versus-X benchmark there, and the numbers the outlets repeat are separated from what is confirmed reporting. Every command runs against your own app: performance counters on Windows, smaps_rollup on Linux, footprint on macOS. Full write-up: https://hackyjs.com/posts/electron-vs-rust-desktop-memory-measuring-working-sets-instead-of-trusting-290mb-headlines
The reported 10x saving from self-hosting GLM-5.1 instead of paying Claude API rates is a utilization claim, not a hardware claim. This video walks the arithmetic: an 8-GPU node rented at $2.50/GPU-hour costs $20/node-hour, and that hourly price has to be divided by the utilization you actually sustain. At 100% utilization the coding workload (40k input, 1.5k output, 80% cache hit) comes out about 9.4x cheaper than Sonnet list prices. Break-even against those list rates is 10.6% utilization — 7.0% on owned hardware at $13.15/node-hour, and above 20% if the API side uses Batch pricing. At 5% utilization the API is ahead by roughly 2.1x. Traffic shape moves the number: input-heavy retrieval breaks even near 6.7%, while agentic loops with long outputs need 14.9%. Decode has about 5.4x headroom over the API output price, prefill about 13.6x — long outputs are the worst case for self-hosting, not the best. The post also lists the seven numbers you'd need to audit any '10x cheaper' claim, including prompt cache hit rate and sustained utilization across nights and weekends. Throughput figures are stated assumptions, not benchmarks of GLM-5.1; the arithmetic is exact. Full write-up: https://hackyjs.com/posts/break-even-math-for-self-hosted-glm-51-gpu-utilization-ops-overhead-and-claude-api-rates
A technical walkthrough of how to take what lands in Safari Technology Preview 256 without regressing stable Safari users. The post separates what the public record confirms from what it doesn't. Confirmed: Apple publishes per-build WebKit release notes grouped by area, and a community write-up compares TP 256 against TP 255. Not confirmed at time of writing: the itemised diff, the WebKit build identifier, which items are on by default versus behind a preference, and whether any item has been reverted on trunk. So you extract those yourself instead of trusting a summary, including this one. What the video covers: - Why a preview build is a signal about where WebKit trunk is heading, not a support matrix entry - Saving the adjacent release-note pages for builds 255 and 256 and diffing them mechanically with a small Node script that classifies items into features, behavior changes, vendor-prefixed work and fixes - Cross-checking every added item against the WebKit commit log, MDN browser-compat-data and the WPT dashboard - Reading pref state from the release-note wording: enabled by default, behind a preference, or an ambiguous bare 'added support' - The adoption rule: adopt a preview feature only when a second engine ships the same behavior, backed by behavior-based feature detection and a tested fallback - A WebKit CI lane that catches the regressions preview-driven code actually produces Full write-up: https://hackyjs.com/posts/adopting-safari-technology-preview-256-without-breaking-stable-safari