sergioandClaude Opus 5
794d9b595e
/usr/bin/gnome-shell construido desde fuente, con sus cuatro typelibs (St-16,
Shell-16, Gvc-1.0, Shew-0) y el NEEDED cerrando en artefactos sellados + libc.so:
cero fuga al sysroot de Alpine.
El draft estimaba "~10 recetas nuevas, dominadas por eds+icu". Fueron 13, pero
casi ninguna donde el mapa las esperaba. Lo que la última tanda destapó:
dbus-shared la cima enlaza atk-bridge-2.0, cuyo .pc Requires atspi-2 y ése
dbus-1 — el dbus canónico es estático no-PIC y el configure ni
llegaba a compilar. Cuarta variante -shared de la cadena, todas
por la misma raíz: el corpus se construyó para un userland
ESTÁTICO y el escritorio es dinámico por obligación.
pulseaudio la frontera llegó por el camino más indirecto de la campaña:
+ libsndfile gnome-shell incluye el subproyecto gvc (el control de volumen)
SIN condicional (meson.build:256) y gvc pide libpulse duro.
Se construye SÓLO EL CLIENTE (-Ddaemon=false): gvc necesita
HABLAR el protocolo, no implementarlo, y el demonio de sonido de
esta distro es una decisión aparte todavía abierta (PulseAudio vs
PipeWire) que construir el daemon habría cerrado de prestado.
libsndfile con --disable-external-libs = una receta, no cinco.
Dos parches al árbol, ambos verificados antes de aplicarse:
· subdir('po') fuera (:324). CUARTA vez que el msgfmt de gettext-tiny aborta
con SIGABRT, acá en po/ar.po; ya pasó en iso-codes, gcr y eds. La deuda está
clara: hace falta el gettext de GNU de verdad.
· los #include <X11/Xlib.h> y <X11/Xatom.h> de src/shell-app-usage.c son
VESTIGIALES — el fichero no usa un solo símbolo de X11. El código X11 real
(el tray XEmbed) SÍ está cerrado por have_x11_client, que sale de mutter y
acá es false. shell-app-usage.c quedó fuera del guard por olvido del upstream.
Y --undefined-version en pulseaudio: usa UN version-script para las tres libs
cliente, así que al enlazar libpulse.so el script nombra símbolos de
libpulse-simple y libpulse-mainloop-glib. GNU ld avisa; lld corta. Mismo flag que
libtiff-shared.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.