La actualización cierra la saga del parche de Qt 6.12 abierta el 12 de octubre, pero una nueva migración de OpenClaw traba las actualizaciones, omarchybot pasa su primer día sin cerrar ni fusionar nada, el kernel Linux 7.3 no llega a la fecha que Torvalds proyectó y Fedora declara el primer NO-GO de su calendario de lanzamiento.
Omarchy publicó este 18 de octubre la versión 4.0.5 en su repositorio de GitHub -ahora bajo la organización omacom, después de que la Fundación Omacom asumiera en agosto la marca y la infraestructura del proyecto-, con el salto a Qt 6.12, un nuevo kernel linux-omarchy 7.2.8 con el planificador BORE y una serie de correcciones de seguridad. Horas después, el mantenedor emirb cerró sin fusionar el pull request #15265, el parche de respaldo que desde el 13 de octubre intentaba llevar a la rama puntual v4-0-4 la corrección del apagón de pantallas por el choque entre Qt 6.12 y el singleton de color de Omarchy -el mismo fallo que esta sección documenta desde el 12 de octubre-. "4.0.5 is out with #14553 in it and there won't be another 4.0 release, so I'm closing this backport" -4.0.5 ya salió con el parche #14553 adentro y no habrá otro lanzamiento 4.0, así que cierro este respaldo-, escribió emirb en la página del parche. El parche original, identificado como #14553 y escrito por David Heinemeier Hansson, se fusionó a la rama principal quattro el 8 de octubre, pero nueve días de espera por un backport a la versión estable dejaron expuestos a quienes actualizaban Qt por su cuenta -el patrón por defecto en Arch Linux-, como documentaron al menos tres reportes distintos entre el 12 y el 17 de octubre. El cierre de hoy no es una corrección nueva: es la confirmación de que la vía del parche puntual quedó obsoleta en cuanto el propio ciclo de lanzamiento alcanzó a la versión con el arreglo adentro, un desenlace más lento que simplemente fusionar el backport cuando omarchybot ya lo había certificado como verificado el 17 de octubre. El episodio llega mientras la Fundación Omacom, que Heinemeier Hansson fundó en agosto con unos 8 millones de dólares de figuras como Michael Dell, Patrick Collison y Jack Dorsey -cifra que un resumen de terceros eleva a cerca de 18,5 millones con doce patrocinadores, según Daily.dev-, financia ahora a tiempo completo al desarrollador de Hyprland y contrató en setiembre a la cabeza de Quickshell. El contraste no pasó inadvertido entre los usuarios que siguieron el hilo: más dinero y más personal remunerado no evitaron que un parche ya confirmado tardara nueve días en resolverse por la vía más lenta posible. Costa Rica no reporta despliegues institucionales de Omarchy, pero la comunidad tica de software libre que esta sección sigue como personaje de la semana puede dejar de rastrear este hilo específico: la versión 4.0.5 ya incorpora la corrección de fábrica.
Toda máquina con el asistente OpenClaw instalado queda a medio actualizar desde hoy, porque la migración 1790397381 exige archivos que el paquete estable todavía no incluye, según confirmó el propio mantenedor.
El usuario abhi152003 abrió este 18 de octubre el issue #15804 en el repositorio de Omarchy: en la versión 4.0.5-1 del canal estable, el comando omarchy update instala los paquetes del sistema pero falla en la migración identificada como 1790397381, pensada para mover el asistente OpenClaw a una instalación autoactualizable bajo ~/.openclaw, y esa falla detiene el resto de las fases de la actualización. La migración necesita los archivos /usr/share/openclaw/install-cli.sh y /usr/share/openclaw/openclaw.tgz, pero el paquete openclaw 2026.10.4-1 que distribuye el repositorio estable instala el programa bajo /usr/lib/node_modules/openclaw y no incluye esos archivos semilla: la versión 4.0.5 publicó la migración antes que el paquete del que depende. La información proviene únicamente de los reportes y comentarios del propio repositorio de GitHub, sin cobertura de prensa especializada al cierre de esta edición. El mantenedor emirb confirmó el mismo 18 de octubre que la versión salió con la migración antes que su paquete y prometió una corrección en el próximo lanzamiento; mientras tanto, recomendó crear a mano el archivo marcador que señala la migración como completada y volver a correr omarchy update. El usuario Mystical89 reprodujo la misma falla en una segunda máquina y advirtió que, como el script omarchy-update corre con la bandera set -e, saltarse esa migración también salta el gancho posterior a la actualización, las actualizaciones de AUR, mise up y la limpieza de paquetes huérfanos -entre ellas, dos migraciones adicionales que corrigen un cuelgue de pantalla negra en el arranque y cambian la prioridad del repositorio propio de Omarchy-. Mystical89 pidió una cola de migraciones diferidas en vez de un simple marcador, y respaldó el pull request #14212, todavía abierto, que propone justamente eso. Al cierre de esta edición, ni el pull request #14212 ni el PR "DO NOT MERGE" #797 del repositorio de paquetes de Omarchy -que reintroduce el paquete semilla de OpenClaw- están fusionados, así que el truco del archivo marcador sigue siendo la única vía documentada para completar la actualización. Costa Rica no reporta despliegues institucionales de Omarchy ni de OpenClaw, por lo que el efecto inmediato queda limitado a quienes prueban la distribución por cuenta propia en el país.
cat /feed/omarchyterminal.md
El usuario fwends documenta un script que se relanza sin pausa cada vez que la lista de aplicaciones cambia, con picos de 80% de uso de procesador en una laptop en reposo.
> > omarchy debug --no-sudo --print
> > hidden-entries.sh: spawn storm, ~2-3 procesos nuevos por segundo
> El usuario fwends abrió este 18 de octubre el issue #15821 en el repositorio de Omarchy: tras actualizar a la versión 4.0.5-1 y a quickshell 0.3.2.r7.g2b4501a-1, el servicio /usr/share/omarchy/shell/services/hidden-entries.sh se relanza en bucle sin pausa, a un ritmo de entre dos y tres procesos nuevos por segundo, con picos cercanos al 80% de uso de procesador en una MacBook Air 7,2 con chip i7-5650U y 8 GB de memoria -una máquina que, según el propio reportero, queda casi inutilizable mientras está en reposo-. El propio usuario rastreó la causa hasta AppLibrary.qml, sin cambios entre las versiones 4.0.4 y 4.0.5: el bloque Connections que escucha DesktopEntries.applications activa hiddenEntryScan.running en cada señal sin ningún retardo (debounce), a diferencia del escaneo del índice de iconos, que sí tiene uno de 750 milisegundos.
> Con inotify, fwends registró una tormenta de lecturas sobre los archivos .desktop del sistema, prácticamente sin escrituras, lo que lo lleva a inferir -sin confirmarlo todavía- que el componente DesktopEntries de quickshell sigue releyendo y reemitiendo su modelo de aplicaciones, y que cada emisión dispara un nuevo escaneo. El propio reporte aclara que la relación con la actualización de quickshell es una inferencia, no una causa confirmada, y propone tres correcciones: agregar el mismo retardo que ya protege al escaneo de iconos, investigar por qué DesktopEntries emite cambios sin que haya archivos modificados, y evitar iniciar un escaneo nuevo si ya hay uno en curso.
> Al cierre de esta edición, el issue #15821 no tiene etiqueta, persona asignada ni pull request vinculado, y ningún mantenedor ha respondido. La información proviene únicamente del propio reporte en GitHub, sin confirmación independiente ni cobertura de prensa especializada. Costa Rica no reporta despliegues institucionales de Omarchy, por lo que el efecto inmediato sobre usuarios ticos se limita a quienes prueban la distribución por cuenta propia en equipos similares.
El filtro author:omarchybot sobre los pull requests del repositorio de Omarchy, consultado hoy para esta edición, muestra 237 resultados totales: 171 abiertos y 66 cerrados, de los cuales 39 siguen fusionados -la misma cifra de cerrados y de fusiones que esta sección reportó el 17 de octubre, cuando el total era 229, con 163 abiertos-. En 24 horas la cuenta abrió ocho pull requests nuevos sin que ninguno se cerrara ni se fusionara: es el primer día, desde que esta sección empezó a seguir la cifra el 15 de octubre, en que el conteo de cierres y de fusiones se mantiene exactamente igual que el día anterior. Los dos días previos mostraron el patrón contrario -cero fusiones nuevas, pero siete y luego ocho cierres sin aceptar-, lo que esta sección leyó como una cuenta que producía parches a un ritmo que sus mantenedores humanos rechazaban más rápido de lo que aprobaban. Hoy ese rechazo tampoco ocurre: los 171 pull requests abiertos simplemente se acumulan, sin que nadie los revise en ningún sentido. La tasa de aprobación histórica de la cuenta queda en 39 de 237, un 16,5%, la más baja desde que esta sección sigue la cifra. Ningún mantenedor de Omarchy ha explicado públicamente los criterios de revisión de la cuenta automatizada, ni confirmado si el nuevo estancamiento responde a un cambio deliberado de prioridades mientras el equipo gestionaba el lanzamiento de la versión 4.0.5 este mismo día. Sin impacto local conocido al cierre de esta edición: no hay registro de desarrolladores costarricenses que dependan del flujo de automatización de Omarchy para su propio trabajo.
El usuario huslage abrió este 18 de octubre el issue #15798 en el repositorio de Omarchy: según su propio diagnóstico, en la versión 4.0.4 es posible inscribir un token TPM2 con systemd-cryptenroll para la partición raíz cifrada con LUKS, pero el arranque sigue pidiendo la contraseña de todos modos, porque el gancho encrypt que Omarchy usa por defecto ignora los tokens TPM2 y el archivo /etc/crypttab. El usuario propone un comando nuevo, omarchy-setup-tpm-unlock, que cambiaría a los ganchos systemd y sd-encrypt, actualizaría la línea de arranque de Limine, inscribiría el TPM2 junto con una llave de recuperación y reconstruiría el initramfs, además de un comando inverso, omarchy-remove-tpm-unlock, para revertir el cambio. La propuesta llega un día después de que esta sección reportara el pull request #15709, que agrega el comando omarchy-drive-tpm con la misma intención de ligar el desbloqueo al chip TPM2; huslage no menciona ese parche en su reporte, y ambos esfuerzos conviven hoy como propuestas separadas y sin fusionar sobre el mismo problema. El propio huslage cita los issues previos #141 y #7222 como la raíz compartida del comportamiento, y ofrece implementar y probar el cambio si el equipo de Omarchy lo autoriza. Al cierre de esta edición, el issue #15798 no tiene etiqueta, mantenedor asignado ni pull request vinculado. La información proviene únicamente del propio reporte en GitHub, sin cobertura de prensa especializada. El cifrado de disco ligado a TPM ya es habitual en flotas corporativas con Windows en Costa Rica, así que cualquiera de las dos propuestas -la de ayer o la de hoy- reduciría la brecha de comodidad frente a esos entornos para un desarrollador tico que migre a Omarchy.
— La propuesta del issue #15798 dejaría intacta la contraseña de arranque por defecto, mientras documenta que los tokens TPM2 ya inscritos hoy no sirven de nada en Omarchy 4.0.4.
La séptima candidata, publicada el 12 de octubre, sigue siendo la última revisión del ciclo seis días después de que Phoronix reportara que Torvalds esperaba publicar la versión final justo hoy.
La página de etiquetas del repositorio torvalds/linux en GitHub, revisada hoy para esta edición, confirma que v7.3-rc7, publicada el 12 de octubre, sigue siendo la última candidata del ciclo: no hay ni una octava candidata ni una etiqueta de versión final al cierre de esta edición, pese a que hoy 18 de octubre era la fecha que Phoronix reportó como la que Linus Torvalds esperaba "hopefully" -con suerte- para el lanzamiento final, si el ciclo no necesitaba una rc8. El propio Torvalds escribió al publicar la rc7 que nada en ese parche parecía motivo para retrasar el cierre del ciclo, y que el calendario seguía apuntando al fin de semana siguiente salvo que surgiera algo nuevo. Phoronix también señaló que la actividad de parches subió al final del ciclo por una ola de cambios vinculados a trabajo con agentes de inteligencia artificial, el mismo tipo de actividad -agentes automatizados escribiendo parches- que esta sección documenta desde hace días en el propio repositorio de Omarchy. Que la fecha proyectada llegue sin lanzamiento no es una regresión: Torvalds había dejado explícitamente abierta la puerta a una rc8, que movería el cierre al 25 de octubre. Si aparece una rc8 en las próximas horas, el ciclo se extendería una semana más; si no aparece, la versión final podría publicarse en cualquier momento del resto del día. El kernel Linux corre en la mayoría de los centros de datos en la nube y en Android, así que cualquier infraestructura usada por empresas costarricenses heredará el resultado de este cierre de ciclo de forma indirecta, a través de las distribuciones que empaqueten el kernel 7.3 cuando esté listo.
Fedora declaró un primer "NO-GO" para el lanzamiento de la versión 45, según reportó Phoronix el 15 de octubre, después de que el equipo de la distribución no tuviera listos los medios de instalación de la candidata de lanzamiento a tiempo para la fecha original del 20 de octubre. El reporte confirma que el proyecto mantiene las dos fechas de respaldo que ya manejaba desde comienzos de octubre -el 27 de octubre y el 3 de noviembre-, con el 27 como la fecha que, según Phoronix, el proyecto espera sostener. El hito "Fedora 45 release" en el repositorio de GitLab de la documentación de notas de lanzamiento de Fedora, revisado hoy para esta edición, todavía muestra 17 tareas abiertas, 0 cerradas y una fecha límite del 20 de octubre -la misma fecha que el NO-GO ya descartó-, sin ningún aviso de que el hito se haya movido o archivado para reflejar el nuevo calendario. Es la octava jornada consecutiva, desde que esta sección empezó a seguir ese tablero el 11 de octubre, en que no se cierra una sola tarea, pero es la primera en que el propio proceso de lanzamiento, y no solo el tablero de documentación, confirma formalmente un atraso. Esta sección ya había señalado el 16 y el 17 de octubre que el tablero de documentación probablemente no reflejaba el riesgo real de la fecha, citando el comunicado de congelamiento final que calificaba de aceptables solo dos bloqueadores menores; el NO-GO confirma esa lectura escéptica en sentido contrario al optimismo de ese comunicado inicial. Fedora es una de las bases de desarrollo más usadas en universidades y empresas de software en Costa Rica por su ciclo de soporte corto y predecible, así que el atraso confirmado hoy retrasa en cadena las actualizaciones de quienes la usan como entorno de trabajo local, al menos hasta el 27 de octubre.
El domingo 18 de octubre cerró la semana más activa de Omarchy desde que esta sección empezó a seguirla: la distribución publicó la versión 4.0.5, que por fin lleva a la rama estable la corrección del apagón de pantallas por Qt 6.12 confirmada desde el 8 de octubre, y el mantenedor emirb cerró sin fusionar el parche de respaldo que ese arreglo volvió innecesario. El mismo día, un usuario reportó que la propia actualización dispara un bucle de procesos en el servicio hidden-entries.sh, otro documentó que la migración de OpenClaw bloquea la actualización estable en cualquier máquina con ese asistente instalado, y un tercero propuso una segunda vía de desbloqueo por TPM 2.0 que convive sin fusionar junto a la que esta sección reportó ayer. La cuenta automatizada omarchybot tuvo, además, su primer día sin un solo cierre ni una sola fusión, mientras su cola de pendientes subió a 171. Fuera del repositorio de Omarchy, el kernel Linux llegó a la fecha que Torvalds había proyectado para el lanzamiento final de la versión 7.3 sin una octava candidata ni una etiqueta de versión final, y Fedora confirmó formalmente el primer "NO-GO" de su calendario de lanzamiento, moviendo la fecha esperada del 20 al 27 de octubre mientras su propio tablero de documentación todavía no refleja el cambio. La semana que cierra hoy deja la misma lectura que las anteriores, pero más nítida: la financiación nueva de la Fundación Omacom y el ritmo de parches todavía no se traducen en una revisión humana más rápida.