Hacker News: mbrock

New comment by mbrock in "Claws are now a new layer on top of LLM agents"

mbrock — Sun, 22 Feb 2026 16:55:36 +0000

If you stop trying to find something like truly ontologically novel about it, you might be able to understand what it actually is. Okay it's not impressive. It's not incredible. It's not groundbreaking new technology. It is what it is.

New comment by mbrock in "What I learned building an opinionated and minimal coding agent"

mbrock — Sun, 01 Feb 2026 19:41:22 +0000

That kind of blanket demand doesn't persuade anyone and doesn't solve any problem.

Even if you get people to sit and press a button every time the agent wants to do anything, you're not getting the actual alertness and rigor that would prevent disasters. You're getting a bored, inattentive person who could be doing something more valuable than micromanaging Claude.

Managing capabilities for agents is an interesting problem. Working on that seems more fun and valuable than sitting around pressing "OK" whenever the clanker wants to take actions that are harmless in a vast majority of cases.

New comment by mbrock in "Developing a food-safe finish for my wooden spoons"

mbrock — Sun, 14 Dec 2025 23:26:39 +0000

Flexner's "Understanding Wood Finishing" has a section about "the myth of food safety" that pretty directly states that food safety isn't a serious concern for fully cured finishes.

New comment by mbrock in "Developing a food-safe finish for my wooden spoons"

mbrock — Sun, 14 Dec 2025 23:17:18 +0000

The solvents evaporate when the lacquer cures, right? A lacquered spatula or spoon could leach some plasticizers when heated up. But who on earth would go to the trouble of spray lacquering a spatula? It doesn't seem like a real concern. Wooden spoons from IKEA aren't gonna poison you!

New comment by mbrock in "Stop crawling my HTML – use the API"

mbrock — Sun, 14 Dec 2025 19:26:44 +0000

The author seems to have forgotten to mention WHY he wants scrapers to use APIs instead of HTML.

New comment by mbrock in "Developing a food-safe finish for my wooden spoons"

mbrock — Sun, 14 Dec 2025 19:16:26 +0000

I think all wood finishes are "food safe" once they're cured.

New comment by mbrock in "Linux Sandboxes and Fil-C"

mbrock — Sun, 14 Dec 2025 19:13:09 +0000

Great! Feel free to ask questions or report problems on GitHub or the Fil-C Discord. If some package doesn't compile I can probably look into it!

New comment by mbrock in "Linux Sandboxes and Fil-C"

mbrock — Sun, 14 Dec 2025 18:18:24 +0000

FYI nginx and Apache and Postgres using shared memory across processes make them hard to use with Fil-C. Lighttpd works well though!

New comment by mbrock in "Linux Sandboxes and Fil-C"

mbrock — Sun, 14 Dec 2025 18:15:58 +0000

If you're into Nix, check out https://github.com/mbrock/filnix — not yet integrated & maintained in upstream Nixpkgs, but lets you replace Nix/NixOS packages with Fil-C versions quite easily.

New comment by mbrock in "Go is portable, until it isn't"

mbrock — Sat, 13 Dec 2025 14:54:17 +0000

I've got a pure Go journald file writer that works to some extent—it doesn't split, compress, etc, but it produces journal files that journalctl/sdjournal can read, concurrently. Only stress tested by running a bunch of parallel integration tests, will most likely not maintain it seriously, total newbie garbage, etc, but may be of interest to someone. I haven't really seen any other working journald file writers.

https://github.com/lessrest/swash/tree/main/pkg/journalfile

New comment by mbrock in "Building more with GPT-5.1-Codex-Max"

mbrock — Thu, 20 Nov 2025 11:29:16 +0000

I see what you mean, but I think it's a lot less pernicious than astrology. There are plausible mechanisms, it's at least possible to do benchmarking, and it's all plugged into relatively short feedback cycles of people trying to do their jobs and accomplish specific tasks. Mechanical interpretability stuff might help make the magic more transparent & observable, and—surveillance concerns notwithstanding—companies like Cursor (I assume also Google and the other major labs, modulo self-imposed restrictions on using inference data for training) are building up serious data sets that can pretty directly associate prompts with results. Not only that, I think LLMs in a broader sense are actually enormously helpful specifically for understanding existing code—when you don't just order them to implement features and fix bugs, but use their tireless abilities to consume and transform a corpus in a way that helps guide you to the important modules, explains conceptual schemes, analyzes diffs, etc. There's a lot of critical points to be made but we can't ignore the upsides.

