La ventana de pruebas de la 4.5.0-rc1 deja fallos de seguridad y de teclado, el kernel abre su ventana de fusión 7.4 y LibreOffice firma dos parches en 24 horas.
La ventana de pruebas de la versión candidata deja un reporte que permite borrar, con permisos de superusuario, todos los idiomas instalados del sistema.
El repositorio oficial del proyecto Omarchy en GitHub acumuló al menos diez reportes de error nuevos entre el 21 y el 22 de octubre, después de que la comunidad probara la versión candidata 4.5.0-rc1 publicada el 20 de octubre. El reporte más señalado, abierto el 22 de octubre por el usuario mrjamesmyers como incidencia #16244, describe que el comando omarchy language, que corre sin contraseña a través de una regla de sudoers, puede borrar el archivo de caché con todos los idiomas instalados cuando el disco está casi lleno -dejando el sistema solo con los locales C y POSIX- sin que el comando reporte ningún error. El mismo día se abrieron reportes sobre un bloqueo total de la interfaz tras reanudar el equipo desde suspensión (incidencia #16246, con etiqueta "bug") y sobre los nuevos atajos Súper+M y Súper+I de la propia 4.5.0-rc1, que se agregan sobre combinaciones ya definidas por el usuario sin ningún aviso (incidencia #16227). Ninguno de estos reportes tenía respuesta oficial del equipo de mantenimiento al cierre de esta edición, según el estado "abierto" que muestra el propio repositorio; la información proviene únicamente del registro público de incidencias en GitHub, sin cobertura cruzada de prensa especializada todavía. La propia nota de lanzamiento de 4.5.0-rc1 había advertido que la candidata "puede contener errores" y recomendado probarla en un equipo que no sea crítico -una advertencia que esta tanda de reportes confirma en la práctica, después de que los días previos destacaran sobre todo las funciones nuevas, el financiamiento corporativo y el fondo de recompensas de US$100.000 que respaldan al proyecto. Omarchy no ha fijado fecha para una segunda candidata ni para la versión estable 4.5.0; el autor de la incidencia #16244 ofreció una corrección propia que todavía no fue fusionada. Costa Rica no reporta instalaciones corporativas de Omarchy; la base de usuarios local se concentra en desarrolladores individuales que siguen el proyecto por su integración con herramientas de IA.
El proyecto llega a la cita del 22 de octubre sin haber publicado todavía una versión candidata de prueba, después de declarar un "no-go" la semana pasada.
Fedora celebra este jueves 22 de octubre la reunión de go/no-go que debe decidir si el lanzamiento de Fedora 45 se mantiene en el 27 de octubre o se posterga hasta el 3 de noviembre, según el calendario del proyecto recogido por Linux Compatible y Phoronix. El proyecto ya había declarado un primer "no-go" el 15 de octubre sin ninguna versión candidata disponible para pruebas -una modalidad inusual, porque los "no-go" previos del proyecto solían originarse en errores bloqueantes abiertos, no en la ausencia total de una candidata. La demora contrasta con el resto del ecosistema que El Pisuika ha venido siguiendo esta semana: Ubuntu 26.10 entregó el kernel 7.3 sin sobresaltos el 15 de octubre, y Omarchy pasó directamente de un parche de emergencia a su propia versión candidata 4.5.0-rc1 el 20 de octubre. Fedora, respaldada por Red Hat, sigue un proceso de gobernanza más formal que exige un historial de errores despejado antes de declarar una versión lista, lo que explica por qué un "no-go por defecto" -sin bloqueantes identificados- resultó inusual incluso para sus propios estándares, según había señalado la arquitecta de operaciones Aoife Moloney en la lista devel-announce del proyecto. Al cierre de esta edición, Fedora no había publicado el resultado de la reunión de hoy; si confirma el "go", la versión 45 llegaría el 27 de octubre, y si no, la fecha de respaldo es el 3 de noviembre. Costa Rica no tiene industria de empaquetado de Fedora; las instituciones que dependen de RHEL o Fedora reciben esta versión con semanas de retraso respecto a Ubuntu, a través de los canales oficiales de Red Hat.
Linus Torvalds publicó el kernel Linux 7.3 el 18 de octubre y, dos días después, comenzó a fusionar en su árbol principal los primeros pedidos de incorporación de subsistemas para la versión 7.4, según el historial público del repositorio oficial torvalds/linux en GitHub. Entre el 21 y el 22 de octubre, Torvalds integró el árbol de Rust -identificado como "rust-7.4" y mantenido por Miguel Ojeda-, los árboles de seguridad LSM, SELinux y auditoría, y los de sistemas de archivos como XFS, GFS2, erofs, fscrypt y fsverity, entre otros. La ventana de fusión es el período de aproximadamente dos semanas en que Torvalds acepta cambios nuevos antes de pasar a una serie de versiones candidatas semanales que depuran errores; la 7.3, publicada el 18 de octubre, llegó después de siete candidatas entre agosto y octubre. La continuidad del árbol "rust-7.4" confirma que el soporte de Rust dentro del kernel sigue sumando subsistemas, en la misma línea de lo que el propio proyecto Rust for Linux había declarado en diciembre de 2025 sobre dejar atrás la etapa experimental. La información de este cierre de edición proviene directamente del historial de fusiones del repositorio, sin una cobertura adicional de medios especializados todavía disponible. Torvalds suele cerrar la ventana de fusión unas dos semanas después de abrirla, tras lo cual el kernel 7.4 entra en su ciclo de candidatas semanales; no hay fecha fija de lanzamiento final más allá del patrón reciente de alrededor de nueve semanas entre versiones mayores. Costa Rica no participa del desarrollo del kernel; el país recibe esta versión meses después, cuando las distribuciones que usa localmente -Ubuntu, Fedora, RHEL- la empaquetan.
El mantenedor del kernel estable Greg Kroah-Hartman publicó el 21 de octubre cuatro versiones de mantenimiento -7.2.12, 6.18.58, 6.12.114 y 6.6.160-, firmadas con su llave GPG, según el espejo oficial en GitHub del árbol estable de Linux. Las cuatro ramas corresponden a series todavía activas de soporte extendido: 7.2 es la línea previa a la 7.3 actual, mientras 6.18, 6.12 y 6.6 son ramas de largo plazo que distribuciones empresariales y equipos de producción mantienen durante años después de su lanzamiento original. El propio repositorio no detalla en sus notas de lanzamiento el número de parches ni las vulnerabilidades específicas corregidas en esta tanda -una limitación habitual de las versiones de mantenimiento del kernel, que remiten al registro completo de cambios para el detalle técnico; la información de esta nota proviene únicamente de ese historial de control de versiones. La cadencia de actualizaciones estables es, sin esa información puntual, el mecanismo primario por el que la mayoría de los usuarios de Linux recibe parches de seguridad, incluso cuando no siguen de cerca el desarrollo del kernel. Costa Rica no participa del mantenimiento del kernel estable; el país recibe estas versiones de forma indirecta, cuando distribuciones como Ubuntu, Debian o RHEL las incorporan a sus propios ciclos de actualización, generalmente con semanas de diferencia.
— Las nuevas versiones 7.2.12, 6.18.58, 6.12.114 y 6.6.160 llegan a las ramas de soporte extendido que todavía reciben parches de seguridad y corrección de errores.
El proyecto LibreOffice publicó el 22 de octubre la versión 26.8.2.2, un día después de la 26.8.2.1 del 21 de octubre, según el registro de etiquetas del repositorio oficial del código fuente, LibreOffice/core, en GitHub. Christian Lohmaier, gestor de lanzamientos del proyecto -identificado en el repositorio con el usuario cloph-, firmó ambas versiones dentro de la misma ventana de 24 horas. Las dos versiones corresponden a la rama 26.8, la línea de mantenimiento más reciente de la suite ofimática de código abierto, que recibe actualizaciones de corrección de errores cada pocas semanas mientras la rama 26.2, más antigua, sigue en soporte extendido. El propio repositorio no detalla en sus notas de lanzamiento qué errores corrige esta tanda; la información sobre estos dos lanzamientos proviene únicamente de ese historial de control de versiones, sin cobertura adicional de prensa especializada al cierre de esta edición. LibreOffice no ha anunciado cambios de calendario para su próxima versión de funciones. Costa Rica no tiene datos propios de adopción de LibreOffice, pero la suite es la alternativa de código abierto más usada en instituciones públicas de la región que buscan evitar licencias comerciales de ofimática.
El 21 y el 22 de octubre combinaron la primera ola de reportes de error sobre la versión candidata de Omarchy, la reunión decisiva de Fedora 45 y la apertura de la ventana de fusión del kernel 7.4. LibreOffice, en paralelo, publicó dos versiones de mantenimiento en 24 horas. Ningún hecho de esta edición tuvo epicentro en Costa Rica: el país sigue estos desarrollos a través de desarrolladores individuales y de las distribuciones que empaquetan estas actualizaciones semanas después.