El directorio se movio de verdad, asi que las referencias absolutas dentro del
repo ya eran incorrectas. Tambien los ejemplos que usaban ~/hammer.
NO se tocan docs/evidencia/: son REGISTRO de lo que se corrio ese dia, y
reescribir una ruta ahi adentro falsifica la evidencia. Que nombren una ruta que
ya no existe es correcto: existia cuando se midio.
Cada arnés headless tenía su propio subconjunto de MOZ_DISABLE_*_SANDBOX, elegido en su
momento sin medir: banco 1 de 5, perfilar 4, codecs 3, ruteo 3, nativo 2, inicio 2. Con
cualquier subconjunto incompleto el sandbox de Firefox sigue intentando montar su
user-namespace dentro del de bwrap, falla con 'uid_map: EPERM' y deja un ayudante
'Sandbox Forked' muerto de SIGSEGV por cada intento — en el 100% de las corridas, después
de escribir el PNG y por eso invisible.
Medido: 2 cadáveres por corrida con sólo CONTENT apagado, 0 con los cinco. Verificado sobre
el arnés ya editado: segv=0 EPERM=0 screenshot=sí.
Acá no se pierde seguridad: bwrap ya es la jaula, el sandbox de Gecko es redundante y lo
único que hace dentro es fallar.
⚠ Cambia las condiciones de medición del banco de PGO: las cifras de docs/26 se tomaron con
el arnés viejo. Los cocientes del PGO comparan dos firefox bajo el mismo arnés y deberían
aguantar; la línea base absoluta de arranque no tiene por qué. Anotado en la cabecera.
No se tocan scripts/wlr/dunst-headless.sh (otro agente trabajando en él) ni los cazadores,
que conservan el entorno viejo a propósito para poder reproducir la condición original.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
El banco medía el ciclo COMPLETO del proceso (arrancar → renderizar → capturar → salir)
y nunca se midió cuánto de eso era arranque. Con una página vacía como control, y las 4
cargas × 2 variantes en UNA sola sesión intercalada (restar entre corridas de días
distintos no vale: la misma variante deriva ~1%):
maquetación trabajo 7281 → 4744 ms -34,8% (publicado: -10,9%)
carga ajena trabajo 4550 → 4634 ms +1,8% = cero, y es buena señal
SunSpider trabajo -34 → -6 ms bajo el ruido
Dos correcciones al documento:
1. El -10,9% es correcto para el ciclo completo pero se leía como 'firefox 11% más
rápido'. Sobre el trabajo de la página el PGO rinde -34,8%: tres veces más. El error
subestimaba el propio resultado.
2. La explicación que di del SunSpider era aire. Su trabajo mide -34 ms, NEGATIVO: la
página con el benchmark tardó menos que la vacía. No había nada que medir, y yo le
colgué encima una teoría sobre el JIT. La teoría puede ser cierta; esta medición
nunca la probó.
Las tablas viejas se dejan sin retocar, con un aviso arriba: el error de método enseña
más que el número corregido. Todo el rigor estadístico estaba puesto sobre una cantidad
que no era la que yo creía medir, y ninguna repetición lo habría revelado — sólo un
control, que costó siete corridas de una página vacía.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
Sergio