gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1471Shell 173Rust 105Markdown 943545 Sutichaykuna

SDD 23: para la IMAGEN sí hay atajo — un rootfs proyectado no es un artefacto

El documento decía, con razón, que `strip` posterior no sirve: rompe la verificación bit-a-bit
porque el ArtifactHash es de ENTRADA. Eso vale para el STORE. Un rootfs proyectado es otra cosa:
se arma copiando y enlazando, no se sella, nadie verifica su hash contra una receta. Stripear ahí
es determinista, no toca un byte del store —que conserva los símbolos para quien depura— y es
exactamente lo que el §2 ya pedía.

Medido sobre el rootfs de la variante `mirada`: 1348 → 891 MiB, un 34 % menos. Un binario suelto
(`ssh` de openssh): 19,3 → 5,3 MiB, un 72 %. La distancia entre los dos números es la composición
—en un escritorio buena parte de los bytes son datos sin símbolos—; en `servidor`, dominado por
estáticos grandes (rust 364, gitea 219, git 216, openssh 202), el ahorro sería mayor, y como no
está medido no se pone un número.

No sustituye al split dentro del build: eso sigue siendo lo que arregla los 126 G del store.

4f29cb8d62118ad99815a4def6a410a965511323 · ruwaq Sergio · (29 p'unchaw ñawpaq) · tayta 3d3d160e0 · kay commitpi sach'ata qhaway

Semántico sayk'uy

Mana ima sutichaypas t'ikrakurqanchu: qillqalla, yachachiylla utaq willaylla t'ikrakurqan.

1 qillqakuna · +24 −0

diff --git a/docs/23-plan-rehasheo.md b/docs/23-plan-rehasheo.md
index 592e202a..abd787ea 100644
--- a/docs/23-plan-rehasheo.md
+++ b/docs/23-plan-rehasheo.md
@@ -120,6 +120,30 @@ ENTRADA (se calcula sin construir) y quedaría apuntando a un contenido que un r
 reproduce. Hay que hacerlo **dentro del build**, y eso cambia la fase `install` ⇒ **re-hashea las
 recetas afectadas**. Es el coste real y no hay atajo.
 
+### ⚠ Pero para la IMAGEN sí hay atajo, y es legítimo (2026-09-23)
+
+Lo de arriba vale para el STORE. **Un rootfs proyectado no es un artefacto**: se arma copiando y
+enlazando, no se sella, y nadie verifica su hash contra una receta. Stripear ahí no rompe nada —
+`strip` es determinista, así que la imagen sigue siendo reproducible— y **no toca ni un byte del
+store**, que conserva los símbolos para quien depura. Es exactamente lo que el propio §2 pide:
+«entregar los símbolos a quien depura sin imponérselos a quien sólo usa la distro».
+
+Medido sobre el rootfs de la variante `mirada` del instalador:
+
+| | |
+|---|---|
+| tal como se proyecta hoy | **1348 MiB** |
+| con `strip --strip-unneeded` sobre los ejecutables | **891 MiB** — un 34 % menos |
+| un binario suelto, `openssh`: `ssh` | **19,3 → 5,3 MiB**, un 72 % |
+
+La distancia entre el 34 % y el 72 % es la composición: en un escritorio buena parte de los bytes
+son datos —fuentes, iconos, traducciones— que no tienen símbolos. En `servidor`, dominado por
+binarios estáticos grandes (`rust` 364 MiB, `gitea` 219, `git` 216, `openssh` 202), el ahorro sería
+mayor. **No está medido para `servidor` y por eso no se pone un número.**
+
+⇒ Es la palanca barata para el tamaño de las descargas, y **no sustituye** al split dentro del
+build: eso sigue siendo lo que arregla los 126 G del store y del espejo.
+
 ---
 
 ## 3. 🧨 El hallazgo que condiciona CÓMO se hace: el entorno del lab NO está hasheado