fixpoint-linux image M3 (x86_64) — 64 MiB, with the fx-core shell

fixpoint-linux bootable image — M3 (x86_64) — the small one, with the shell

Boots fixpoint-linux under QEMU with -drive only and lands you at an
interactive fxsh prompt — fx-core's own shell, running the real fx-*
binaries. Built by fx-image (fx-init @ 48cae93).

• fixpoint-m3-x86_64.raw.gz — 64 MiB raw image, gzip (~15.8 MiB on the wire)
• uncompressed sha256: bf8c703f7e13aca975e2c4a6b95173f5981bd4f20478fc94ac88bd15f5fd0879

Boot it

curl -fL -o fixpoint.raw.gz \
  https://github.com/fixpoint-linux/fx-init/releases/download/image-m3/fixpoint-m3-x86_64.raw.gz
gunzip fixpoint.raw.gz

qemu-system-x86_64 -machine q35 -accel kvm -cpu host -m 2048 -nographic \
  -drive file=fixpoint.raw,format=raw,if=virtio

You get fx-init: boot-ok v3, then fx> . Try fx-cat /etc/hostname,
fx-seq 1 5 | fx-sort -r, fx-ls /. Ctrl-A X quits QEMU; exit leaves the
shell.

Why this supersedes M2 and M1

M1 (64 MiB) was broken and M2 (128 MiB) was a workaround. The payload was
built Debug/unstripped — a ~47 MB store against a 32 MiB partition — so cp -a /fx/store ran out of space and init silently fell back to the ramfs store. M1
still printed boot-ok v3; it had no persistence or roll-forward. M2 simply
made the image big enough to fit the bloat.

This release fixes the cause: the payload is built with
-Doptimize=ReleaseSmall, which takes the store to 3.3 MB, so the image
fits back in 64 MiB with the disk store actually seeding. Verified on this
artifact: the store mounts, the raw file's contents change across a boot, three
boots persist at v3, and the download is ~15.8 MiB.

Provenance

Input	Value
config	m3/config-console.dhall (config-good + the fxsh console service)
package set	m3/package-set.dhall
kernel pin	scripts/kernel-pin.txt (6.12.19-tiny, drivers built-in)
fx-init	48cae93
activated generation	v3

Early milestone: you get the shell and the supervisor; not yet a
general-purpose desktop.