> on UTM (QEMU and Apple Virt Framework), but many of them don’t appear to support GPU acceleration

Uh, it does. OpenGL/virgl works great out of the box for me with UTM and Linux guests (I'm on stock Debian stable), perfectly usable and performant enough to drive an external 4K monitor - my daily driver. Ditched my beefy Intel workstation for it, no regrets.

There's now virtualized Vulkan support which just shipped in UTM 5.0.0 this month - really exciting news! But it is still kinda buggy, so maybe that's your problem. Try UTM 4.7.5 or disable Vulkan (in UTM > Settings > Display) for now.

That’s super helpful, thanks! I’ll look into that - both UTM config and stock Debian.

It seems that it depends on the distro though - I couldn’t get it working on any of the distros I mentioned above, although admittedly this stuff is not my strong suit; rather than spend lots of time figuring out the ins and outs of each distro I was kind of hoping that commenters would help surface the best options for this setup generally, from which it would then make sense to dig more deeply. Or alternatively, get a steer on which distros to avoid.

One of the commenters below helpfully mentioned NixOS - it’s been great - GPU acceleration working out of the box. Good contender at the moment.

Maybe helps the LLM, but at the cost of confusing humans. It would've been better left as an internal implementation detail. I've got better things to keep in my head that remembering wtf deacon is, etc.

You can bind-mount a single file read-only with docker.

While you're at it, bind mount .git read-only as well. Hasn't happened to me yet, but talked to people who had their local repo wiped out by desperate agents! No code - no broken tests, eh. It would also block one nasty container escape vector via git hooks.

Nonsense. I've been running Linux just fine as my daily driver on Macbook M4 for a year. Besides battery life (VM is kinda heavy on it) and some minor issues (fewer than you'd think, especially with Vulkan landing in UTM today) it's the best Linux laptop I've owned ever so far. I like macOS as much as the next Linux user here, but it's fairly decent as a hypervisor. If anything, at least it comes with UI unlike Intel ME.

I captured max RSS size while running benchmarks as a rough approximation, but it's not exposed anywhere. If you go to the repo, you can run `./bench/compare -f rss_mb -lT bench/amd64/*.json` to see a table in the terminal. No big surprises there, Java engines (Rhino, Nashorn, GraalJS) are most memory-hungry.

Put them in a container or VM? Security benefits from layering: engine/runtime is one layer, container/VM is another - an attacker would need two independent high-value exploits to breach both of them.

High budget is no guarantee for absence of critical bugs in an engine, maybe even somewhat opposite - on a big team the incentives are aligned with shipping more features (since nobody gets promoted for maintenance, especially at Google) -> increasing complexity -> increasing bug surface.

If speed is less important and you can live without JIT, that expands your options dramatically and eliminates a large class of bugs. You could take a lightweight engine and compile it to a memory-safe runtime, that'd give you yet another security layer for peace of mind. Several projects did such ports to Wasm/JS/Go - for example your browser likely runs QuickJS to interpret JavaScript inside .pdf (https://github.com/mozilla/pdf.js.quickjs)

You can use this docker image with all the pre-built binaries as a starting point: https://hub.docker.com/r/ivankra/javascript-zoo

Just keep benchmark code limited to standard ECMAScript, don't expect any browser or Node APIs besides console.log() or print().

I actually captured max RSS size while running benchmarks as a rough approximation, but it's not exposed anywhere. If you go to the repo, you can run `./bench/compare -f rss_mb -lT bench/amd64/*.json` to see a table in the terminal. No big surprises there, Java engines (Rhino, Nashorn, GraalJS) are most memory-hungry.

thanks for your work!

Pretty much. ES6+ scores are from running compat-table's test suite (https://compat-table.github.io/compat-table/es6/), along with their weighting. If you click on an engine's name to go to a page about it, there's a report at the bottom with failing tests.

"Someone" is a big assumption these days. What if it was an AI agent just poking in its own source code?