diff --git a/docs/19-lanzamiento-publico.md b/docs/19-lanzamiento-publico.md new file mode 100644 index 00000000..9d72c903 --- /dev/null +++ b/docs/19-lanzamiento-publico.md @@ -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//`), 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.