David Heinemeier Hansson fusiona en persona la corrección del ícono de wifi y una reescritura que reduce el arranque del escritorio de casi 20 segundos a menos de uno; otras dos correcciones resuelven un interruptor de pantallas roto y una instalación que inflaba el disco con drivers de Nvidia de más; un nuevo reporte documenta un ícono de bandeja que desaparece, y el kernel Linux cumple una semana exacta desde su última candidata pública sin que aparezca la sexta.
El colaborador silversword411 abrió, el 9 de setiembre de 2026, la solicitud de incorporación de cambios #11015 en el repositorio omacom/omarchy en GitHub, fusionada este domingo 4 de octubre. La solicitud corrige tres problemas relacionados: el registro de widgets en la barra disparaba sincronizaciones en cascada de la API de complementos con complejidad cuadrática respecto al tamaño de la barra y la cantidad de monitores; el script de reinicio del escritorio esperaba un tiempo fijo a que el proceso anterior cerrara, pero ese cierre podía tardar entre 5,4 y 6,0 segundos -más que la ventana de espera-, lo que hacía que el reemplazo chocara con una instancia que todavía no liberaba su candado único; y el sistema instanciaba a la vez las versiones horizontal y vertical de los indicadores, duplicando procesos sin necesidad. En pruebas sobre un equipo con seis monitores y 23 widgets, el arranque del escritorio bajó de entre 19,8 y 20,3 segundos a 0,70 segundos, y el cierre de la instancia anterior bajó de entre 5,4 y 6,0 segundos a aproximadamente 1,2 segundos, según las mediciones incluidas en la propia solicitud. La corrección cierra, en un solo cambio, el origen común de varios reportes que esta sección ha documentado en días recientes: el reporte #14013, sobre actualizaciones que dejaban el escritorio inutilizable por el resto de la sesión, y el reporte #14085, sobre una barra que desaparecía por completo durante una actualización porque el script de reinicio esperaba apenas cinco segundos a que el proceso viejo confirmara su salida. La solución de hoy reemplaza esa espera fija por una verificación real del cierre del proceso mediante quickshell list, en lugar de un temporizador que adivinaba cuánto tardaría el escritorio en liberar sus recursos. La información de este caso proviene únicamente del propio repositorio, sin cobertura cruzada de otro medio especializado al cierre de esta edición. Costa Rica no tiene cifras públicas de usuarios de Omarchy con configuraciones de varios monitores, pero cualquier persona tica que use el escritorio en una estación de trabajo con más de una pantalla debería notar un arranque y un reinicio sensiblemente más rápidos desde la próxima actualización.
La solicitud de incorporación de cambios #14133, que David Heinemeier Hansson abrió el sábado 3 de octubre de 2026 en el repositorio omacom/omarchy, quedó fusionada este domingo 4 de octubre, según el propio registro en GitHub. El cambio -que esta sección reportó ayer como la nota principal de la edición- corrige que el ícono de wifi de la barra alternara entre el glifo de desconexión y las barras de señal en redes con modo de transición OWE; la versión fusionada basa la verificación de conectividad en el estado del dispositivo de red en lugar del SSID visible y consulta la intensidad de señal mediante nmcli sin forzar un nuevo escaneo. Que la solicitud se fusionara al día siguiente de abrirse, sin cambios adicionales reportados en el propio historial del repositorio, coincide con la lectura que la revisión automatizada del bot greptile-apps había hecho ayer: calificó el cambio de riesgo medio pero lo marcó como seguro de fusionar, con una suite de 4.069 pruebas que pasaron sin fallos. Es, junto con la solicitud #11015 que resuelve esta misma edición, la segunda corrección de Omarchy que DHH lleva de reporte a fusión en menos de 48 horas este fin de semana. La información de este caso proviene únicamente del propio repositorio, sin cobertura cruzada de otro medio especializado al cierre de esta edición. Costa Rica no tiene cifras públicas de usuarios de Omarchy que se conecten a redes OWE -comunes en aeropuertos y cafés con wifi abierto y cifrado oportunista-, pero cualquier persona tica en esa situación ya debería ver el ícono estable desde esta actualización.
— La solicitud que David Heinemeier Hansson abrió el sábado para detener el parpadeo del ícono de wifi en redes OWE quedó fusionada este domingo, con la revisión automatizada confirmando que no rompió ninguna de las pruebas existentes.
El colaborador houz42 abrió, en una fecha que el propio repositorio no precisa, la solicitud de incorporación de cambios #13725 en omacom/omarchy, fusionada este domingo 4 de octubre de 2026. El panel de pantallas de Omarchy usaba el comando hyprctl keyword monitor para apagar o encender un monitor, pero Hyprland rechaza ese comando bajo su sistema de configuración en Lua -no heredado- con el mensaje "keyword can't work with non-legacy parsers. Use eval", y aun así devolvía un código de salida exitoso, por lo que la interfaz no mostraba ningún error y el interruptor simplemente no hacía nada, según la propia solicitud. La corrección reemplaza esas llamadas por hyprctl eval usando la API hl.monitor -el mismo mecanismo que ya usan los scripts de escalado de monitores de Omarchy-, y agrega que el parámetro disabled se envíe explícitamente en false al volver a encender una pantalla, porque hl.monitor combina reglas y de otro modo conservaría la configuración de apagado anterior. El problema es parte de un patrón más amplio: a medida que Hyprland empuja a sus usuarios hacia el analizador de configuración no heredado, cualquier herramienta construida sobre comandos antiguos de hyprctl puede fallar en silencio en lugar de avisar. La información de este caso proviene únicamente del propio repositorio, sin cobertura cruzada de otro medio especializado al cierre de esta edición. Costa Rica no tiene cifras públicas de usuarios de Omarchy con configuraciones multimonitor avanzadas, pero cualquier persona tica que apague pantallas externas desde el panel de Omarchy -por ejemplo, al conectar una laptop a un solo monitor- debería notar que el interruptor vuelve a funcionar desde esta actualización.
El colaborador selfcrypto abrió la solicitud de incorporación de cambios #12569 en omacom/omarchy, fusionada este domingo 4 de octubre de 2026, que cierra el reporte #8856. El problema: Steam depende del paquete virtual lib32-vulkan-driver, y cuando pacman se ejecuta con la bandera --noconfirm -como hace el instalador de juegos de Omarchy-, elige automáticamente el primer proveedor disponible de ese paquete virtual, que resultaba ser lib32-nvidia-utils, de casi 1,8 gigabytes, sin importar si el equipo tenía o no una tarjeta gráfica de Nvidia, según la propia solicitud. La corrección reordena dos pasos de instalación para que el driver específico de la tarjeta gráfica del equipo -Intel, AMD u otro- se instale antes que Steam, de modo que ese driver correcto satisfaga primero la dependencia virtual y pacman ya no necesite elegir por defecto; un segundo cambio evita que el script auxiliar falle cuando no detecta ninguna tarjeta gráfica. El equipo probó la corrección en sistemas con Intel, AMD, configuraciones híbridas y equipos Nvidia con GSP, según la propia solicitud. Es el tipo de problema que un paquete virtual mal resuelto puede causar en cualquier distribución basada en Arch: una instalación silenciosa de casi dos gigabytes de software que la persona nunca necesitó. La información de este caso proviene únicamente del propio repositorio, sin cobertura cruzada de otro medio especializado al cierre de esta edición. Costa Rica tiene una comunidad de jugadores que instala Steam sobre hardware con tarjetas integradas Intel o AMD con más frecuencia que con tarjetas dedicadas Nvidia; quienes instalaron juegos con Omarchy antes de esta corrección debieron descargar casi 1,8 gigabytes de software que no iban a usar, sin que se conozca una cifra de cuántos equipos ticos se vieron afectados.
cat /feed/omarchyquickshell.md
El usuario spirosrap documentó este domingo que un ícono del sistema se queda en blanco justo cuando una aplicación vuelve de su variante de color a la monocromática -el momento exacto en que una alerta se resuelve.
> El usuario spirosrap abrió este domingo 4 de octubre de 2026 el reporte #14232 en el repositorio omacom/omarchy en GitHub, sin corrección ni mantenedor asignado al cierre de esta edición. El reporte documenta que un ícono de la bandeja del sistema queda en blanco cada vez que una aplicación cambia de un ícono de color a uno simbólico (monocromático), con un script de prueba que alterna el estado cada tres segundos y reproduce el fallo de forma consistente. La causa, según el propio reporte, está en el componente TrayIcon de shell/plugins/bar/widgets/Tray.qml: la propiedad visible y la propiedad layer.enabled cambian al mismo tiempo sobre el mismo ícono, y la capa parece muestrear una textura vacía cuando se vuelve a habilitar.
> El patrón que rompe es, justamente, el que usan las aplicaciones para avisar una alerta: un ícono monocromático en reposo que cambia a color cuando hay algo que atender, y vuelve a monocromático cuando la alerta se resuelve. Con este fallo, la persona pierde el ícono por completo en el momento exacto en que una notificación se resuelve, en lugar de ver la confirmación visual de que ya no hay nada pendiente. Es, además, el cuarto reporte sobre el escritorio Quickshell que esta sección documenta solo este fin de semana -junto a los casos de suspensión, Bluetooth y permisos de widgets reportados ayer-, y ninguno de los cuatro tenía persona asignada ni solicitud de corrección vinculada al cierre de esta edición: un patrón de reportes que se acumulan más rápido de lo que el equipo -todavía reducido frente al tamaño que ha alcanzado el proyecto- logra atender.
> La información de este caso proviene únicamente del propio repositorio, sin cobertura cruzada de otro medio especializado al cierre de esta edición. Costa Rica no tiene cifras públicas de usuarios de Omarchy con aplicaciones que alternan íconos de alerta en la bandeja, pero cualquier persona tica que dependa de ese aviso visual -por ejemplo, para notificaciones de mensajería- debería confirmar por otra vía que una alerta se resolvió, en lugar de confiar en que el ícono vuelva a aparecer.
Una semana exacta después de la quinta candidata, el repositorio torvalds/linux todavía no muestra una etiqueta pública v7.3-rc6 esta mañana, aunque el propio calendario semanal del ciclo deja abierta la posibilidad de que aparezca más tarde hoy.
El repositorio torvalds/linux en GitHub, consultado por esta sección la mañana de este domingo 4 de octubre de 2026, muestra a v7.3-rc5 -publicada el domingo 27 de setiembre- como la etiqueta más reciente del ciclo 7.3 del kernel Linux, sin que v7.3-rc6 aparezca todavía ni en la lista de etiquetas ni en la de lanzamientos del repositorio. Las cinco candidatas anteriores del ciclo se publicaron, todas, un domingo: rc1 el 30 de agosto, rc2 el 6 de setiembre, rc3 el 13, rc4 el 20 y rc5 el 27; si Linus Torvalds mantiene ese mismo patrón, rc6 todavía podría aparecer más tarde este domingo, horas después del cierre de esta edición. Esta sección documentó, el viernes y el sábado, que Torvalds ya venía fusionando ramas de varios mantenedores de subsistemas -sonido, aleatoriedad del núcleo, TPM, gestión de energía- etiquetadas con la referencia rc6 en su propio nombre, sin que eso se tradujera todavía en la etiqueta pública que marca el corte oficial de la candidata. Un ciclo de desarrollo del kernel no tiene fecha fija de por sí: Torvalds publica cada candidata según el volumen y la gravedad de lo que falta por fusionar, y ninguna fuente oficial ha señalado, al cierre de esta edición, un problema que esté retrasando el corte más allá del ritmo habitual del fin de semana. La fecha del lanzamiento estable de la versión 7.3 sigue en disputa entre el 18 y el 25 de octubre, según las fuentes que esta sección ya citó esta semana, sin que ninguna fuente consultada hoy permita despejar cuál de las dos prevalece. Costa Rica no tiene mantenedores identificados en el equipo de desarrollo del kernel, y el efecto de que rc6 aparezca unas horas más tarde o más temprano es, en la práctica, nulo para los usuarios ticos: las distribuciones que sí usan a diario adoptarán los cambios del ciclo 7.3 recién cuando lleguen a una versión de soporte extendido.
El domingo 4 de octubre de 2026 quedó marcado por la solicitud #11015, que redujo el arranque del escritorio Quickshell de Omarchy de casi 20 segundos a 0,70 segundos en equipos con varios monitores y cerró, de paso, el origen de al menos dos reportes de días anteriores sobre actualizaciones que dejaban el escritorio inutilizable. David Heinemeier Hansson, por su parte, vio fusionada la corrección del ícono de wifi en redes OWE que había abierto el sábado, y otras dos solicitudes resolvieron un interruptor de pantallas que fallaba en silencio bajo la configuración en Lua de Hyprland y una instalación de Steam que inflaba el disco con drivers de Nvidia en equipos sin esa tarjeta. La comunidad de Omarchy documentó, además, un nuevo reporte sobre un ícono de bandeja que desaparece justo cuando una alerta se resuelve -el cuarto fallo de Quickshell que esta sección registra solo este fin de semana, ninguno con persona asignada al cierre de esta edición-. En paralelo, el kernel Linux llegó al domingo sin publicar la sexta candidata de su ciclo 7.3, exactamente una semana después de la quinta, dentro todavía del margen que el propio patrón semanal del proyecto permite. Esta sección seguirá si alguna de las cuatro solicitudes y reportes de Quickshell documentados este fin de semana recibe una corrección, y si v7.3-rc6 aparece hoy o el patrón semanal del kernel se rompe por primera vez en este ciclo. Costa Rica no reporta impacto local confirmado de ninguno de estos frentes al cierre de esta edición, pero desarrolladores, jugadores y la comunidad tica de software libre que usan Omarchy a diario siguen expuestos, en distinta medida, a cada una de las fallas documentadas hoy.