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
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.
«El más caro para el usuario es ffmpeg: sin él, un sitio que sirva H.264 no
reproduce» — el hueco más caro del mapa no existía. De los cuatro «sin receta»
quedan tres y ninguno es un códec.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
El §6.10 preguntó «¿qué NO puede hacer?» y contestó leyendo cadenas de sonames.
Media pregunta. Al hacer la otra mitad —¿se ve el vídeo?— salieron tres cosas:
DOS ERRORES DEL MAPA, los dos por leer una etiqueta en vez de medir:
- «no hay receta de ffmpeg» era falso: la hay, sellada, y ya viajaba en la
clausura de los cuatro escritorios por `mpv`. Lo que faltaba era la lista de
raíces del runner.
- «VA-API sin receta» también: `libva` está y está en las cuatro imágenes. El
hueco es real pero es el DRIVER — las tres mesa van `-Dgallium-va=disabled`.
Y queda anotado que ahora el mapa ya no lo puede ver, porque la librería
presente silencia el aviso sin encender la función.
UN BUG REAL: AV1 no reproducía. Gecko se come el primer elemento de
`LD_LIBRARY_PATH` al lanzar el RDD ⇒ sin appdir ⇒ ffvpx no carga ⇒ se cae al
ffmpeg del sistema, que no trae AV1 por software. Sin error, sin NEEDED
faltante, sin cadena ausente: `readyState=1` para siempre.
Y lo que quedó MEDIDO, por el lanzador de verdad y headless: H.264+AAC, VP9+Opus,
AV1, MP3 y FLAC reproducen, con el tiempo avanzando y no con «se creó el
decodificador» — que en AV1 se creaba igual y no entregaba un cuadro.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
El corpus queda entero tras la jornada: los dos únicos no sellados son `ajeno`
(steam-runtime-sniper, xwayland), que son frontera y no deuda.
atuq reconstruido sobre el firefox con PGO (b3:0acf6f58): 340 M, libxul de
227.802.816 bytes — el mismo del motor. La tesis del derivado sostenida: el
navegador propio se rehace en segundos sobre un motor nuevo.
Verificado que arranca desde una hidratación limpia de escritorio-sway, 0
errores de relocación. Y verificado que el PGO viaja EN EL ARTEFACTO y no sólo
en el configure: buildconfig.html dentro del omni.ja de atuq contiene
`profile-use`, junto a `wasi-sysroot` y `lto=cross`.
Nota de método: la CAPTURA no servía para esto. Salió byte a byte idéntica a la
de ayer porque la sección «Configure options» cae bajo el viewport — o sea que
una imagen igual no probaba que nada hubiera cambiado. El artefacto sí.
verificar-repro.sh: REPRODUCEN 1, DERIVA 0, NO-DETERMINISMO 0.
Era el riesgo real de esta unidad, no el rendimiento. El perfil es no
determinista por naturaleza; congelarlo como fuente pineada era el ARGUMENTO de
por qué el build seguiría siendo reproducible, y esto es la MEDICIÓN. Si
-fprofile-use hubiera metido cualquier decisión dependiente del orden o del
timing, habríamos cambiado velocidad por el invariante del proyecto.
El §3.ter daba dos muros —el display y el no-determinismo del perfil— y los dos
eran ciertos. Aparecieron tres más, ninguno visible sin construir:
1. libclang_rt.profile.a no existía: el lab trae clang pero NINGUNA runtime de
compiler-rt. El instrumentado murió en el minuto 38:56.
2. Los sandboxes de Firefox matan la corrida de perfilado con signal 11: el
proceso que renderiza no nace, 0 GET, y el .profraw que queda es el del
padre arrancando. Un perfil de nada, con todo en verde.
3. El worker no puede bajar del mirror: tiene mirror-env.sh pero no la clave.
Y queda escrito cómo se verificó que el PGO llegó, que NO pudo ser como RLBox.
Ahí el artefacto delata la jaula (símbolos w2c_*, cero -> 634). Acá el
discriminante análogo —las secciones .text.hot que clang emite al particionar
por temperatura— NO SIRVE: con lld y ThinLTO el enlazador las fusiona y dan cero
con PGO y sin él. La evidencia válida está un nivel bajo el configure: 189
invocaciones del compilador con -fprofile-use, llvm-profdata encontrado, cero
avisos de perfil que no cuadra, y libxul creciendo 1,7 MB.
Es evidencia de BUILD y no de ARTEFACTO, y conviene decirlo así en vez de
presentarla como si fuera lo mismo.
Ayer escribí que tres de los siete huecos eran «promoción y no autoría» porque
libsecret, libcanberra y vulkan-loader ya tienen receta sellada en colas
incoming. Fui a declararlas en los perfiles y lo comprobé antes: en los TRES
casos falta la otra mitad.
vulkan-loader las TRES mesa construyen con -Dvulkan-drivers= VACÍO
-> un cargador sin un solo ICD no es WebGPU
libsecret no hay receta de gnome-keyring ni de ningún servicio de
secretos -> firefox hablaría a org.freedesktop.secrets y no
habría nadie
libcanberra no hay receta de sound-theme-freedesktop -> carga y no suena
Declararlas habría subido el número de paquetes de la imagen sin encender una
sola función, que es la peor clase de verde. Una librería es MEDIA función; la
otra mitad es quien la atiende.
La misma vara sobre libnotify, que sí declaré ayer, medida perfil por perfil:
plasma-workspace en kde, gnome-shell en gnome, cosmic-notifications en cosmic —
completa en tres— y NADIE en sway. Ahí queda a medias y ahora está escrito cuál
es.
Y una trampa anotada para quien vaya a cerrarla: el nombre `mako` YA ESTÁ OCUPADO
en el corpus por el motor de plantillas de Python que usa Mesa para su codegen.
No es el daemon de wlroots. Escribir recipes/mako.toml para el daemon pisaría una
receta viva de la cadena de mesa — la colisión de homónimos que la memoria del
proyecto ya tiene anotada. Me lo comí yo: fui a ver si `mako` estaba sellado, dijo
que sí, y por poco lo cuento como «el daemon ya está».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
Sin esta línea la receta queda sellada y en NINGUNA imagen — la lección de `foot`
que este mismo fichero tiene escrita cuatro renglones más arriba de `atuq`, y que
la clausura no puede ver porque mide lo declarado.
Va en los cuatro perfiles que ya llevan el navegador (kde, gnome, cosmic, sway) y
NO en base/cli/mirada, que no lo llevan. Verificado parseando el TOML y no
leyéndolo: libnotify=1 en esos cuatro, 0 en los otros tres.
Medición al lado, con el vigía de sonames antes y después:
kde 306 -> 307 nodos 2083 -> 2086 sonames 0 sin proveedor
gnome 190 -> 191 657 -> 660 0
cosmic 161 -> 162 498 -> 501 0
sway 201 -> 202 509 -> 512 0
mirada 41 -> 41 231 -> 231 0 (no lleva atuq)
+1 nodo exacto por perfil, que es lo que se agregó, y el que no lo lleva no se
movió. Si hubiera arrastrado algo sin querer, el delta no sería 1.
Y una comprobación que el mapa de §6.10 no da y que es la que decide si el
`dlopen` va a funcionar: que resuelvan las deps de la PROPIA librería. Un dlopen
falla en silencio igual si libnotify está pero su gdk-pixbuf no. Se lo pregunté
al loader musl, no a mí:
ld-musl --list /usr/lib/libnotify.so.4
libgdk_pixbuf-2.0.so.0 => /usr/lib/... libgobject-2.0.so.0 => /usr/lib/...
libglib-2.0.so.0 => /usr/lib/... libgio-2.0.so.0 => /usr/lib/...
libc.so => /lib/ld-musl-x86_64.so.1
Toda la cadena cae dentro del rootfs salvo libc.so, que es la excepción del lab
ya documentada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
Sergio