The device (BISC) is a single CMOS chip, thinned down to 50 μm, that slides into the subdural space (between skull and brain).

The specs are pretty wild:

Form Factor: It rests on the brain "like a piece of wet tissue paper."

Resolution: 65,536 electrodes with 1,024 simultaneous recording channels.

Bandwidth: 100 Mbps wireless link (custom ultra-wideband radio).

Power: Fully wireless via an external relay station.

The differentiator here seems to be the non-penetrating approach. Unlike Utah arrays or Neuralink threads that penetrate the cortex, this sits on top, which theoretically minimizes tissue scarring/reaction while maintaining high data throughput (100x current wireless BCIs).

Paper: Stable, chronic in-vivo recordings from a fully wireless subdural-contained 65,536-electrode brain-computer interface device

Building something similar - using Claude API to generate mini games from text descriptions (https://codorex.com, still pretty rough).

Can confirm: Claude is weirdly good at generating functional game logic from vague prompts, but spatial precision is a constant battle. Anything involving exact pixel positions needs validation/correction layers on top.

The suggestion upthread about having it write its own measurement tools seems promising - haven't tried that approach yet.

Actually, here's a relevant example - had Claude generate an interactive solar system with circular orbits and moons: https://codorex.com/shared/yeABdJWvRHAKqHs2kxpRnZNZPWmqWSu9

Interesting that it handles this fine (functional orbital mechanics, animation) but would probably struggle to recreate the exact pixel positions of the Space Jam layout. Confirms the pattern: good at "make something like X" but bad at "recreate X exactly."

This is really cool.

“It’s been wild to read endless online complaints from so-called ‘technical’ RPi users for the last 13 years about SD card wear and tear…”

A lot of the SD-card wear issues come from people running “normal PC workflows” on a storage medium that was never designed for that pattern.

Something I’ve seen help many newcomers is simply enabling an overlay filesystem or tmpfs-based writes. It’s basically the middle ground between a full RAM-boot distro (piCore, Alpine diskless, NetBSD) and a standard SD-based Raspberry Pi OS.

You still get the normal ecosystem and docs, but almost no writes hit the card unless you explicitly commit them.

For anyone stuck between “I want something simple” and “I don’t want my SD to die,” overlays are the easiest win.

Tesla rather famously had issues by writing logs to SD storage.

At 5:38 he describes "gravity fields" that snap your cursor to lines and endpoints - letting you "be sloppy while drawing and get a precision drawing at the same time."

Every design tool today (Figma, Illustrator, CAD) still uses this exact UX pattern. Sutherland nailed it 62 years ago with a light pen and an oscilloscope.

The detail that -wavonly (falling back to the older WinMM API instead of DirectSound) actually gave the highest frame rate is a perfect example of a lesson that keeps reappearing in systems programming: "more direct" doesn't always mean faster when you're CPU-bound. DirectSound's lower latency came at the cost of more CPU cycles that could otherwise go to rendering.

The platform that fired 80% of its engineers continues to have reliability issues. Shocking.

LLMs are terrible at tracking exact line numbers. This format uses context matching instead - it finds where to apply changes by matching surrounding text, not by trusting line numbers. The find_context_core() function searches for matching lines rather than jumping to line N.

I use Claude Code CLI daily - it's genuinely changed how I work. The $1B number sounds crazy but honestly tracks with how good the tool is. Curious how Bun integration will show up in practice beyond the native installer.

Doesn’t sound crazy at all? My Max subscription costs me more than all the other netflix/spotify etc combined, but I pay it happily, and spotify would go before Claude does.

The "yes/no" framing is a nice constraint that makes this actually useful vs generic "page changed" monitors. Do you rate-limit the checks to avoid hammering sources?