SergioandClaude Opus 5
e1d58cc583
Misma divergencia que se encontró ayer en GNOME, medida igual: `hydrate-cosmic.sh` nombra 25 raíces escritas a mano dentro del script, el perfil `escritorio-cosmic` declara 43, y **17 paquetes declarados no llegaban al rootfs**: adwaita-cursors · xkeyboard-config · bash · atuq (el navegador) · mpv · swayimg zathura + zathura-pdf-poppler · dejavu-fonts y dejavu-fonts-nerd · libnotify desktop-file-utils · hicolor-icon-theme · y las cinco *-shared de runtime ⚠ EL PRIMERO NO ES UNA COINCIDENCIA: `adwaita-cursors` es EXACTAMENTE el ejemplo con el que la cabecera de `scripts/hydrate-profile.py` advirtió de esto el 2026-09-04 — «se añadió a las raíces de cosmic y sway, y los scripts de hidratación, que no la conocen, habrían seguido armando un rootfs sin cursores». No era hipotético: seguía pasando hoy, cinco días después. Y `xkeyboard-config` es la cicatriz de sway repitiéndose: sin él el compositor arranca sin mapa de teclado. Y AL REVÉS NO SE PIERDE NADA, que es lo que hace el cambio barato y lo separa del caso GNOME (donde primero hubo que mover 11 raíces de runtime al perfil): de las 25 del script, la única que el perfil no declara es `zlib-shared`, y la clausura del perfil la alcanza igual. O sea que el motivo que justificaba la lista a mano —los componentes que `cosmic-session` lanza por PATH, que ningún grafo de build ve— YA ESTÁ RESUELTO en el perfil, que los declara todos como raíces. La lista quedó redundante sin que nadie lo notara. VERIFICADO HIDRATANDO, no leyendo: `hydrate-profile.py escritorio-cosmic` proyecta 162/162 nodos (24166 ficheros, 4,8 G) y ahí están los 17. (Ojo con la sonda: `bash` instala en `/bin/bash`, no en `/usr/bin` — mi primer chequeo lo dio por ausente y era el chequeo el que miraba mal.) ⚠ Y UN DATO QUE MATIZA EL DIAGNÓSTICO Y LO EMPEORA. El rootfs que hay en disco (`escritorios/cosmic-rootfs`, 3,9 G) SÍ tiene cursores, xkb y mpv — o sea que no se armó con la lista por defecto, alguien le pasó raíces a mano. Y aun así le falta `atuq`. El problema real no es que la lista esté mal: es que **lo que llega a la imagen depende de lo que alguien se acuerde de teclear**. Derivarlo del perfil quita esa variable. El script se deja porque su cabecera documenta por qué COSMIC necesita raíces de runtime explícitas —sigue siendo cierto sobre la naturaleza de cosmic-session—; lo que ya no es cierto es que su lista sea la verdad. Los dos armadores de imagen (qemu y metal) ahora apuntan a `hydrate-profile.py`. ── Y de paso, una nota vieja de targets.toml corregida ──────────────────────────────────────────── Decía que el perfil de KDE «son 13 raíces de ARRANQUE EN METAL, no la imagen completa», con konsole/kate/dolphin y otras 19 apps selladas y sin declarar. Ya no: hoy son 48 raíces, con esas apps, las fuentes y las *-shared declaradas — el frente KDE lo reordenó y la nota quedó atrás. De su cola quedan 8 recetas fuera del perfil y son las que corresponde: libICE, libSM, libXtst y los cinco eslabones huérfanos de xwayland desde que se retiró su receta. Lo que a KDE le queda es OTRO problema, también medido hoy: su imagen no se hidrata del perfil sino de un rootfs YA ARMADO (8,4 G) que nadie re-deriva. De las 18 hojas del perfil están 15 — faltan `obs-studio` y `atuq`, justo las dos añadidas después de esa hidratación. Re-hidratarlo es decisión del frente KDE. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
hammer
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 comparta el sistema.
hammer no es otro gestor de paquetes inmutable. Es una arquitectura de dos mundos:
- El laboratorio compila desde fuentes upstream (commits fijados), de forma
determinista y aislada (
bubblewrap+zig cc+ musl estático), y direcciona cada artefacto por su hash (BLAKE3) en un content-addressed store. - El userland es un Linux clásico, mutable, con FHS de verdad (
/bin,/lib,/etc). Los binarios se hidratan desde el store por hardlinks. Puedes pisar archivos en caliente, romper cosas con unrm -rf, y revertir cuando quieras.
Entre ambos mundos viven las tres piezas que hacen a hammer distinto:
- Overlay de experimentación — prueba cambios sobre el sistema real con red de
seguridad;
hammer try/commit/discard. - Diario de mutaciones — un daemon
fanotifyregistra todo lo que tú (o la IA) cambiáis a mano. Vives imperativamente; el sistema genera el delta contra la base limpia. El diario es tu configuración — sin ser declarativa. - Manifiesto
.swm— compartes la receta de la mutación (parche de fuente + flags + ediciones de config), no el binario cocinado. El receptor reproduce y verifica; no confía en tu binario.
Encima de todo corre el bus de agente (/run/agent.sock): la IA habla un protocolo
pequeño y legible, dispara compilaciones, inyecta en el overlay, escucha fallos y reacciona.
Tú tienes la última palabra.
Estado
Fase de arranque. Validamos la capa AI-nativa sobre Alpine (musl + FHS ya cocidos)
antes de bajar a distro propia. Ver docs/10-roadmap.md.
Documentación de diseño (SDD)
Toda la arquitectura está en docs/. Empieza por
docs/00-vision.md y docs/01-architecture.md.
Estructura
crates/
hammer-core tipos compartidos: Recipe, Swm, hashing CAS, store
hammer-build el laboratorio: sandbox + compilación + hidratación
hammer-cli el binario `hammer` (build, hydrate, try, commit, apply, export…)
hammerd daemon: bus de agente + diario de mutaciones
docs/ SDDs y ADRs
Stack
| Capa | Decisión |
|---|---|
| Base de validación | Alpine (musl + FHS mutable) |
| Tooling / daemons | Rust (estático-musl) |
| Compilador del lab | zig cc por defecto, pluggable por receta |
| Sandbox de build | bubblewrap (namespaces) |
| Direccionamiento | BLAKE3 content-addressed store |
| Despliegue | Hidratación por hardlinks + patchelf |
Filosofía
La automatización es mi empleada en el sótano, pero en el piso de arriba mando yo.
Eficiencia matemática en la manufactura, libertad biológica en la ejecución.