Un bug atribuido a un agente de Gemini puede saturar Omarchy con más de 300 mil procesos al abrir el navegador, el parche confirmado contra el choque de Qt 6.12 cumple ocho días sin fusionarse, omarchybot tiene su primer día sin una sola fusión nueva frente a siete cierres sin aceptar, un usuario documenta cómo Btrfs puede agotar espacio de metadatos pese a mostrar gigabytes libres, el kernel Linux 7.3 declara obsoleto el modo journal de ext4 en su séptima candidata y Fedora 45 llega a cuatro días de su plazo sin una sola tarea cerrada.
Un reporte firmado por un agente de Gemini describe cómo una configuración común de navegador predeterminado hace que Omarchy se relance sin control hasta agotar el límite de procesos del sistema, con un parche ya propuesto y todavía sin fusionar.
El usuario cacarr-pdxweb abrió este 15 de octubre el issue #15581 en el repositorio de Omarchy, firmado con la línea "filed by Gemini 3.8 Flash (High) via Google Antigravity" -presentado por el modelo Gemini 3.8 Flash a través de la herramienta de programación agéntica Antigravity-. El reporte describe que cuando el manejador predeterminado de enlaces http y https del sistema queda apuntando a omarchy-browser.desktop -algo que ocurre, según el propio reporte, al ejecutar xdg-mime default omarchy-browser.desktop x-scheme-handler/http o con ciertas configuraciones de ~/.config/mimeapps.list-, el script omarchy-launch-browser se interpreta a sí mismo como el navegador que debe abrir y se relanza sin límite a través de systemd-run: en minutos satura el límite de procesos del segmento user-1000.slice, deja los núcleos del procesador al 100% y genera, en palabras del propio reporte, "over 300,000 processes/units" -más de 300 mil procesos o unidades-, hasta que utilidades básicas como notify-send y nmcli empiezan a fallar con errores SIGABRT. El fallo no requiere ninguna configuración exótica: basta con que el manejador de enlaces del sistema -una preferencia que cualquier usuario puede cambiar sin saber que apunta de vuelta al propio lanzador- quede mal apuntado. El colaborador AnPod respondió el mismo día con el pull request #15610, que hace que omarchy-launch-browser detecte cuando el manejador configurado es él mismo y se niegue a ejecutarse, imprimiendo un error en vez de relanzarse; según el propio autor, una prueba nueva que simula la configuración circular falla sin el cambio y pasa con él. La revisión automatizada de greptile-apps dejó un solo señalamiento, de prioridad P2, sobre un script de prueba que no queda marcado como ejecutable, sin objeciones al diseño de la corrección. La información proviene únicamente del repositorio de GitHub de Omarchy, sin cobertura de prensa especializada al cierre de esta edición. Al cierre de esta edición, el pull request #15610 sigue sin revisión de un mantenedor humano ni fusión. Costa Rica no reporta despliegues institucionales de Omarchy, pero la comunidad tica de software libre que prueba el canal estable del proyecto -personaje de la semana en esta sección durante los últimos cinco días- debería revisar su manejador predeterminado de enlaces antes de que una actualización futura reintroduzca, sin aviso, la misma condición de carrera.
El usuario p4k9 abrió el 15 de octubre el issue #15545 en el repositorio de Omarchy: tras una actualización a Qt 6.12, la interfaz completa -barra, menú, notificaciones, pantalla de bloqueo, selector de imágenes- se renderiza en negro opaco, con más de 200 advertencias de tipo TypeError en el registro al iniciar. Según el propio diagnóstico de p4k9, confirmado con una prueba propia, los archivos Bar.qml, Menu.qml y LockView.qml importan el módulo qs.Commons sin alias, de modo que cualquier referencia a Color resuelve al tipo nativo que QtQuick 6.12 agrega en vez del singleton de paleta de Omarchy -la misma causa raíz que esta sección documentó por primera vez el 12 de octubre. La corrección ya existe desde el 8 de octubre en la rama principal quattro, y el pull request #15265, abierto el 13 de octubre para llevarla a la versión estable 4.0.4, recibió el 15 de octubre la confirmación más clara hasta ahora de que funciona: el usuario duyetpt escribió en la página del parche que lo probó en una instalación nueva y que "cleared the palette warnings in testing" -despejó las advertencias de paleta en sus pruebas-. A pesar de esa confirmación, ningún mantenedor con permiso de fusión ha movido el pull request, que cumple ya ocho días desde que el cambio original llegó a la rama principal sin llegar a ningún usuario del canal estable. El patrón se repite: cada día que el backport no se fusiona, usuarios que actualizan Qt por su cuenta -como ocurre por defecto en Arch Linux- reportan el mismo síntoma como si fuera nuevo. Costa Rica no reporta despliegues institucionales de Omarchy, pero la comunidad tica de software libre que sigue el canal estable del proyecto sigue expuesta al mismo apagón de pantallas mientras el parche confirmado no se publique.
El filtro author:omarchybot sobre los pull requests del repositorio de Omarchy, consultado hoy para esta edición, muestra 228 resultados: 170 todavía abiertos y 58 cerrados, de los cuales 39 fueron fusionados -la misma cifra de fusiones que esta sección reportó el 15 de octubre, cuando el total era 226, con 175 abiertos y 51 cerrados-. La aritmética muestra que, en 24 horas, la cuenta abrió solo dos pull requests nuevos mientras siete de los que ya estaban abiertos pasaron a cerrados sin que el conteo de fusiones se moviera: los siete terminaron rechazados o abandonados, no aceptados. Es el primer día de la semana en que el número de cierres sin fusionar supera por completo al de fusiones nuevas -cero-, después de varios días consecutivos en los que esta sección reportó al menos una fusión adicional diaria, aunque fuera una sola. La tasa de aprobación histórica de la cuenta, que rondaba el 17% hasta ayer, queda hoy en 39 de 228, apenas 17,1%, prácticamente estancada; pero la composición del día -cero fusiones, siete rechazos- es la lectura más crítica que esta sección ha podido hacer del experimento desde que comenzó a seguirlo la semana pasada. Ningún mantenedor de Omarchy ha explicado públicamente los criterios con que decide cerrar un parche de la cuenta sin fusionarlo, ni qué modelo o modelos redactan cada propuesta. 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.
La etiqueta v7.3-rc7 del repositorio torvalds/linux, publicada el 12 de octubre, sigue siendo la última candidata del ciclo cuatro días después, según confirma hoy la página de etiquetas del proyecto en GitHub. El sitio especializado Warp2Search reportó que la rc7 llegó unas seis horas más tarde de lo habitual porque Linus Torvalds confundió el día tras asistir a la Cumbre de Mantenedores del Kernel y a la Linux Plumbers Conference, y que el parche es exclusivamente de correcciones: incluye 58 cambios de endurecimiento de espacios de nombres de montaje del mantenedor de VFS Christian Brauner, un parche de compatibilidad para el error de hardware AMD TLBI Erratum #1718, y la marca formal de que el modo data=journal de ext4 queda obsoleto, con retiro planeado para 2028. La deprecación de data=journal no afecta al modo por defecto de ext4 -data=ordered-, pero sí a instalaciones que lo activaron de forma explícita para maximizar la integridad de datos sobre el rendimiento, un ajuste poco común fuera de servidores de bases de datos antiguos. Combinada con el endurecimiento de montajes de Brauner, la rc7 confirma que el ciclo 7.3 se concentra en seguridad y limpieza de deuda técnica más que en funciones nuevas, en línea con lo que Phoronix había anticipado para esta fase del ciclo. Si no aparece una octava candidata, el lanzamiento final seguiría proyectado para el domingo 18 de octubre, dos días después de esta edición; una rc8 lo movería al 25 de octubre. Se trata de una fecha todavía no confirmada por un anuncio oficial de Torvalds al cierre de esta edición. 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á este cambio de forma indirecta, a través de las distribuciones que empaqueten el kernel 7.3 cuando ext4 con data=journal reciba, eventualmente, un aviso de retiro.
cat /feed/omarchyterminal.md
El usuario soojy documentó cómo el filesystem Btrfs puede devolver errores de espacio agotado mientras df todavía reporta espacio libre, porque el chequeo de actualizaciones de Omarchy solo mira esa cifra.
> > btrfs filesystem usage /
> Data,single: Size:453.73GiB Used:426.34GiB
> Metadata,DUP: Size:5.00GiB Used:4.45GiB
> Unallocated: 1.00MiB
> El usuario soojy abrió el 15 de octubre el issue #15528 en el repositorio de Omarchy: en una instalación con raíz Btrfs sobre un disco NVMe de 464 gigabytes, los chunks de datos ocuparon todo el dispositivo sin dejar espacio sin asignar para nuevos chunks de metadatos, y operaciones que necesitaban metadatos empezaron a fallar con el error ENOSPC -a pesar de que el comando df reportaba 27,39 gigabytes libres-. Según el propio reporte, los chunks de datos estaban al 94% de uso y los de metadatos al 89%, mientras fallaban Docker, 1Password, journald y los bloqueos de sockets Unix bajo /home desde las 6:06 de la mañana.
> El reporte señala que la herramienta de Omarchy omarchy-update-requires-free-space, que bloquea actualizaciones cuando el disco está lleno, solo revisa la salida de df y por eso no detectó el problema: una actualización corrió igual durante el incidente. Omarchy no configura ninguna política de reclamo o balanceo automático de Btrfs, y el kernel Linux, según explica el propio reportero, solo libera por defecto los bloques completamente vacíos, sin activar el reclamo dinámico que existe desde la versión 6.11. El propio soojy aplicó un balanceo manual con btrfs balance start -dusage=50,limit=4 / que recuperó el servicio, y propone que Omarchy active el reclamo dinámico de datos por defecto o que el chequeo de actualizaciones lea directamente la asignación real de Btrfs en /sys/fs/btrfs, un dato de acceso público que df no refleja.
> El pull request #15590, vinculado al issue, sigue abierto y sin revisión humana al cierre de esta edición. El propio reporte aclara que no es una regresión de una versión puntual sino un vacío de prevención que puede afectar a cualquier instalación con el diseño por defecto de Omarchy -LUKS con raíz Btrfs- sobre el tiempo suficiente. Costa Rica no reporta despliegues institucionales de Omarchy ni de Btrfs como sistema de archivos raíz en infraestructura crítica, por lo que el efecto directo sobre usuarios ticos es, por ahora, limitado a quienes prueban la distribución por cuenta propia.
El hito "Fedora 45 release" en el repositorio de GitLab de la documentación de notas de lanzamiento de Fedora muestra, al cierre de esta edición, 17 tareas abiertas y 0 cerradas, con el hito en 0% completado, a cuatro días de su fecha límite fijada para el 20 de octubre de 2026 -el mismo balance que esta sección reportó el 15 de octubre, ahora en su sexto día consecutivo sin un solo elemento cerrado en ese tablero específico. LinuxCompatible y Warp2Search habían reportado a comienzos de octubre que el congelamiento final de Fedora 45 entró en vigor el 6 de octubre con solo dos bloqueadores aceptados -una imagen de Server para aarch64 de tamaño excesivo y una falla de autenticación WiFi vinculada al servicio de secretos oo7-, lo que sugiere que el tablero de documentación que esta sección sigue no necesariamente refleja el riesgo real de la fecha de lanzamiento. Pero seis días seguidos sin ningún cierre, a solo cuatro días del plazo, acortan el margen para que ese argumento siga sosteniéndose sin evidencia nueva. Fedora mantiene dos fechas de respaldo, el 27 de octubre y el 3 de noviembre, si el calendario se atrasa. El indicador real seguirá siendo si el proyecto confirma el lanzamiento el 20 de octubre como estaba previsto. 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 un atraso en esta fecha retrasaría en cadena las actualizaciones de quienes la usan como entorno de trabajo local.
— El tablero oficial de hitos en GitLab repite las mismas diecisiete tareas abiertas y ninguna cerrada que mostraba ayer, ahora a cuatro días de la fecha de lanzamiento fijada para el 20 de octubre.
El viernes 16 de octubre cerró la semana de Omarchy con un susto nuevo y dos frentes crónicos: el issue #15581, atribuido a un agente de Gemini, documentó cómo una configuración común de navegador predeterminado puede desatar una bomba de más de 300 mil procesos, con un parche ya propuesto y todavía sin fusionar. El choque entre Qt 6.12 y el singleton de color del proyecto, que esta sección sigue desde el 12 de octubre, cumplió ocho días con una corrección confirmada que funciona y que ningún mantenedor ha fusionado, y la cuenta automatizada omarchybot tuvo su primer día sin una sola fusión nueva frente a siete pull requests cerrados sin aceptar. Fuera de las alertas del repositorio, el kernel Linux confirmó que su séptima candidata del ciclo 7.3 trae endurecimiento de montajes y la deprecación formal del modo data=journal de ext4, de cara a un lanzamiento final todavía proyectado para el 18 de octubre, y el tablero de hitos de Fedora 45 llegó a cuatro días de su plazo sin una sola tarea cerrada. La semana que cierra hoy deja un patrón más claro que el de días anteriores: la automatización de Omarchy produce reportes y parches a un ritmo que sus propios mantenedores humanos no están absorbiendo al mismo paso.