SergioandClaude Opus 5
849c041446
SDD 25 §9 listó seis experimentos que no se pudieron correr y por qué. Cuatro de ellos sólo pedían privilegios, y esta sesión los tuvo. Programas y salidas crudas en docs/evidencia/tasas-kernel-2026-08-29/. 1. proc connector (bench_connector.c) — el sondeo de /proc no es lento, es CIEGO: 200 procesos de vida mínima lanzados uno cada 10 ms, sondeando cada 100 ms se ven **0 de 200**; por connector, **200 de 200**. Y esperar el evento no cuesta nada frente a waitpid (116,0 vs 114,8 µs, dentro del ruido), con 0 eventos perdidos en 1400. Sorpresa: taskstats por genetlink **no es más rápido** que parsear /proc/self/stat (2 688 vs 2 697 ns). Su valor es el CONTENIDO (delay accounting), no la velocidad. 2. reflink (bench_reflink.c) — el «copiar en O(1)» existe y NO está en ext4: FICLONE no soportado, y copy_file_range ≈ read+write (13,7 vs 14,5 ms). En xfs y btrfs es PLANO: 64 MiB en 0,010 ms y 512 MiB —ocho veces más— en 0,020 ms, contra 512,7 ms de read+write. **25 600× a 512 MiB.** 3. io_uring SQPOLL (bench_sqpoll.c) — no rescata el veredicto de T12: sobre datos cacheados pierde igual. ext4: pread 554 ns < io_uring 618 < SQPOLL 868. tmpfs: pread 749 < SQPOLL 1 409 < io_uring 2 030 (ahí sí mejora al io_uring normal, 1,4×, pero sigue perdiendo contra la syscall). Y se come un core. 4. syscalls por invocación de compilador — con el strace DEL PROPIO CORPUS (store/3c1fd8c0…-strace), que es la respuesta a «no hay strace en esta máquina». gcc: 1 803 syscalls por un `-c` trivial, **1 095 con error (61%), 919 de ellas readlink** — la canonicalización de rutas, que T8 no medía. Pero al piso de 78,7 ns son 0,14 ms sobre 30,5 ms de compilado: **el cruce al kernel es el 0,5%**. La tormenta de rutas vale milisegundos, no minutos. Condiciones distintas a la corrida original (load ~1,3 sobre 4 vCPU contra 7,3) ⇒ los absolutos NO se comparan entre corridas, sólo los cocientes dentro de una. 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.