Ever wonder what really happens inside the model when it picks the next word? This one runs a real GPT-2 in your browser. Type your own sentence and follow it: embedding, the query-key-value split, attention between words, then the probability of the next token. Drag the temperature slider, you will feel what sampling does.

We all know 0.1 + 0.2 is not 0.3. But if you add money in cents all day, how wrong can it get? The OP proves the sum is off by at most one ulp, then plots it and gets a checkerboard, because the error of both inputs and of the add itself interfere. 2Sum in the appendix gives you the exact error.

Everyone is talking about Jev this week. The OP is not impressed, so they did it in 25 lines: prompt a small Qwen with A/B/C choices, read the logits of only those three tokens, normalize. That is the whole thing. It is a parody post, but you learn more about logits here than in most serious ones.

The biggest brokerage in Iran pushes 1,900 messages a second to tens of thousands of open connections, on 6 pods with 55MB RAM each. Kafka at the door, Redis Pub/Sub for the fanout, plain SSE to the client. I like the reasoning: a price is not an event you must keep, the next update replaces it anyway.

Do you wrap your page in a div with height: 100vh; overflow: auto? Then you already gave up scroll restoration, keyboard scrolling, window.scrollY, pull to refresh and the collapsing address bar on mobile. A nested scroller gets none of it. Even overflow-x: hidden on html does this. Use min-height: 100svh and overflow-x: clip.

Read a 256MiB file 4KiB at a time and that is 65,536 reads, but you do not feel it, because the kernel guesses ahead and grows the window as you keep going. Worth knowing the knobs: POSIX_FADV_SEQUENTIAL doubles it, POSIX_FADV_RANDOM kills it for index lookups, and DONTNEED only drops clean pages, so fsync first.

A flat page table would need 256GiB per process, so x86-64 splits the address into four levels of 512 entries, and one mapped page costs about 12KB. Then you see why TLB and working set matter, what your process really gets from fork before the first write, and why mmap skips a copy but pays a fault.

Their router kept dozens of consistent hash rings with 160 points per server, up to 6GB a box. A bit of math shows the last 90,000 points only buy you 0.7% better distribution, so 160 became 16. They also squeezed the struct into 6 raw bytes to beat Rust alignment. 100TB of RAM back. Math pays.

Deleting the old rows cost them more than running the workflow. Two things to learn: ON DELETE CASCADE scatters your deletes all over the pages, and an index knows nothing about visibility, so millions of dead tuples at the head of it made one lookup take 20 minutes. Drop the FK, batch it, vacuum around it. 10x.

Where does Postgres keep a row lock? Not in any lock table. It writes the xid into the row’s own t_xmax, the same field a delete uses, with infomask bits for the mode. Two lockers do not fit, so it allocates a multixact. That is how inserting children under a long transaction bloats pg_multixact.

A GitHub issue title went straight into a shell run: step. The sed escaping ran after the template expanded, so it escaped nothing, and one quote in a title was enough to walk away with their Jira token. GitHub Advanced Security did not catch it. Lesson: github.event is user input, put it in env first.

A 4B model with LoRA, trained with the reward being simply how fast the plan runs, and 44.7% lower latency on the Join Order Benchmark for $1,200. But read it for the measurement part: four pinned containers, interleaved candidate and default runs, a tie zone so noise cannot look like a win. That is the hard half.