max / alloy

Weigh the base trim instead of quoting dnf, and the push instead of assuming it Both claims committed last were repeated from the tools that made them rather than measured against the artifact, and both are wrong in the same direction: they promise a saving to whoever reads them next. THE TRIM. dnf reports 297 MiB freed and /usr does shrink by 304 MiB, so the number was never invented. The image on disk shrinks by 3.8 MiB. Every file in the base's /usr is a hardlink into /sysroot/ostree/repo/objects, which the image carries too, so removing the /usr path drops one link of two and frees no blocks; the repo still holds the object and cannot be pruned, because those objects belong to the base commit and it is still referenced. dnf is accounting for the rpm database, which is a different question from what the medium carries. Both profiles were built the same hour so the package versions match and the delta is the trim rather than a base bump. That takes the build-speed argument with it. The ext4 populate, the squashfs, the write to a stick and the install all scale with the image, and the image did not move, so the trim is paid for four times by nobody. It stays, because the packages are genuinely unreachable from an Alloy install and because the installed system is built from /usr rather than from the image's repo and is where the saving should land. That has not been weighed, and the comment now says so rather than implying the medium got smaller. The label loses its "(297 MiB)". A number in a picker is a promise, and this one would be read as the size of the ISO the user is about to build. THE PUSH. A registry moves layers to the target, which is true and is why the script exists. The push into it is not incremental: skopeo re-copies all 125 blobs on every run, 22s twice in a row with no "Skipping fetch of repeat blob", because a containers-storage source records no compression metadata, so each layer is recompressed before its digest is known. The volume still earns its keep, for the target's next pull rather than for this end. The script said "first push moves the image; later ones move what changed" on every run, so anyone timing it saw the second push cost what the first did and had nothing to reconcile it against. Recorded while measuring: the registry binds every interface and takes no authentication, because a VM reaches it at 10.0.2.2 and a real target by tailnet name. Same trust boundary as the tailnet, and still a reason to keep it up only while a push is in flight. base_trim.rs keeps its subject, which was never the size: the trim list is a thing people extend, and firmware is what they must not take. The reason to hold that line is now the one that survives measurement. A list that looks like it buys hundreds of megabytes is exactly the list somebody extends.