sergioandClaude Opus 5
1eb469337d
El «79%» que este plan y los SDD 19/20 venían citando era **el 79% del CONTENIDO BINARIO**,
medido sobre una muestra de .so/.a. Es cierto y es la cifra equivocada para planificar, porque un
artefacto no es sólo binarios: trae cabeceras, datos, iconos, locales, .pc y documentación, que
no encogen.
MEDIDO con `scripts/medir-debug.sh` (suma los tamaños reales de las secciones .debug_* vía
readelf -S y los compara con el tamaño del árbol, sin reconstruir nada):
40 artefactos · 876 MB · 27%
100 artefactos · 2955 MB · 38% (truncada a 60 ficheros/artefacto)
250 artefactos · 8874 MB · 60% ← la que manda: sin truncar, ~7% del store
La varianza es alta porque unos pocos artefactos grandes dominan el total, así que el número
necesitaba validación independiente — y la tiene: el piloto de la etapa 2, donde se reconstruyó y
se pesó de verdad, dio bison −50% y appstream −68%. Los dos ENCIERRAN el 60% de la muestra
grande. El modelo predice lo que el rebuild produjo.
CIFRAS CORREGIDAS, con el store en 127 G:
se venía diciendo medido
reserva de disco ~96 G ~76 G
store tras el split ~30 G ~51 G
espejo público ~30 G ~51 G
Sigue siendo el mayor ahorro disponible en el proyecto —76 G no es poco— pero no es lo
prometido, y la diferencia importa para dimensionar el alojamiento del espejo, que es una
decisión con factura.
LA LECCIÓN: una cifra medida sobre una cosa (contenido binario) se citó durante semanas como si
midiera otra (tamaño de artefacto), y llegó a tres documentos. El número no era falso; LA UNIDAD
sí. Cuando un número vaya a decidir un gasto, hay que volver a la medición original y comprobar
QUÉ estaba midiendo.
Corregido en los tres sitios donde se había propagado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
151 lines
8.9 KiB
Markdown
151 lines
8.9 KiB
Markdown
# SDD 19 — Lanzar la distro al público: qué falta de verdad
|
|
|
|
Escrito 2026-08-07, a pedido del usuario («ve indicándome cuáles son los pasos necesarios para lanzar
|
|
la distro al público»). No es una lista genérica de «cómo se hace una distro»: cada punto está medido
|
|
contra el estado real del repo en esa fecha.
|
|
|
|
**La tesis**: lo que falta para *terminar de construir* no es lo mismo que lo que falta para *publicar*.
|
|
Lo primero es trabajo conocido y acotado. Lo segundo tiene dos cosas bloqueantes que hoy no existen —
|
|
metadatos de licencia y un espejo de fuentes— y que no se pueden improvisar el día del anuncio.
|
|
|
|
---
|
|
|
|
## 0. Lo que YA está (para no rehacerlo)
|
|
|
|
- **Formato de paquete y repositorio**: Etapa F completa — `pack` / `repo` / `install` / resolución de
|
|
deps / firma / DB de instalados / servidor HTTP, todo sobre `.swm`. Ver [SDD 06](06-swm-format.md).
|
|
- **Instalador TUI** y `base-system` completo (índice firmado de 748).
|
|
- **Seis perfiles de imagen** en `docs/state/targets.toml`: `base`, `cli`, `escritorio-mirada`,
|
|
`escritorio-kde`, `escritorio-gnome`, `escritorio-cosmic`.
|
|
- **El invariante que nos diferencia**: build determinista, bit a bit, direccionado por contenido.
|
|
1142 artefactos vigentes. Esto no es una promesa de marketing: es verificable por terceros, y en el
|
|
§3 se explica cómo convertirlo en evidencia pública.
|
|
- **Arranque soberano** (EFI-stub sin GRUB) y kernel propio que reproduce bit a bit.
|
|
|
|
---
|
|
|
|
## 1. Terminar el producto (trabajo conocido, sin sorpresas)
|
|
|
|
Ordenado por dependencia, no por gusto.
|
|
|
|
1. **Las 16 recetas pendientes.** 4 en GNOME (3 aparcadas por diseño: GTK3/X11/PAM) y 12 en el corpus
|
|
(cadena GUI de la cascada de mesa). **Ojo: las 12 fallan en el worker por su rootfs** (`python
|
|
OSError` en meson, `find_package` en cmake) y no se deben construir en el laptop por el zig-skew.
|
|
Hay que arreglar el entorno del worker primero, o declarar las herramientas en `[deps]`.
|
|
2. **WMs Wayland ligeros** (pedido del usuario). Candidatos naturales: `sway`/`labwc`/`river`/`niri`.
|
|
Baratos comparados con los escritorios completos: no hay torre de C debajo.
|
|
3. **Aplicaciones gráficas de terceros.** Acá está el trabajo grande y hay que ser honesto con el
|
|
tamaño:
|
|
- **Navegador**: el más caro de todo el catálogo. Firefox es Rust + C++ + su propio sistema de
|
|
build, y arrastra cbindgen, nasm, nodejs, y una cadena de `*-sys` con C++ que es justo la
|
|
frontera que el techo MSRV del sandbox no cruza todavía. Presupuestar como un frente propio.
|
|
- **Ofimática**: LibreOffice, del mismo orden de magnitud.
|
|
- **El resto**, mucho más barato: visor de imágenes, lector PDF, reproductor (mpv), gestor de
|
|
archivos, terminal, editor gráfico.
|
|
4. **Lo que no es una aplicación pero se nota si falta**: impresión (CUPS), bluetooth, gestión de red,
|
|
energía/suspensión, tipografías, locales e i18n, zona horaria, y cerrar el audio (falta
|
|
`wireplumber`: «el shell conecta» ≠ «hay sonido»).
|
|
|
|
---
|
|
|
|
## 2. 🚨 LO LEGAL — bloqueante, y hoy NO existe
|
|
|
|
Esto es lo que más fácil se pasa por alto y lo que puede obligar a bajar una descarga ya publicada.
|
|
|
|
### 2.1 Metadatos de licencia: eran **0 de 1141**; hoy van 228
|
|
> **CORRECCIÓN (mismo día).** Este párrafo decía «5 de 771 recetas los declaran», contado con
|
|
> `grep -l license recipes/*.toml`. **Los dos números estaban mal.** Los «5» eran falsos positivos:
|
|
> el paquete `addlicense`, el paquete `cargo-bundle-licenses`, una línea `install .../licenses/` y un
|
|
> comentario — `grep -l <palabra>` sobre TOML cuenta comentarios y nombres, no campos. Y las recetas
|
|
> son **1141**, no 771 (771 son los nodos del grafo del corpus). El número real era **0 de 1141**.
|
|
>
|
|
> **Estado actual**: campo `license` implementado **fuera de `hash_inputs`** (se puebla sobre recetas
|
|
> ya selladas sin mover un `ArtifactHash`; verificado en 40 recetas, 40 idénticos), `scripts/licencias.sh`
|
|
> que cuenta el campo de verdad, y **228 sembradas** desde una tabla curada. Faltan 913, casi todas
|
|
> CLIs Go/Rust — automatizables desde `Cargo.toml` y los `LICENSE` de los módulos Go.
|
|
>
|
|
> El catálogo completo está en [SDD 20](20-catalogo-publicable-y-completa.md); los pasos, en
|
|
> [SDD 21](21-manual-del-piloto.md).
|
|
|
|
Hace falta:
|
|
- Un campo de licencia **obligatorio** en la receta (con validación en `hammer`, no por convención).
|
|
- El texto de la licencia **dentro del artefacto** (`/usr/share/licenses/<pkg>/`), que es lo que
|
|
exigen GPL y familia al distribuir binarios.
|
|
- Un informe agregado por imagen: qué licencias entran en cada perfil y si alguna es incompatible.
|
|
|
|
### 2.2 Espejo de fuentes — la obligación real de la GPL
|
|
La GPL no pide «que el código exista en internet»: pide que **quien recibe el binario pueda obtener
|
|
la fuente correspondiente**, de vos. Hoy las recetas apuntan a URLs de terceros que se caen.
|
|
|
|
**Acá estamos en una posición inusualmente buena y hay que aprovecharla**: cada receta pinea tarball
|
|
+ `sha256`, así que el espejo de fuentes es un `fetch` de todo el corpus a un bucket, y además queda
|
|
verificable. Es trabajo mecánico, pero **debe existir antes de la primera descarga pública**, no
|
|
después.
|
|
|
|
### 2.3 Marcas
|
|
Redistribuir Firefox con su nombre y logo requiere cumplir la política de marca de Mozilla; por eso
|
|
Debian tuvo Iceweasel. Lo mismo con otros. Decidir por adelantado: cumplir o rebrandear.
|
|
|
|
### 2.4 La licencia de hammer mismo — ✅ ya está
|
|
> **CORRECCIÓN (mismo día).** Este punto decía «el repo no declara una». **Es falso**: hay un
|
|
> `LICENSE` (MIT) en la raíz y `license = "MIT"` en `Cargo.toml`. No lo miré antes de escribirlo.
|
|
> Este punto no bloquea nada.
|
|
|
|
---
|
|
|
|
## 3. Infraestructura pública
|
|
|
|
1. **Espejo de paquetes e imágenes.** Dimensionado: el store son 126 G, pero **~60% es información de depuración** ⇒ separar `-debug` en paquetes aparte baja el espejo a **~51 G** (medido en la etapa 3 del SDD 23; el «79%» que se citaba era sobre el CONTENIDO BINARIO, no sobre el tamaño de artefacto). Ver
|
|
[SDD 17](17-cierres-frontera.md) y la nota de capacidad.
|
|
2. **Cadena de firma de release.** Hoy hay firma de índice. Falta el nivel de arriba: una **clave raíz
|
|
fuera de línea**, claves de firma rotables, y un procedimiento escrito de qué hacer si se filtra
|
|
una. La firma sin gestión de claves es teatro.
|
|
3. **Evidencia de reproducibilidad publicada.** Esto es el diferenciador y hay que hacerlo explícito:
|
|
publicar, junto a cada imagen, los `ArtifactHash` de toda su clausura, para que un tercero
|
|
reconstruya y compare. Idealmente **un reconstructor independiente** que lo verifique en continuo.
|
|
Es lo que convierte «somos reproducibles» en un hecho comprobable por un extraño.
|
|
4. **Respuesta a seguridad.** Un canal para reportes, un proceso de avisos, y —lo más importante— la
|
|
capacidad demostrada de **empujar una actualización y que llegue**. Antes de publicar, ensayar el
|
|
ciclo completo con un CVE de mentira.
|
|
|
|
---
|
|
|
|
## 4. La experiencia de quien la instala
|
|
|
|
1. **Imagen instalable validada en METAL**, no sólo en QEMU. Regla ya aprendida: validar imágenes de
|
|
escritorio con PANTALLA, nunca sólo `-nographic`; y `/dev/console` es el serial, así que cada capa
|
|
debe escribir a `/dev/tty0`.
|
|
2. **Matriz de hardware honesta**: en qué se probó y en qué no. Vale más un «probado en estas 3
|
|
máquinas» que un «debería funcionar».
|
|
3. **Documentación mínima**: instalación, gestión de paquetes, cómo reportar un fallo. Sin esto, cada
|
|
usuario nuevo es una conversación privada.
|
|
4. **Sitio y página de descarga** con sumas y firmas, y las instrucciones para verificarlas.
|
|
5. **Un canal público** (issues + algo de chat) y un rastreador de fallos.
|
|
|
|
---
|
|
|
|
## 5. Sostenibilidad — lo que decide si sobrevive al primer mes
|
|
|
|
1. **Versionado y cadencia de release** decididos y escritos.
|
|
2. **Actualización en sitio probada de verdad**: instalar la versión N, actualizar a N+1, y que
|
|
arranque. Y **rollback**, que con un store direccionado por contenido debería ser barato: es la
|
|
ventaja natural de esta arquitectura y conviene que sea una función de primera clase.
|
|
3. **Reconstrucción desde cero reproducible** en una máquina limpia, cronometrada. Es la prueba de que
|
|
el proyecto no depende de un laptop concreto — que es exactamente la preocupación que originó el
|
|
respaldo del 2026-08-07.
|
|
|
|
---
|
|
|
|
## 6. El orden que yo propondría
|
|
|
|
**No se puede publicar sin**: §2 completo (licencias + espejo de fuentes + licencia propia), §3.2
|
|
(gestión de claves), §4.1 (imagen validada en metal) y §5.2 (actualización probada).
|
|
|
|
**Se puede publicar con huecos en**: §1.3 (aplicaciones de terceros — se puede lanzar sin navegador
|
|
propio y añadirlo después), §3.3 (el reconstructor independiente es un objetivo, no un requisito) y
|
|
§4.2.
|
|
|
|
**Lo que yo haría primero, hoy, porque es barato y desbloquea lo caro**: el campo de licencia
|
|
obligatorio en la receta. Mientras el corpus siga creciendo sin él, la deuda crece con él; a 771
|
|
recetas todavía es un rato de trabajo, a 2000 es un proyecto.
|