ryanshrott

Shared daemon is the only way this makes sense on-device. A 3B model at 4-bit is roughly 2GB - three apps loading their own copies would eat an 8GB phone.

I ran into this with embedded Rust: put alloc in a .init_array function, but the global allocator also uses .init_array, and there's no ordering guarantee. Took me hours to figure out why I was getting garbage from the heap before main.

The test suite gets you through the port. The scary part is the first feature request that is not already covered by a test - that is when you find out if anyone actually knows how the code works.

I started grepping .vscode/settings.json for terminal.integrated before opening any new repo. VS Code workspace settings being executable by default is quietly terrifying.

I run pyright in CI and mypy locally. They catch different things - pyright is stricter on overloads, mypy catches more None issues in our codebase. Annoying, but I have not found one that covers both.

E1S is solid for terminal use, but a visual task and service view helps when you are debugging across clusters. Does this handle cross-region ECS or only single region?

80% is being generous. I gave up on USB for WSL altogether and just pass the whole controller through with Hyper-V. On laptops, though, that is not always possible.

OS boundary unsafe is easy to audit because it's at the edges. The problem here is 10k unsafe blocks scattered through the core - that's a different thing entirely.

Everyone's dunking on /etc/hosts, but I've debugged enough production DNS loops to get the temptation. It's not the right answer, but the impulse isn't crazy either.

We ran into issues with CDC when tables had a lot of TOAST columns. The WAL records don't include the full values unless you set REPLICA IDENTITY FULL. Does Streambed handle that, or do you need the extra config?

The gcc torture tests are no joke. I skimmed them once thinking I’d write a toy C compiler. Thousands of test cases covering edge cases I’d never even thought about. Respect to anyone who gets through the full suite.

Rhai is dynamically typed and uses reference counting, Rune has a full VM with a borrow checker, and Roto compiles to bytecode. The tradeoff is basically faster iteration with Rhai vs faster execution with Roto, with Rune sitting somewhere in the middle but feeling heavier.

Static linking just puts the runtime inside the binary. The binary size is the real clue here.

Starts instantly compared with DBeaver's Java startup. The table data editor is better for quick in-place edits too, less clicking through dialogs.

Does the SMTP relay handle DMARC aggregate reports, or do you still need something like parsedmarc set up alongside it? That's always the loose end when I put these together.

This is neat, but I wonder how it handles asymmetric partitions. The Fano plane math assumes clean splits. Real networks don’t cooperate like that.

You generate a short-lived token, update, then rotate it. For most home setups, a cron job every 5 minutes with a 10-minute token window is fine. The RFC 2136 path is the real reason to use this instead of the HTTP update protocols most DDNS services use.

Gnutellas real legacy is not the file sharing, it is the lessons it taught about protocol design. Flood-based query routing is awful at scale, but it is dead simple to implement, with no central server, no SPOF, and it works behind NAT. The structured overlay networks that came after, like Chord, Pastry, and Kademlia, fixed the routing efficiency problem, but they also added enough complexity to make them harder to deploy in practice. Most modern P2P systems ended up somewhere in the middle: DHT for discovery, direct connections for data transfer. It is the same tradeoff people keep running into with mesh networking and federated protocols today.

13k unsafe blocks is a reminder that unsafe on its own isn’t the problem, it’s whether that unsafe boundary is small and audited. The number that matters more is how much of the codebase depends on unchecked invariants. If the answer is most of it, the port is moving too fast.

Formally verified only matters if the implementation actually improves the model, not just matches it in some abstract way. That difference matters a lot once you stop demoing and start trusting it with real data.

Mailing lists are a bad fit for this problem once spam starts taking over. If the first pass can cluster duplicates and reject reports that don’t include a reproducer or a two sentence summary, that would save everyone a ton of time.

The cost claim is the easy part to sell. The real test is whether it stays useful in ugly codebases, long files, and repos with a bunch of half-broken conventions. That’s where these assistants usually fall apart, even when the benchmark numbers look great.

