Great read. This is (unbelievably) impressive. Both from the model and the human. Congratulations. I also liked the postscriptum about the GPU driver.

Mac hardware is some of the best there is, but I lost faith in macOS around 2015 when I experienced a bug where XNU would shut down my device without warning if the wireless driver produced an invalid packet. (The shutdown code was in the open-source XNU part of Darwin. I don't know why the invalid packet was produced, perhaps there was a hardware issue, but the response shouldn't have been to hard reset the device immediately.)

Running Linux on this hardware, and being to use most of its capabilities, is awesome. Thanks to all the AsahiLinux contributors (directly and indirectly) for their work.

Given that Dutch is the ancestor here (not that Dutch hasn't changed since the split), I wouldn't call it "as if".

> For example, one of the unique features of my harness is that the filesystem is completely virtualized and all filesystem I/O is part of the session...

What are the mechanics of this? You mentioned bash so I asssume you don't "control" all the tooling. Is it running in a VM with an overlay filesystem that takes snapshots at every file interaction? Or perhaps outside a VM but containerized with a FUSE-based overlay filesystem?

It's not a VM; it's containerized with a FUSE-based custom overlay, and the agent never touches a real mount (with two exceptions: passthrough read-only mounts for things like /bin, and ephemeral tmpfs mount at /tmp).

My view is this isn't sufficent. They're pretty good at breaking out of stuff. A VM would be the minimal isolation boundary for me.

The main risk is not that the agent breaks out of their sandbox, although it's an infitesimal possibility (that increases to certainty if you increase the token budget to 100M$ and use subagents to spend it all at once).

The main risk (for you, mere human without a 100M$ budget) is that it downloads a compromised package or vulnerability, or that it runs a stray rm -rf or some stupid stuff. A user provides reasonable protection, you don't NEED a vm (and even then that can be escaped).

Hi Kenton!

One thing I'm wondering about (and was happy to see) is how you seem to have your (childhood) friends close by, at least on occasion.

I live in Europe and am considering what a move somewhere else in Europe (+/- 1000km) would mean. Seeing much less of my long-time friends, I imagine. But Austin seems much further from the earlier places you've stated you've lived. Did some of your friends just move with you? Are they visiting often?

> transparent matte coat for my exterior walls

I'm curious about this. Do you mean a layer of paint-like substance that makes the walls isolate better?

Kind of not like this.

I mean the coat on my brick wall (and ideally roof), that will reflect most of the infrared and UV.

I've used a white paint like this on the conservatory and white walls outside, and along with a solar-reflective foil outside of my windows it's the biggest factor to having a nice temperature inside. I might also actually consider painting the interior walls with something like this as well - there's less he t escaping through radiation if it's reflected back, right?

+1, I like to test in a similar way. For example if I'm making a CLI, the test will spawn the CLI for each test-case, instead of invoking the code directly. This provides a more realistic flow, and makes it clear which user journeys one is supporting.

Faking responses I often do with environment variables, like:

  ts := httptest.NewServer(...)
  cmd := exec.Command(...)
  cmd.Env = append(os.Environ(), fmt.Sprintf("MYCLI_PROD_ADDR=%s", ts.URL))

Of course, it's better still to go down this turtle stack (e.g. by spawning a local instance of your backend server instead of some faked handlers), but that adds more cost. I find the trade-off OK here.

I actually had to use a similar hack there due to the limitation that go test compilates cannot spawn themselves where I needed to have an environment variable with the actual binary prebuilt before the tests run. Took me a while to understand that TestMain doesn't cover that use case...

On Linux, "self" is /proc/self/exe. In general, I've seen people use `os.Args[0]`. But on checking again, I see there's even `os.Executable()` (https://pkg.go.dev/os#Executable) for this purpose.

I'm quite sure go test compilates can spawn themselves, I'm doing it on many platforms.

But, the test setup I was referring to was explicitly not that: the tests are spawning the main binary, not themselves. Using bazel+runfiles this is pretty easy to do. With the pure Go build tool, I'm not sure what approach I'd use to "guarantee" that I get a binary build for the same environment as the test.

My favourite Delphi program, and the one I learned to program with, was Dev-C++ (https://sourceforge.net/projects/dev-cpp). AFAIK there is a more recent fork, but I also clearly recall the 4.9.9.? versoin number from back then. It was very fast (including startup). I enjoyed it a lot back when I was still on Windows. Funny that Delphi was used to create a C/C++ IDE.

It is funny that while I learned about Dev-C++ during my university course but it was mostly considered a joke by anyone that used Linux (including myself). I think the issue was because it shipped with a really old version of GCC even at the time, so something that compiled on it had lots of issues running in the more recent GCCs that Linux/Ubuntu used (including the teacher for this particular course).

As C++ got more and more complex, it was not able to for Dev-C++ to catchup.

Dev Pascal was also a dead end.

Ah I remember Dev-C++ - not bad for simple stuff, but I tried using it to import a Visual Studio project (which worked) but it wouldn't compile due to it not having any compiler intrinsics headers.

Reminds me of VirGL [1] and Venus [2], which I think do something similar for OpenGL and Vulkan.

I use this with Baguette/Crostini on ChromeOS to get some light gaming done. Works very well [3].

[1]: https://docs.mesa3d.org/drivers/virgl.html

[2]: https://docs.mesa3d.org/drivers/venus.html

[3]: For Baguette, the Crostini-replacement, one needs to do a minor amount of tweaking to get 3D acceleration to work well (https://www.reddit.com/r/Crostini/comments/1sftdu1/comment/o...).