sid and box

sid is a small Debian sid environment that runs on an Apple silicon Mac and shares the host home directory with the container. It is meant to be started when a Linux toolchain is needed — a compiler, apt, a service to test — and otherwise left alone.

The base image is debian:sid-slim, around 30 MB. Two CPUs and two gigabytes of memory are enough; the container is not a virtual machine and does not try to be one.

Five ways to run it

The repository deliberately keeps several launchers, all sharing the same conventions — container named sid, uid/gid 501:20, /Users/user mapped to /home/user — so only one can run at a time:

• a shell script that pulls the plain image and configures it live;
• a Containerfile that bakes the tools in for a reproducible image;
• two container-compose variants, with and without a build step;
• a set of small reference scripts.

The box helper wraps the common operations: open a login shell here or at a chosen directory, run one command, start, stop, inspect, or follow logs. It reads no configuration files and is distribution-agnostic.

What was learned about the runtime

Apple’s container tooling is not Docker. Restart policies are ignored, compose up recreates the container on every run, and only part of the deploy block is honoured — CPU limits map to --cpus, but memory has to come from mem_limit. Those details are written down in the README instead of being rediscovered each time.

Identity mapping also needed care. A plain Debian image has no user matching uid 501, so whoami reports a number and ls -l shows numeric owners until a passwd entry is added. With the home directory mounted from macOS, files created from the root shell are owned by root; the documentation says to work as the user account for that reason.

Why bother

A virtual machine is heavy, a remote server is far away, and some tools are simply easier to install with apt than with Homebrew. This keeps a Linux environment one command away without giving it permanent control of the machine.