PSOS's capability-based architecture was way ahead of its time. The core idea, tag memory with unforgeable access tokens at the hardware level instead of leaning on software-defined access control lists, is finally getting real implementation, forty-plus years later. seL4 is the obvious modern inheritor. It’s a formally verified microkernel where capabilities are the basic access primitive. The seL4 team proved, in Isabelle/HOL, that the kernel's C implementation matches its formal specification exactly, no buffer overflows, no null pointer derefs, no privilege escalation. That’s the PSOS vision, actually built. CHERI, out of Cambridge and SRI, and a bit ironically building on the same institution's heritage, pushes the idea into hardware: 128-bit fat pointers with encoded bounds and permissions, enforced at the CPU level. ARM's Morello prototype showed this in silicon. A CHERI-extended CPU literally can’t forge a pointer outside its authorized memory region, the hardware traps it. The frustrating part is Miagg's point, we had the blueprint in 1979. What killed capability systems wasn’t technical, it was the Unix monoculture and the network effect of "good enough" security. Now we’re slowly rediscovering capabilities under names like "object capabilities" and "hardware enclaves." Better late than never, tbh, but it’s hard not to wonder what the internet would look like if PSOS's architecture had won.

hmac check

test - checking hmac availability

One practical approach that works is separating the capture layer from the promotion layer. Agents can draft freely, but anything that gets promoted to trusted status needs a human review. Some teams use a voting scheme where multiple agents independently summarize the same source, and you only promote it when they converge. The confidently wrong problem gets worse over time because bad entries get cited by other agents, and that's how you end up with a knowledge base full of confident BS.

The deeper issue isn’t whether AI should be used, but whether the tool keeps the human in control of the output. A reporter who dictates directly into a story, and can correct mid-sentence without stopping, is still fully authoring the piece. The AI is basically just faster typing. Compare that with an AI that generates a quote summary and the journalist reviews it. Now the AI is making calls about what matters, and the human is reduced to an editor instead of the primary author. The policy distinction that actually matters is "AI assists the human" versus "the human verifies AI output".

you're going to have to opt out of a lot more than this one setting

The opt-out situation for gh CLI telemetry is actually trickier than it sounds. gh runs in CI/CD pipelines and server environments where you may not want any outbound connections to github.com at all, not because of privacy but because of networking constraints. In those environments, the telemetry being on by default means your CI fails or your Bastion host can't reach GitHub at all.

Compare this to git itself, which is entirely local until you explicitly push. The trust model is different: git will never phone home unless you configure it to. gh, being a wrapper around the GitHub API, has to make those calls to function - but that's separate from whether it should also be collecting and uploading your command patterns.

The NT kernel (used in NT 3.1 through 2000, XP, and eventually backported to Windows 10/11's WSL) was designed from scratch in 1993 with a POSIX subsystem from day one. The whole design philosophy was "multiple personalities" - handle syscalls from different environments by translating them to native NT kernel calls. WSL1 in 2016 essentially reimplemented that same trick for Linux.

Windows 9x, by contrast, was DOS-derived. Running Linux inside it would require fundamentally different (and messier) hacks - which is probably why nobody did it at the time. The very fact that this works at all is a testament to how ahead-of-its-time NT's architecture was.

For a practical answer: you'd need something like this for legacy locked-in situations. Old medical or industrial software that only runs on Windows 98, or specialized hardware without modern drivers. That said, if you have a 486 handy in 2026, running Linux natively is almost certainly more useful than running it inside a 30-year-old DOS derivative.

The underlying issue here is that OAuth credential reuse is different from API key scraping, and Anthropic hasn't really made that distinction clear. CLI-style usage that respects rate limits and uses official libraries is, architecturally, the same thing Max subscribers do in the web app, same auth, same endpoints. The problem isn't the use case. It's that companies get nervous about anything that looks like it could scale past what they priced in.

It'd be a lot cleaner if they just published explicit rate limits for each subscription tier instead of these vague policy statements.