SergioandClaude Opus 5
893b126c31
Cierran las 24 que quedaban de una vuelta. El barrido de la frontera queda así: 327 opcional,
25 provisto, 10 nix-ismo, 3 pendientes. Arrancó la jornada en 152 pendientes.
⚠ SÉPTIMO ALIAS, y resuelve el enigma que dejé abierto esta mañana. libmpc → mpc: nixpkgs llama
`libmpc` a GNU MPC y `mpc` al cliente de MPD; acá GNU MPC se llama `mpc`. O sea que el «lo piden
mpc y yambar» de libmpdclient no era un error del sembrador cruzando mal: es que los dos catálogos
usan el MISMO nombre para paquetes DISTINTOS. Las dos puntas de esa confusión quedan cerradas.
Van siete alias y cinco formas: puntuación, mayúsculas, prefijo `lib`, versión en el nombre, y
ahora homonimia cruzada.
Lo demás, cada uno con su prueba en la receta o en el fuente: libev cae por el mismo
--enable-lib-only de nghttp2 que c-ares (configure.ac:230); graphite2 por -Dgraphite=disabled;
libliftoff por -Dlibliftoff=disabled; libtasn1 por -Dtrust_module=disabled; libasyncns por
-Dasyncns=disabled; inih por -DEXIV2_ENABLE_INIH=OFF contra un default ON; rdma-core por
--disable-rdma. nanosvg y resvg caen juntas porque fuzzel VENDORIZA nanosvg (su receta ya lo
decía) y fcft va con -Dsvg-backend=none. boost-build no hace falta porque la receta de boost es
sólo cabeceras. validate-pkg-config no es una librería sino un setup hook de nixpkgs → nix-ismo.
CAPACIDADES AUSENTES que quedan dichas: sin polkitd no corren las reglas .rules de JavaScript
(duktape); no se regula el brillo de un monitor EXTERNO por DDC/CI (ddcutil); los PDF con
tipografías CJK no incrustadas se ven mal (poppler-data); dolphin navega sin panel de metadatos
ni etiquetas (baloo-widgets).
⚠ LOS TRES QUE NO FIRMO, y por qué. No son «opcional»: son huecos de RUNTIME que ninguna receta
delata al construir, y decidirlos es elegir alcance de la distro, no triaje. Los tres con la
medición hecha y escrita en su `porque`:
gnome-keyring NINGÚN artefacto del store declara org.freedesktop.secrets (grep sobre el store
entero), y el artefacto de kwallet trae sólo libKF6Wallet.so, sin kwalletd6. Los
dos escritorios tienen el PROMPTER sellado y ninguno tiene el ALMACÉN
glib-networking los usr/lib/gio/modules/ de los cuatro artefactos de glib están VACÍOS ⇒ GIO no
tiene TLS, y libsoup 3 delega el TLS en GIO ⇒ HTTPS mudo en el stack GNOME
xdg-desktop-portal-kde los únicos backends de portal sellados son el de cosmic y el de gnome; la
cola kde no tiene ni receta de xdg-desktop-portal ⇒ en Plasma la captura de
pantalla de obs-studio (linux-pipewire → portal ScreenCast) no tiene con quién
hablar, mientras que en GNOME y COSMIC sí
Los tres son el mismo patrón que ya nos costó una noche con las fuentes: una raíz que no resuelve
queda `wanted` y NINGUNA métrica lo dice. Marcarlos `hueco` los mete como raíz en targets.toml y
al drenaje; eso lo decide el usuario.
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.