mappu

Is it feasible to implement the libvte surface on top of libghostty? Might be interesting as a drop-in replacement.

NodeJS and Java are in a similar place (this CVE is a memory safety issue in PHP's C-language interpreter) but Go's compiler/runtime is written in Go and is memory-safe all the way down to the assembly.

I expect it will be the death of the C codebase which will get an oxidation push.

In userspace/application code this isn't giving you all the value you hope for - because of overcommit and fork/exec, you can OOM on simply modifying a variable (in a non-file-backed page).

What Zig does is great, but it is not actually comprehensively checking that all allocations are fallible and handled. That's not possible on Linux.

I'm impressed it didn't seem to mention anything about what tools it was using, just straight to imports. Did you prepare any special tools for it, did you have WinDbg/Ghidra/... set up in Claude already? Or did it do this completely stock? Any idea if it even found pdb/symbols for the binary?

I watched Hana bi and Sonatine recently. I thought "this sounds like Joe Hisaishi" - turns out it was, he scored basically all of Takeshi's films

> Currently have auto compaction turned off. When the orchestrator's context is getting close to full, I have it write a handoff markdown file and point a fresh agent at it.

In a good harness that should be how auto compaction works anyway

If you can run the smarter 3.8 27B model, why not use it for everything?

If you're focused on lightweight, native and fast, I don't think you should use an immediate-mode GUI toolkit. Why does an app like this need to hit a 60fps framerate? It's not a game.

I have no skin in this game, but just because they're doing it doesn't mean it's their focus, the EU is big enough to work on multiple 0.8%-size wins all over the place.

I'm not sure this is a real problem - for embedded you know a priori - for arbitrary desktop/SBC machines, misa will be available in kernel mode and /proc/cpuinfo will be available in user mode.

RVA23 hardware is available (e.g. SpacemiT K3)

Go's http.Client will keepalive a TCP/TLS connection to save you handshake latency on second requests. But it can only do this if you completely finish reading the last request.

Now in 1.27:

> http.Response.Body drains itself on Close. For HTTP/1, closing the body now reads and discards any unread content (up to a conservative limit) so the connection can be reused. For most programs this is a transparent win [...]

Great, so i no longer have to io.Copy(io.Discard, resp.Body) in the err case, one less thing to worry about; but

> if you were leaning on an early Close to abort a large download, set Transport.DisableKeepAlives to opt out.

That's a subtle behaviour change. Any previous Go program which used Close in this way - say for an infinite event stream - now hangs, soaking up bandwidth.

In the past, the Go team have searched the entire Github corpus for misuse before making changes like this. I don't have a reference but I assume an appropriate level of consideration went into this decision.

EDIT: ""up to a conservative limit"" so this is not so bad after all.

Automatically draining http response bodies is a risky silent behaviour change. I think it will be an improvement for most applications, but it's very subtle if you were relying on the old behaviour

The really big thing is the model weights, which are a read workload not a write one, it won't affect an SSD's write endurance.

The write workloads are just the context and any K/V cache - llama.cpp does not mmap those to disk, so they would remain in memory or VRAM as space affords.

Standard llama.cpp can mmap the gguf, so it'll stay on disk if it doesn't fit on memory, and the kernel page cache will ensure the hot parts ("resident trunk") stay resident.

What's the benefit of a custom implementation at all?

Linus Torvalds said last week that LLMs were just a tool. Lorenzo Stoakes had the impeccable rebuttal that "it's a tool in the same way a nuclear bomb is just a tool" - of course it's useful but there is clearly more to it than that.

I'm happy for Debian to at least consider the other aspects of social impact, ethics, copyright, and maintainability.

This distinction is less a gotcha and more actually immediately obvious in the Windows task manager. It shows cached memory separately and in a different colour. The "in use" part is real in-use excluding the page cache.

On my current Windows 11 install i'm using 7 GB with just this Firefox tab open, and another 18GB of "Cached" RAM.

Same as how `free` on Linux shows it in a different column.

Steve Yegge calls this is the "discernment horizon" - https://steve-yegge.medium.com/the-flat-curve-society-36c8b0...

The off-the-shelf player in this space (structured red-team search) is probably https://github.com/usestrix/strix (no affiliation). But any frontier model, if you tell it "here's how the authentication system works, go looking for bugs" will probably do a good job.

- MiMo (Xiaomi)

Blender has all these curve tools and more, it might be interesting to write an exporter to the Neverball file format if one doesn't exist yet.

In my harness i implemented apply_patch just taking unified diffs for patch -p1. I was shocked to see how bad models are at generating them. I started logging diff failures to analyse -

- All models are terrible at generating line numbers for a proper diff, give up on them

- Some models (Owl-alpha) must have been post-trained on Codex transcripts, because they occasionally push its V4A patch format into any diff tool available

- Codex puts a lot of info in its system prompt about the desired patch style, making larger hunks instead of granular ones, etc

There was some earlier speculation this is the model behind the stealth-released openrouter/owl-alpha model, that's been free for the last month.

There's also this new one: https://github.com/joske/yserver

It was somewhat slow about a decade ago - you can see

- (2015, Go 1.5) Calls cost about 170ns https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...

- (2017, Go 1.8) Cgo speedup by 50% https://go.dev/doc/go1.8#cgoperf

- (2023, Go 1.21) Calls cost about 40ns https://shane.ai/posts/cgo-performance-in-go1.21/

- (2026, Go 1.26) Cgo speedup by another 30% https://go.dev/doc/go1.26#faster-cgo-calls

A current benchmark shows a Cgo function call as costing about 25 ns. https://gist.github.com/DeedleFake/2f50b02c0708484c66d182533...