SergioandClaude Opus 5
46dba58616
SDD 25 tenía medido el sandbox por namespaces (T14, ~1 ms por proceso) pero no el grano fino que harkaq pone dentro, que cobra por SYSCALL. `bench_jaula.c` lo mide con control negativo en las dos mitades (si la jaula no quedó puesta, sale con 2). seccomp: el filtro de harkaq es una denylist lineal, así que toda syscall legítima recorre la cadena entera — y aun así es PLANO en su longitud (86,9 ns con 4 entradas, 88,3 con 250, sobre un piso de 75,0). Lo que lo hace plano es el bitmap de acción constante del kernel, y eso no se supone: un gemelo de la misma longitud con una carga de args[0] —que hace que el analizador se rinda— sí crece, 111,6 → 139,9 ns. La regla que sale de ahí es que un filtro es gratis mientras no mire un argumento. El bitmap se paga al instalar (1,5 µs por entrada) y se amortiza en 2 830 syscalls, o sea una invocación y media de gcc, una sola vez por fase de build. landlock: el precio es ESTAR enjaulado (+473 ns por open), no cuántas reglas hay — pasar de 1 regla a las 16 384 de una clausura fichero a fichero agrega +225 ns más. La política por-fichero de D1, que era la decisión discutible, resulta casi gratis. Y dos negativas medidas: `stat` no paga (Landlock no engancha getattr) y un open DENEGADO sale más barato que uno concedido, al revés de lo que se esperaba al medirlo. En total, la jaula le cuesta a un compilado 0,23–0,31%: una décima parte del presupuesto de <5% de SDD 16. De paso, dos cosas del filtro que salieron de mirarlo para medirlo: la denylist tiene un techo de ~252 entradas por el __u8 de los saltos de la BPF clásica, y el jf se calcula leyendo y modificando `k` en la misma expresión (UB en C11, benigno con gcc y clang, comprobado). Y §9.6 queda con el experimento de PTI bien planteado: no es «el laptop daría peor» (compara dos máquinas y mezcla cuatro variables) sino la misma máquina con pti=on y pti=off. momento no sirve ni forzándolo: este invitado no expone PCID, así que mediría el peor caso y no el de un TigerLake. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
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.