114 lines
6.6 KiB
Markdown
114 lines
6.6 KiB
Markdown
# 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 `.cfs` resultante: **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
|
||
construye `mkcomposefs --digest-store` solo, 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)
|
||
|
||
1. **#4 MGLRU** — va gratis en el mismo re-sellado de kernel que ya pide plan-jaula-juegos.
|
||
2. **#1 composefs** — prototipo de backend; decide con números frente a ADR 0005.
|
||
3. **#2 perfil sellado** — empezar por rustc de la granja (se cobra en cada build).
|
||
4. **#5 uutils** — tanda Rust de laptop cuando haya hueco; #3/#6/#7 bajo demanda.
|