Projects

nodejs-k8s124 stars · JavaScript · public

Kubernetes' core APIs reimplemented in Node. Point your real kubectl at it and it answers.

A single-process, single-node stand-in for kube-apiserver: state in MongoDB instead of etcd, "pods" as sibling Docker containers on the host. Around 55 resource kinds are routed; the ten that matter (Pod, Deployment, ReplicationController, Service, Endpoints, ConfigMap, Secret, Node, Namespace, Event ) have real lifecycle behaviour, and the rest round-trip as API objects. Init containers, exec/httpGet/tcpSocket probes, label and field selectors, watch streams, and all three patch types work.

The hard part wasn't the schemas. It was aggregated discovery, server-side table printing, the k8s\0-prefixed protobuf envelope, and the scalar coercions where a resource limit sent as a plain string decodes as zero on the client instead of erroring.

Write-up: kubectl didn't format that table →

KestrelSwift · WebKit · not yet public

A macOS browser that holds whatever tab-memory budget you give it; at 800 MB it destroys zero tabs where discard-LRU destroys five.

About 7,900 lines of Swift on WKWebView. Background tabs are demoted down a ladder of measured states rather than being killed outright, so the browser stays under a budget you set the way a game engine stays inside a frame budget. Restore from a hibernated tab takes 82 ms, and p95 restore latency is lower than discard-LRU's because deserialising a session image beats refetching the page.

It also falsified its own design. Simulation predicted 7.9–11.5× less memory than an unmanaged browser; the real engine delivers 1.4–2.6×, because the simulation priced a hibernated tab at 32 KB and WebKit charges 39 MB, because the renderer process survives and can't be terminated on request. That one number, wrong by three orders of magnitude, explains the entire gap, and it produced a budget feasibility rule the simulation never surfaced.

Write-up: I priced a hibernated tab at 32 KB →

reckonerResearch · not a public repo

Fifty-plus experiments asking whether language-model capability really needs billions of parameters, and what today's largest models cost to run on modest hardware.

The strand with the sharpest result is a cost model for streaming a mixture-of-experts model's weights off an SSD. It was gated twice against systems I had nothing to do with: it reproduces a third-party runtime's on-disk container byte-for-byte from config alone (expert stride 1,769,472, per-layer blob 452,984,832, exact integer equality) and predicts an unrelated model's on-disk size, converted by different people with a different tool, to 1.1%.

Then it met the machine. Running a 276B-parameter model from SSD, the bytes-per-token prediction held under an independent method (kernel page-in counters against config arithmetic); the tokens-per-second prediction missed by 23×, because the model had declared that it did not account for compute and compute was what bound. On the way there, the SSD benchmark turned out to be measuring RAM.

Not under version control and holding ~119 GB of model weights, so there's no repo to link. The write-up is the artifact.

Write-up: wrong by 23×, exactly where I said I'd be →

social-deduction-benchJavaScript · public

Social deduction as an LLM benchmark, scored per turn and corrected for chance rather than ranked by win rate.

Language models play Mafia against each other, but nothing here ranks them by whether they won; a seven-player game is mostly variance, so win rate over any affordable batch mostly measures luck. Instead every town player makes a public accusation per statement, and because the engine knows both the ground truth and the exact probability of hitting a Mafia by chance for that turn's roster, accuracy minus that baseline gives detection lift: a signed number with a meaningful zero and 15–25 samples per game instead of one bit.

522 games across 19 models and 3,368 individual accusation records. Detection lift rises with game day (about zero on day one, then +0.13, +0.23, +0.26) and the rule-based control has not been beaten. The most useful finding is a correction to itself: the control scored +0.293 over twelve games and +0.071 pooled over 434, which is the project's own evidence that twelve games can't pin a policy down.

Concept, research questions and system design are mine; much of the implementation was AI-assisted. Findings are exploratory.

webCrawlerJavaScript · MongoDB · public

A search engine (crawler, inverted index, BM25 ranker) with no search library.

A cluster-based crawler pool scaled to available memory pulls URLs from a MongoDB frontier, parses with jsdom, and updates a hand-built inverted index ({ docId, tf, len } postings plus document frequency per term). search.js scores with a hand-implemented BM25. The tokenizer is shared between indexing and search, because those two have to agree exactly.

It also has a hand-written robots.txt parser and a politeness limiter that survives a hundred concurrent worker processes, which took three attempts, since the first two enforced a perfectly correct delay while the crawled host received a hundred simultaneous requests. The tests assert on what the crawled server received rather than what the limiter returned.

Write-up: my crawler's rate limiter was lying to me →

video-timelinePython · public

Hands a video to a language model as a measured timeline, not a pile of screenshots.

Sampling N frames from a video loses the thing that matters: a screenshot says nothing about when it happened, how long after the last one, or whether the camera moved or the subject did, so the gap gets filled with a plausible story. This turns an MP4 or MOV into timestamped intervals with shot boundaries, camera-motion vectors, on-screen text and audio activity attached, so the model reads intervals instead of guessing between samples. Python over ffmpeg and Tesseract.

No sample video ships with it, which is deliberate: the fixtures are generated, so the harness builds a clip whose contents (title cards, hard cuts, a fade from black, a pan, frozen frames, tone and silence) are known in advance and the detector's output can be checked against them rather than eyeballed.

sql-nodejsJavaScript · on npm · public

An in-memory SQL engine with a hand-written parser and genuinely zero dependencies.

Parses SQL strings and answers SELECT with real column projection over its own table and row storage. "Zero dependencies" is checkable rather than aspirational: both dependencies and devDependencies are empty, and the tests run on Node's own built-in runner in CI.

Deliberately small, and the README says where it stops rather than leaving it to be discovered: one column=value equality per WHERE, one row per INSERT, no joins, updates, deletes or aggregates.

Postmastr-Backend3 stars · JavaScript · public

A mailroom tracker that reads a shipping label off a photo and emails the recipient.

Tesseract.js OCR over label images, wired into a Node/Express and MongoDB backend. Built for the problem of a package arriving and nobody knowing whose it is.