Al reconstruir atuq sobre el firefox con jarlog, murió:
zipfile.BadZipFile: Bad magic number for central directory (rebrand.py)
El jarlog convierte el omni.ja al formato «jar optimizado» de Mozilla, que mueve
el directorio central al principio:
sin jarlog: PK\003\004 ZIP estándar — zipfile lo abre, 5306 entradas
con jarlog: \376\204#\0 zipfile lo rechaza
Y atuq reempaqueta el omni.ja con zipfile para su branding. O sea que el jarlog
rompe el navegador propio de la distro.
La cuenta es asimétrica: el COSTE está medido y el BENEFICIO no —el banco corre
con caché caliente, donde reordenar el omni.ja no ahorra ninguna lectura, y dio
-0,1%, por debajo del suelo de ruido del propio banco—. Cambiar algo que
funciona por una ganancia que no se pudo medir, rompiendo algo que sí
funcionaba, es mal negocio.
Revertido a los hashes YA construidos y medidos (perfil 3647c6be, firefox
3d199174, atuq fab2fbfb): cero reconstrucciones. La documentación va fuera de
los campos hasheados, verificado antes y después.
Se retoma cuando (1) se mida el arranque EN FRÍO, que es su terreno, y (2)
rebrand.py sepa leer el jar optimizado o des-optimizarlo antes. El blob
92497cdd del mirror ya trae el jarlog: retomarlo es cambiar una línea.
Y LA LECCIÓN, que es la que más vale: el jarlog parecía GRATIS. «Es lo que hace
upstream y no cuesta nada» lo escribí yo en este mismo documento hace unas
horas. El coste no apareció midiendo el jarlog sino CONSTRUYENDO LO QUE DEPENDÍA
DE ÉL. Una función que se declara gratuita sin haber reconstruido a sus
consumidores no es gratuita: es no medida.
sin PGO v1 v2 v3 (= v2 + jarlog)
DOM/maquetación 23.008 20.851 20.527 20.502 (-10,9%)
SunSpider 16.006 15.859 15.869 15.838 (-1,0%)
jarlog solo: -0,1% y -0,2%
Indistinguible de cero, y el argumento no es que los rangos se solapen —que se
solapan— sino que la MISMA variante varía ~1% entre corridas de días distintos
(v1 dio 20.851 hoy y 21.050 ayer). El suelo de ruido del banco es diez veces el
efecto buscado.
No es un fallo del jarlog: el banco corre con la caché de página CALIENTE, y ahí
reordenar omni.ja no ahorra ninguna lectura. Su terreno es el arranque en frío,
que este instrumento no reproduce.
Lo que SÍ está probado es que la función existe, y del lado del artefacto:
libxul IDÉNTICO byte a byte entre v2 y v3, omni.ja distinto en 26 bytes. El
jarlog tocó exactamente lo que debía y nada más. Se conserva porque es lo que
hace upstream y no cuesta nada; lo que no se afirma es una ganancia no medida.
Y no hizo falta la extensión Quitter, que este mismo documento daba por
bloqueante: profileserver.py sólo traduce JARLOG_FILE a MOZ_JAR_LOG_FILE.
Anotado además: los dos atípicos del banco son 120.034 y 120.030 ms, o sea
exactamente el timeout del arnés. No son ruido de carga sino corridas COLGADAS
al arrancar en headless, 2 de 56 (~3,5%).
atuq b3:fab2fbfb, 340 M, libxul de 227.043.776 bytes: el mismo del motor con el
perfil de 46 páginas. Verificado que ARRANCA desde una hidratación limpia de
escritorio-sway, 0 errores de relocación.
El corpus queda en 860/862 sellados —los dos que faltan son `ajeno`, que es
frontera y no deuda— y el vigía de sonames en CERO huecos en los cinco perfiles.
sin PGO v1 (36 pág) v2 (46 pág)
DOM/maquetación 23.285 ms 21.050 (-9,6%) 20.640 (-11,4%)
SunSpider 3d-raytrace 16.003 ms 15.846 (-1,0%) 15.857 (-0,9%)
La mejora en maquetación NO se afirma por las medianas sino por la separación:
SEIS de las siete muestras de v1 son más lentas que TODAS las de v2; sólo una
cae dentro del rango de v2.
En SunSpider v1 y v2 son INDISTINGUIBLES —los valores se entrelazan por
completo—, que es exactamente lo esperable: ese camino lo ejecuta el JIT y el
PGO no lo toca. Un corpus mejor no puede mejorar lo que el PGO no alcanza. El
-0,9% frente al -1,0% no dice que v2 sea peor ahí: dice que no se distingue.
Una de las siete corridas de v2 dio 120.029 ms contra ~20.600 de las otras seis.
La mediana lo ignora por diseño; una media lo habría convertido en «v2 es
catastróficamente peor». Fue la razón de elegir mediana antes de ver un número.
Y lo que el banco no puede afirmar, escrito: las 10 páginas nuevas ejercitan los
mismos subsistemas que la página de medición, así que el parentesco con lo que
ahora se entrena es mayor que antes. El -11,4% es real para ESTA carga;
generalizarlo a «cualquier página» sería el mismo error que cometía el corpus de
Mozilla, en la otra dirección.
`scripts/test-atuq-inicio.py` le pregunta al motor por sus overrides en vez de
mirar el XPI en el disco: moz-extension://…/inicio.html en las dos, contra
about:home / about:newtab cuando se le saca el XPI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
Antes de escribir el crate del host en tawasuyu había que saber si el mecanismo
funciona en nuestro build. Funciona, y el cuadro deja las cuatro cosas que hacen
falta para escribirlo: dónde va el manifiesto (/usr/lib/mozilla, no el appdir),
qué instala de verdad la extensión (el escaneo de distribution/extensions, NO el
install_url de la política), que el host tiene que ser un proceso largo, y que el
único error que nombra la causa es el del puerto de connectNative.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
Con `--via-atuq` el emisor es `new Notification(...)` dentro del navegador, o sea
las cinco piezas: libxul dlopeando libnotify.so.4 (invisible para cualquier
auditor de ELF), D-Bus, la activación y dunst dibujando. Veredicto por el
`onshow` del motor: MOSTRADA #33 con el .service, «ERROR al mostrar» sin él.
Y deja probado de paso que en el proceso de atuq la GLib NO se duplica — usa la
cadena `-shared` que arrastra su GTK3, la misma contra la que enlaza
libnotify.so.4. El que la duplicaba era dunstify.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
El modo por defecto prueba la cadena del SISTEMA (`notify-send` → bus → dunst).
Éste prueba la que motivó todo el hilo del §6.10: una página llama a
`new Notification(...)`, `libxul` hace `dlopen("libnotify.so.4")` —que no es
NEEDED de ningún ELF, o sea invisible para cualquier auditor—, eso habla D-Bus,
el bus ACTIVA dunst y dunst dibuja. Cinco piezas, y la única forma de saber que
están las cinco es verlo.
El veredicto acá no puede ser el diff de píxeles solo: el navegador ocupa la
pantalla y repinta por su cuenta. Lo decisivo es el `onshow` del objeto
Notification, que es el motor diciendo que el sistema ACEPTÓ la notificación; el
diff queda como corroboración y la captura «antes» se toma con atuq ya pintado.
--via-atuq MOSTRADA #33 · 151.174 píxeles
--via-atuq --negative-control «ERROR al mostrar» · 0 píxeles
El control negativo también se lee distinto según el modo, y no por comodidad:
sin el .service, lo que tiene que faltar en el modo navegador es el onshow.
Captura en docs/evidencia/atuq-notificacion-web-sway-2026-09-07.png: dos globos
de dunst sobre la ventana de atuq, en sway headless, sin que nadie haya lanzado
el daemon a mano.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
`dunst` 1.12.2 atiende `org.freedesktop.Notifications` en el cuarto escritorio.
La prueba no es que la receta selle: el bus ACTIVA al daemon y el daemon DIBUJA
—14.832 píxeles cambiados con el .service puesto, 0 sin él—.
Y queda anotada la media función que apareció de paso: dunstify segfaultea por
las dos GLib (estática del corpus + compartida que arrastra libnotify.so.4), o
sea que en este corpus quién enlaza qué GLib es parte del contrato.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
Era la única mitad que quedaba abierta del mapa del §6.10: KDE atiende
`org.freedesktop.Notifications` con plasma-workspace, GNOME con gnome-shell y
COSMIC con cosmic-notifications; sway no tenía a NADIE, así que una página que
pedía notificar mandaba el mensaje al bus y se lo comía el silencio.
`dunst` 1.12.2 y no `mako` —que es el de la casa wlroots— por dos razones
medidas: el nombre `mako` YA ESTÁ OCUPADO en el corpus por el motor de plantillas
de mesa, y el cierre del perfil incluye las herramientas de build, así que la
imagen terminaría con dos artefactos homónimos peleando por las mismas rutas; y
mako habla D-Bus por sd-bus, que en musl es una receta nueva (basu), mientras
dunst habla por GDBus, que ya está sellado. Cero dependencias nuevas.
DOS GUARDIANES EN LA PROPIA RECETA, porque las dos cosas que importan no se ven
en que compile:
- `X11=0` es una intención; el hecho se lee en el ELF. dunst compila los dos
backends por defecto y su config.mk avisa: sin wayland «forzará xwayland». En
esta distro eso sella un binario que arranca, toma el bus y NO PINTA NUNCA. La
fase exige `libwayland-client` entre los NEEDED y prohíbe `libX11`.
- El `.service` de D-Bus es la mitad que importa: sin systemd, al daemon lo
levanta EL BUS. Se comprueba que reclame `org.freedesktop.Notifications` y se
le saca la línea `SystemdService=`, que acá no puede significar nada.
Y `DUNSTIFY=0`: entró primero en 1 y el binario **segfaultea hasta en
`--help`** (rc=139 en las tres pruebas). La causa es el cuadro que este repo ya
tiene escrito: nuestro `libnotify.so.4` es compartido y arrastra la cadena glib
`.so`, mientras esta cola enlaza la GLib estática ⇒ dos copias de GObject en un
proceso. No se pierde nada: el emisor de la casa es `notify-send`, que viene
DENTRO del artefacto de libnotify y ya está en las cuatro imágenes. Hay un
guardián que frena el día que alguien vuelva a poner DUNSTIFY=1 sin leer.
LA PRUEBA, en `scripts/wlr/dunst-headless.sh`: sway headless + bus de sesión +
`notify-send`, y NADIE lanza dunst a mano — lo activa el bus por el .service,
que es el mismo camino de una página web en atuq. La evidencia es un diff de
píxeles antes/después acotado al cuadrante donde dunst dibuja, porque un log en
verde es compatible con una pantalla vacía y el color no distingue (swaynag pinta
su barra de error en el mismo rojo).
positivo 14832 píxeles cambiados · servidor: dunst knopwob 1.12.2 1.2
control 0 píxeles · ServiceUnknown · notify-send rc=1
El control negativo borra el .service dentro del overlay temporal y EXIGE que no
se dibuje nada: probado en los dos sentidos.
Captura en docs/evidencia/dunst-sway-notificacion-2026-09-07.png.
Vigía de sonames: escritorio-sway 203 → 204 nodos, 512 sonames, 0 sin proveedor.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
Sergio