docs: SDD 19 — qué falta de verdad para lanzar la distro al público

Lo que falta para TERMINAR de construir no es lo mismo que lo que falta para
PUBLICAR. Lo primero es trabajo conocido (16 recetas, WMs Wayland ligeros,
apps de terceros — con el navegador como frente propio). Lo segundo tiene dos
bloqueantes que hoy no existen y no se improvisan el día del anuncio:

1. METADATOS DE LICENCIA: sólo 5 de 771 recetas los declaran. La distro no sabe
   bajo qué términos redistribuye el 99% de lo que empaqueta. Hace falta campo
   obligatorio validado por hammer + el texto dentro del artefacto.
2. ESPEJO DE FUENTES: la GPL no pide que el código exista en internet, pide que
   quien recibe el binario pueda obtener la fuente correspondiente DE VOS. Acá
   estamos bien parados —cada receta pinea tarball+sha256— pero hay que hacerlo.

Más: gestión de claves (firma sin eso es teatro), evidencia de reproducibilidad
publicada como diferenciador comprobable, imagen validada en METAL, y ciclo de
actualización ensayado antes de publicar.

Recomendación de arranque: el campo de licencia obligatorio, ya. A 771 recetas
es un rato; a 2000 es un proyecto.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-07 08:27:14 -04:00
co-authored by Claude Opus 5
parent 809b154586
commit b12ea3ac9d
+138
View File
@@ -0,0 +1,138 @@
# 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: **5 de 771 recetas los declaran**
Medido el 2026-08-07: `grep -l license recipes/*.toml` da **5**. O sea que la distro no sabe bajo qué
términos redistribuye el 99% de lo que empaqueta.
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
El repo no declara una. Sin eso, legalmente nadie puede contribuir ni derivar.
---
## 3. Infraestructura pública
1. **Espejo de paquetes e imágenes.** Dimensionado: el store son 126 G, pero **el 79% es información
de depuración** ⇒ separar `-debug` en paquetes aparte baja el espejo a ~30 G. 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.