Sergio
acccbc0a2c
DOM+layout+strings, FUERA del corpus: 23.540 -> 21.327 ms -9,4% SunSpider 3d-raytrace, DENTRO: 16.034 -> 15.878 ms -1,0% Mismo rootfs, mismo script, corridas intercaladas A/B/A/B, mediana de 7, calentamiento descartado; lo único que cambia entre variantes es un --ro-bind de /usr/lib/firefox. Los rangos no se solapan en ninguna de las dos, así que ambas diferencias son reales y no ruido. Yo esperaba lo contrario: que medir sobre el conjunto de ENTRENAMIENTO inflara la ganancia. Da el número MÁS BAJO, y la razón es mejor que la predicción: 3d-raytrace es aritmética pura en un bucle caliente, y ese bucle no lo ejecuta el C++ de SpiderMonkey sino código máquina que el JIT genera en runtime. El PGO optimiza el intérprete, el GC y el propio JIT — no lo que el JIT emite. Un benchmark JIT-bound es casi ciego al PGO por construcción. Donde se ve es en DOM/layout/arranque, que es C++ de punta a punta, y que además es lo que el usuario percibe: la medición cubre el ciclo completo del proceso (arrancar, renderizar, capturar, salir), no el régimen de una página cargada. Corolario anotado: el corpus de entrenamiento está sesgado hacia JS justo donde el PGO menos rinde. Un corpus con más maquetación probablemente daría más. Es su propia unidad de trabajo.
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 |
| 26 | atuq: el envoltorio Gecko |
Navegador propio como artefacto DERIVADO de firefox (no fork de fuente); la toolchain clang como puerta de PGO/LTO; qué se promete y qué no |
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/.