6.6 KiB
Joyas reusables — trucos de otras distros que encajan en piezas hammer existentes
Fecha: 2026-07-16 · Criterio de entrada: o está probado por alguien serio, o el CAS de
hammer lo vuelve trivial donde a otros les cuesta. Cada joya nombra la pieza hammer que la
recibe — sin pieza receptora, no entra. Complementa plan-freebsd-aprovechables.md,
plan-variantes-cpu.md y plan-jaula-juegos.md.
1. composefs (Red Hat) — hidratación montada con verity gratis
Qué es. overlayfs+EROFS montando un árbol desde un object store content-addressed, con fs-verity por objeto. Probado en producción: ostree/bootc/Fedora Atomic lo usan hoy. Está diseñado literalmente para stores como el de hammer.
Dónde encaja. Backend alternativo a la hidratación por hardlink (ADR 0005): en vez de materializar N hardlinks, un manifiesto (imagen EROFS chiquita, firmable) monta el árbol directo del store. Y se lleva puesto medio cierre §5 (verity + medida): el hash que hammer ya usa como identidad se convierte en verificación por-lectura del kernel. Coste kernel: EROFS
- OVERLAY_FS + FS_VERITY, tres líneas más del contrato
scripts/config.
Gate barato: prototipo de hammer hydrate --backend composefs sobre un artefacto sellado;
comparar con hardlink en frío/caliente. No reemplaza ADR 0005 — convive como backend.
Prototipo MEDIDO (2026-07-17, laptop, composefs 1.0.8, sobre el product-rootfs sellado
ba351f1b…, 262MB / 730 entradas):
hammer hydrate(hardlink, ADR 0005): 28ms.mkcomposefs --digest-store: 507ms (incluye hashear todo al objects/). El manifiesto.cfsresultante: 136KB firmables para el rootfs entero.- La comparación de velocidad es la métrica equivocada: ambos son sub-segundo. Lo que composefs compra y el hardlink NO puede dar: (1) fs-verity por fichero en runtime — integridad verificada en cada lectura, el cierre §5 en serio; (2) proyección genuinamente read-only — con hardlinks, un write con privilegios a través del árbol hidratado corrompe el store (comparten inode); con composefs es imposible por construcción; (3) el manifiesto chico como unidad de firma/distribución.
- Hallazgo de diseño: el objects/ de composefs se indexa por digest fs-verity
(sha256), no por
b3:⇒ el backend mantiene un objects/ paralelo al store (lo construyemkcomposefs --digest-storesolo, y DEDUPLICA contenido entre artefactos) o hammer guarda el mapa b3→verity al sellar. No es bloqueante, es una tabla. - Pendiente (pide root): montar el
.cfs(overlayfs+EROFS) y medir lectura fría/caliente vs hardlink. El kernel linux-metal re-sellado ya trae EROFS+FS_VERITY.
2. PGO/BOLT con perfil sellado — la que NADIE probó bien
El problema ajeno. PGO y BOLT dan 10–20% real (Fedora ya envía clang/rustc bolteados), pero rompen la bit-repro de las distros: el perfil varía corrida a corrida, así que reproducible-builds y PGO viven peleados.
El truco hammer. El perfil se sella como artefacto: se genera una vez con carga
representativa, entra al store por hash, y la receta lo declara como input. El build vuelve a
ser función pura (fuente, perfil) → binario — PGO bit-reproducible, verificable por la
granja como cualquier receta. Nadie tiene esto porque nadie trata los perfiles como inputs
content-addressed.
Dónde paga primero: el toolchain propio. Un rustc/zig PGO+BOLT hace toda la granja más barata — es la única optimización que se cobra en cada build futuro, no en cada ejecución.
3. mimalloc en estático — el talón de musl
El problema. El allocator de musl (mallocng) es el punto débil de rendimiento conocido de toda distro musl, sobre todo multihilo. Y como hammer linkea estático, cada binario hornea su allocator — no hay LD_PRELOAD que valga después.
El truco (probado: Chimera Linux lo envía system-wide). Linkear mimalloc en las
herramientas calientes, per-receta como el patrón .hammer-zig-ar (NO framework: re-hashearía
los sellados). Candidatas: las propias herramientas hammer y todo lo alloc-intensivo de la
lista caliente de plan-variantes-cpu.md — es la otra mitad de esa moneda: v3 acelera el
cómputo, mimalloc el malloc.
4. MGLRU + zram — dos líneas de kernel, probadas a escala
CONFIG_LRU_GEN=y (multi-gen LRU, kernel ≥6.1): responsividad de escritorio bajo presión de
memoria, probado por ChromeOS/Android/CachyOS. Más zram como swap comprimido. Entra por el
mismo contrato explícito de linux-metal.toml que NTSYNC/sched-ext (plan-jaula-juegos.md
T1.x) — mismo re-sellado, cero código.
5. uutils coreutils — de-Alpinización que compila en el LAPTOP
Probado: Ubuntu 25.10 los envía como default. Son los coreutils en Rust — y ahí está el encaje hammer: Rust compila en el laptop (la regla "recetas C ⇒ worker" no aplica). Cada utilidad de la clase busybox/coreutils que hoy es deuda declarable puede migrar a una receta Rust sin tocar la cola del worker. No es rendimiento: es soberanía de cadena con el compilador que ya es el nativo de la casa (ADR 0001).
6. El corpus de Clear Linux (Intel, †2025) — minarlo como se minó aports
Clear Linux fue el pionero real de casi todo esto (PGO+LTO masivo, dual-build AVX2, flags
por-paquete medidos) y murió en julio 2025 — pero sus repos de patches/configs por-paquete
siguen públicos. Es un corpus, como aports lo fue para musl (Etapa G): cuando una lib
entre a la lista caliente de plan-variantes-cpu.md, mirar qué flags le daba Clear es la
forma barata de no re-descubrir su benchmark. Se mina bajo demanda, no se importa en masa.
7. Reglas ananicy (CachyOS) — datos, no código
Corpus de reglas nice/ionice/latency por-proceso que CachyOS mantiene para escritorio. Es un
fichero de datos reusable tal cual como perfil del init propio (SDD 07 / arje) — el demonio
que las aplica es trivial y no hace falta traer ananicy-cpp entero.
Lo que se miró y NO entra
- DT_RELR / prelink — ganancias de arranque para dinámico; con link=static es ruido.
- ccache/sccache — la memoización de hammer es por contenido y sellada (H2); un cache mutable por-builder la contradice.
- ksm en la granja — dedup de páginas entre VMs efímeras que viven minutos: no amortiza.
Orden sugerido (independiente de los otros planes)
- #4 MGLRU — va gratis en el mismo re-sellado de kernel que ya pide plan-jaula-juegos.
- #1 composefs — prototipo de backend; decide con números frente a ADR 0005.
- #2 perfil sellado — empezar por rustc de la granja (se cobra en cada build).
- #5 uutils — tanda Rust de laptop cuando haya hueco; #3/#6/#7 bajo demanda.