# Uses

Source: https://taco-man.in/uses

> What I build with, and how two machines share the work. Checked October 2026.

## Two machines, one workspace

I edit everything on a MacBook Air with 8 GB of memory. The heavy work runs on a Windows PC next to it: Docker, test suites, GPU runs, Rust builds. The code never lives in two places. The Mac is the only place I edit; the other machine gets disposable copies.

```text
MacBook Air (M2, 8 GB): code, editor, browser
  │  Tailscale (WireGuard), direct over the home network
  ▼
Windows PC (Ryzen 7 5800H, 16 GB, RTX 3060 6 GB)
  └─ WSL2: Ubuntu 24.04, 14 CPUs, 12 GB — "devbox"
       ├─ its own Tailscale address
       ├─ Docker Engine and Compose (no Docker Desktop)
       ├─ NVIDIA GPU passthrough
       └─ ~/mirror/<project>: throwaway copies for heavy runs
```

### Tailscale

Both the Windows host and the Linux server inside it join my Tailnet as separate devices. SSH to the server is key-only. Ports that containers publish are reachable from the Mac by name, as `devbox:<port>`, and from nowhere else: WSL2 sits behind Windows' NAT, so only my Tailscale devices can reach them.

### Docker on the other machine

The Mac has a Docker context that points at the server, so plain `docker` and `docker compose` run there:

```bash
docker context use devbox
```

Quitting Docker Desktop on the Mac frees about 4 GB of memory, which on an 8 GB machine is half the point. Two things change from local Docker: bind mounts refer to folders on the server, so I use named volumes; and `docker build` sends its context over the network.

### Run next to the database, not across the network

Moving only Docker to the server makes a chatty program slower. I measured it on a service that makes 40 to 55 database round trips per write:

| Where things run | One database round trip | One write |
| --- | ---: | ---: |
| Code and Docker on the Mac | 0.64 ms | 95 ms |
| Code on the Mac, Docker on the server | 5.36 ms | 313 ms |
| Code and Docker both on the server | 0.17 ms | 12 ms |

So heavy runs go to the server too. A small `devbox` command syncs the working tree to a mirror with rsync and runs the command there, next to the databases:

```bash
devbox run "uv sync --frozen && .venv/bin/python -m pytest tests -q"
```

That suite, 518 tests on 10 workers, takes about 3 minutes 40 seconds there. On the loaded Mac it was 13% done after an hour. Long-lived servers run in tmux on the server, so they survive the Mac going to sleep.

### Two architectures as a test rig

For [Taco](https://github.com/tac0mania/taco), the two machines are also the test: the Mac is ARM and the server is x86. `scripts/dx <lane> <command>` runs a command on the server in its own build directory, so parallel jobs never wait on one cargo lock. `scripts/xcheck` folds every test file on the Mac and unfolds it on the server, then the other way round, and fails unless both machines restore every byte and write identical `.taco` files.

## Editors

- VS Code, Zed and Neovim.
- Xcode and Android Studio for mobile apps.

## Terminal

- Ghostty and iTerm, with zsh.

## Languages and runtimes

- TypeScript on Node.js and Bun, with pnpm.
- Rust, for Taco and networking experiments.
- Python with uv, for measurement tools.

## Tools

- Docker, Postman, DBeaver and the GitHub CLI.
- Claude and Claude Code.

## Browsers

- Arc and Chrome.