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
Documentación de diseño de hammer
Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.
Software Design Documents (SDD)
| # | Documento | Qué cubre |
|---|---|---|
| 00 | Visión y filosofía | Por qué existe, qué problema resuelve, la actitud de ingeniería |
| 01 | Arquitectura general | El modelo de dos mundos, componentes, flujo de datos |
| 02 | El laboratorio de build | Sandbox, zig cc, recetas, CAS, grafo de dependencias |
| 03 | Hidratación y store | Store content-addressed, hardlinks a FHS, patchelf, rollback |
| 04 | Overlay de experimentación | overlayfs en caliente, try/commit/discard |
| 05 | Diario de mutaciones | fanotify, log append-only, config-sin-ser-declarativa |
| 06 | Formato .swm |
Manifiesto de mutación compartible, esquema, firma |
| 07 | Bus de init y de agente | /run/init.control, /run/agent.sock, protocolo |
| 08 | Integración de la IA | El bucle agéntico, seguridad, intención → .swm |
| 09 | Modelo de confianza | Reproducibilidad, verificar-no-confiar, log de transparencia |
| 10 | Roadmap | Fases, MVP, primer entregable |
| 11 | Bootstrap from-scratch | Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned |
| 12 | arje como init real del Stage 1 |
Contrato de runtime: seed card, hammerd supervisado, CRASHED real |
| 16 | harkaq: la jaula de hammer | Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad |
Runbooks (operativos)
| Runbook | Para qué |
|---|---|
| Validar Stage 1 booteando en QEMU | stage0→stage1→initramfs→QEMU; criterios de éxito y troubleshooting |
Architecture Decision Records (ADR)
Decisiones tomadas, con su contexto y consecuencias. Ver adr/.