New comment by mbrock in "Building more with GPT-5.1-Codex-Max"

mbrock — Thu, 20 Nov 2025 11:20:58 +0000

I'd been imagining taking the Zig Language Server and adding some refactorings to it—it only had a bare minimum like Rename Symbol. It seemed like a huge project with so much context to get familiar with, so I put it off indefinitely. Then on a whim I decided to just ask GPT-5 (this was before Codex, even, I think?) to give it a go. Plopped it down in the repo and said, basically, implement "Extract Function". And it just kind of... did. The code wasn't beautiful, I could barely understand it, some of which must perhaps be blamed on the existing codebase not being exactly optimized for elegance, but it actually worked. On the first try! We continued to implement a few more refactorings. Eventually I realized the code we were churning out actually needs major revision and rewriting—but it took me from less than zero to "hey, this is actually provably possible and we have a working PoC" in, like, fifteen minutes. Which is pretty insanely valuable.

New comment by mbrock in "Why is Apache still popular even as Nginx has proven its mettle on performance?"

mbrock — Sat, 15 Nov 2025 14:56:38 +0000

If you've already gotten used to one custom ad hoc confusing configuration language...

New comment by mbrock in "Notes by djb on using Fil-C"

mbrock — Mon, 03 Nov 2025 12:16:24 +0000

Interesting! I guess that's from your standard benchmark setup. Please note that Fil-C makes no secret of having a performance penalty. It's definitely a pre-1.0 toolchain and only recently starting to pick up some momentum. The author is eager to keep improving it, and seems to think that there's still plenty of low hanging and medium hanging fruit to pick.

It does (or did, at some point) pass the thorough SQLite test suite, so at least it's probably correct! The famous SQLite test coverage and general proven quality might make SQLite itself less interesting to harden, but in order to run less comprehensively verified software that links with SQLite, we have to build SQLite with Fil-C too.

New comment by mbrock in "Notes by djb on using Fil-C"

mbrock — Mon, 03 Nov 2025 09:45:15 +0000

If you missed it, djb himself posted this cute graph of "nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4)":

https://cr.yp.to/2025/20251028-filcc-vs-clang.html

I've heard Filip has some ideas about optimizing array performance to avoid capability checks on every access... doing that thread safely seems like an interesting challenge but I guess there are ways!

New comment by mbrock in "Notes by djb on using Fil-C"

mbrock — Sun, 02 Nov 2025 17:13:38 +0000

Currently measured worst case for some types or code.

New comment by mbrock in "Notes by djb on using Fil-C"

mbrock — Sun, 02 Nov 2025 16:09:56 +0000

Yeah, but if you actually need to retain a live subgraph of the allocated heap, the arena can't help you. So you make an arena allocator that only frees its slab after moving out the reachable set to a new compacted arena. Congratulations, you've implemented a Cheney-style compacting GC!

New comment by mbrock in "Notes by djb on using Fil-C"

mbrock — Sun, 02 Nov 2025 14:59:15 +0000

Hmm, so if they're writing new memory unsafe code in C/C++, presumably to remain within their already established and entrenched C/C++ ecosystems, why isn't Fil-C interesting as a way to thwart memory safety issues in that new code?

New comment by mbrock in "Notes by djb on using Fil-C"

mbrock — Sun, 02 Nov 2025 14:52:49 +0000

You can wrack some people's brains by stating that for some problems, a GC is a great way to alleviate the performance problems caused by manual memory management.

New comment by mbrock in "Notes by djb on using Fil-C"

mbrock — Sun, 02 Nov 2025 14:48:40 +0000

From an engineering perspective, the software is already written in C, and you're weighing the tradeoffs between rewriting it and recompiling it.