SergioandClaude Opus 5
133e1dd802
De 78 pendientes a 53. Caen enteras opencv, swayimg, networkmanager, gwenview, appstream y
plasma-desktop.
⚠ CORRECCIÓN, y es de las que cambian lo que uno haría. En dos commits de hoy avisé que cairo
(lzo) y xwayland (libdecor) piden esas libs con `auto`/`required:false` y que «si entran al
catálogo, el ArtifactHash cambia sin que nadie lo pida». El mecanismo está mal: el sandbox de
hammer monta SÓLO las deps declaradas (docs/02-build-lab.md §3.4 — raíz tmpfs y bind read-only de
las deps del store), así que meterla en [deps] mueve hash_inputs y SE VE. La vía por la que un
`auto` sí muerde en silencio es otra y ya está documentada: que la lib aparezca en el LAB, que no
entra en hash_inputs. Los dos `porque` quedan corregidos en el fichero; el aviso sigue valiendo,
pero apunta al lab y no al catálogo.
Lo demás, cada uno con su prueba:
opencv -DBUILD_LIST=core,imgproc ⇒ de todo OpenCV se construyen DOS módulos: gflags y
glog son del dnn y hdf5-cpp del hdf, ninguno en la lista. eigen y openblas caen
por -DWITH_EIGEN=OFF y -DWITH_LAPACK=OFF, explícitos
swayimg -Davif/-Dheif/-Draw/-Dsixel=disabled, los cuatro escritos en la receta
networkmanager newt es la dep de nmtui y el propio meson lo dice en su assert (meson.build:806:
«Use -Dnmtui=false to disable it»), que es justo lo que pasamos; slang es su
back-end. bpftools cae por -Debpf=false
gwenview cfitsio (FITS de astronomía), libkdcraw (RAW) y kimageannotator son TYPE OPTIONAL
en su CMakeLists; qtimageformats no aparece ahí — son plugins de Qt de runtime
appstream -Dstemming=false para libstemmer
plasma-desktop kaccounts-integration es TYPE OPTIONAL y su PURPOSE lo dice («OpenDesktop
integration plugin»); xf86-input-evdev y xf86-input-libinput son drivers del
SERVIDOR X y la distro no corre uno; plasma-sdk no aparece en su CMakeLists
⚠ QUINTO, SEXTO Y SÉPTIMO DESFASE DE VERSIÓN: xapian, libfyaml y libblake3 no aparecen en NINGÚN
meson de AppStream 1.0.5, que es la que pineamos. Ya van siete candidatos que salen de expresiones
de nixpkgs más nuevas que nuestros pines (openapv, libebur128, spandsp, libglycin y estos tres).
Es un patrón, no una casualidad: cuando el `porque` heurístico dice «lo pide una sola receta»,
mirar primero si la versión pineada la nombra sale más barato que razonar sobre la feature.
⚠ dnsmasq no es una librería: NM la declara `type: 'string'` (meson_options.txt:10), una RUTA a un
binario que ejecuta. Capacidad ausente —compartir la conexión y el DNS con caché— no dep rota.
Y gnome-keyring sigue pendiente, ahora con la medición terminada escrita en su `porque`: el grep
sobre el store ENTERO dice que NINGÚN artefacto declara org.freedesktop.secrets, y del lado KDE el
artefacto de kwallet trae sólo libKF6Wallet.so — la librería cliente— sin kwalletd6. Los dos
escritorios tienen el prompter sellado y ninguno tiene el almacén.
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.