I Want to Build a Sandboxed, Cross-Platform Software Distribution System

Pointers Gone Wild

I Want to Build a Sandboxed, Cross-Platform Software Distribution System

July 14th, 2026

I'm writing this post to solicit feedback from the community. You may or may not have been following my blog. I've been tinkering on a small virtual machine named UVM for a while. This is a side project, and I've been having fun working on it, but I have a bigger vision for what it could become. I wanted to share that vision and invite comments. I haven't really talked about it online so far, in part because I'm a bit shy to be honest. The internet can sometimes be a very cynical place, but I decided to take the risk anyway. My only request is that if you comment on the ideas presented here, whether on X, HN, or reddit, you please try to keep the feedback constructive rather than simply dismissive.

There are several unsolved problems around software distribution, both for the people writing software, and for end users. On the developer side, it can be tricky to build software that will run on every platform. On the user side, we now live in a world where vulnerabilities can be automatically discovered, and due to supply chain attacks, it feels more dangerous than ever to install software with brew or try some random project on GitHub. Even major projects like the OpenCode harness pull in 300+ dependencies, which makes it hard to audit everything. We're functioning with security models that are completely outdated. There's no way that random programs should have access to your entire home directory, potentially on the same machine where you do your banking.

What I'd like to build is something that resembles the package managers that we're all familiar with (e.g. apt, brew), but that allows installing and running the same programs on every major platform (e.g. Mac, Linux, Windows, BSD, etc), and to run programs in a way that's sandboxed by default. This means something that's probably similar to the capabilities model found on mobile, where programs need to either ask for permission, or be explicitly allowed to perform potentially dangerous operations. I think this is something that needs to exist, and would be beneficial for a lot of people, but currently doesn't.

This is a sketch of what I would like the CLI to look like, just to give you a feel of how it could be used:

# It would be easy to provide a curl command to install UVM<br>curl --proto '=https' --tlsv1.2 -sSf https://uvmplatform.org/sh | sh

# Run a program, no install, fast startup<br>uvm run some_program

# Run a specific version of a program<br>uvm run some_program@2.5

# Download a self-contained package for a given program<br># In the current directory<br>uvm download some_program

# Download auto-generated binaries for any platform<br># Self-contained binaries embed a lightweight VM and sandbox<br>uvm download-binary --platform=x86_64 some_program

In the rest of this blog post, I'll go over how I think this can be built, where I'm at, the compromises involved, and also try to anticipate some of the criticism of the approach I'm presenting.

Approach and Compromises

I have a background in JIT compiler design, and what I've been building is a minimalistic virtual machine, with a small instruction set that's designed to easily map to x86-64, arm64, and RV64 (RISC-V). You can think of the virtual machine as a simplified model of a 64-bit computer, designed in such a way that I know it's possible to build a JIT for the common 64-bit targets and get good performance. The instruction set is simple enough that I believe it might be possible to build a decent JIT compiler in a matter of days or weeks.

The VM has a number of subsystems that allow it to interface with the outside world (input, sound, graphics, file I/O, networking). This is similar to Linux system calls, but once again simplified. The design of the VM, and the subsystems in particular, is opinionated. This is a compromise, which I think might make some people recoil, but I hope you'll bear with me as I explain the potential advantages.

UVM has a minimalistic design, and that extends to its subsystems as well. In particular, it exposes only low-level APIs, and there is no Foreign Function Interface (FFI). That means the only way to interface with the outside world is through the low-level APIs provided by the VM. For example, to produce graphics, you can open a window, and then present frames, in the form of a frame buffer (an array of pixels). To output sound, you directly write audio samples to a virtual audio output device. What UVM tries to do is reduce the API surface of the functions it exposes to running programs as much as possible, to maximize portability and minimize chances of API breakage.

This might seem very limiting, but the tradeoff is that these APIs are trivial to implement on any modern platform, and they can remain very stable over time. New APIs will be added as needed, but the evolution of the...