> 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).
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).
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?
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:
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).
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.
Much more resource heavy. I tried NixOS and Bazzite (and other spins purporting to be lighteweight) and the difference on a 2010-era mid-range laptop was noticeable in terms of sluggishness. Not that this laptop was going to be my daily driver, but I like experimenting. It was a good showing for NixOS and that decided which one I would take. All of the other nice things about NixOS (fast rebuilding, easy install images, remote deploy, easy build tweaks, ...) were cherries on top.
Nixpkgs cross support for Windows has been in there a while. Native windows support for Nix is a bit less advertised because it is pre-release/pre-MVP-on-master, but see https://github.com/nix-windows/nix-windows-demo . And expect to hear more on this in the next few weeks :).
It is, frankly, amazing. I've never seen infrastructure of this kind so close to the people, so sprawling and so well kept. People swim in side arms of the Isar too, many floating (see pictures near the start at https://maps.app.goo.gl/krgaM2tTKdzCzW398, where people surf on the mini-river).
Of the places I've been, Munich is by far the best one in this area (and many others) that I know.
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?
reply