GNU Linux-libre 7.1 elimina blobs de drivers Lontium, Realtek y Qualcomm; CachyOS lanza nueva versión con paquetes para x86-64-v4; Fedora 45 y Ubuntu 26.10 esperan el estable.
Linus Torvalds publicó el release candidate inicial del kernel 7.2 el 29 de junio, poniendo fin a la ventana de integración de cambios; el árbol supera por primera vez los 43 millones de líneas.
Linus Torvalds anunció la disponibilidad de Linux 7.2-rc1 el domingo 29 de junio, marcando el cierre formal de la ventana de merge del ciclo 7.2. Durante las dos semanas previas, los mantenedores de los subsistemas del kernel integraron sus cambios al árbol principal; el rc1 congela esa base y abre el período de pruebas —habitualmente de seis a ocho semanas de candidatos semanales— antes del lanzamiento de la versión estable. El dato más citado en la comunidad fue el tamaño del árbol fuente: con los cambios del ciclo 7.2 integrados, el repositorio del kernel supera las 43 millones de líneas de código por primera vez en su historia. La cifra incluye drivers, subsistemas de archivos, gestión de memoria, red, seguridad, y soporte para las decenas de arquitecturas de hardware que el kernel cubre. A modo de referencia, Linux 5.0 en 2019 tenía aproximadamente 26 millones de líneas; el crecimiento acumulado en siete años refleja la expansión hacia nuevas arquitecturas como RISC-V y LoongArch, el soporte de aceleradores de hardware especializados, y la incorporación sistemática de mitigaciones de seguridad estructurales. Fedora 45 y Ubuntu 26.10 —dos de las distribuciones que siguen el ciclo upstream más de cerca— tienen previsto incorporar Linux 7.2 como kernel predeterminado cuando se publique la versión estable, esperada para agosto de 2026. Esto convierte el rc1 de esta semana en el punto de partida de la cadena que determinará qué kernel usarán cientos de miles de usuarios en el segundo semestre del año.
cat /feed/kernellinux73preview.md
> Mientras Linux 7.2 inicia su fase de pruebas, ya hay cambios confirmados para el siguiente ciclo de desarrollo. Para el kernel Linux 7.3 —cuya ventana de merge abrirá hacia finales de 2026— se introdujo la propiedad DRM color format con soporte del driver AMDGPU, el componente del kernel que maneja las GPUs de AMD bajo la arquitectura DRM (Direct Rendering Manager).
> El cambio extiende la gestión de formatos de color en el stack de display de Linux, permitiendo al driver comunicar y negociar con el monitor el espacio de color óptimo: sRGB, DCI-P3, BT.2020 y variantes HDR. Hasta ahora esta negociación era parcial o dependía de soluciones en el espacio de usuario (como colord o kwin's color management), con resultados variables según el entorno de escritorio. Con la propiedad nativa en DRM, la gestión de color queda disponible para todos los stacks de display que usen el kernel, incluyendo Wayland compositors que no implementan su propia capa de gestión.
> El impacto práctico es mayor de lo que parece: usuarios de hardware AMD con monitores de alta gama en entornos de diseño y fotografía en Linux han reportado años de frustración con la gestión de color inconsistente. La adición en el driver AMDGPU abre el camino para que KDE Plasma y GNOME aprovechen la información nativa del kernel en lugar de heurísticas propias. Para Costa Rica, donde la adopción de Linux en estaciones de trabajo de diseño es incipiente pero creciente, este es el tipo de mejora que reduce la fricción con usuarios provenientes de macOS.
El proyecto GNU publica la versión 100% libre del kernel 7.1, depurando firmware no libre de tres subsistemas de hardware; el modelo defiende la independencia de hardware propietario.
El proyecto GNU publicó GNU Linux-libre 7.1, la versión del kernel Linux depurada de todo firmware y código no libre. La nueva versión limpia tres áreas de drivers que el kernel upstream de Torvalds incluye con blobs binarios: el bridge Lontium LT8713SX DP MST (usado en ciertos docks y hubs USB-C con DisplayPort multistream), los chips inalámbricos Realtek 802.11be 8922D (Wi-Fi 7), y blobs embebidos en el devicetree de algunos SoCs Qualcomm. El proyecto GNU Linux-libre, mantenido por Alexandre Oliva, parte de la premisa de que cualquier firmware binario en el kernel —aunque sea pequeño— representa una barrera a la libertad del usuario: el software no puede ser auditado, modificado ni redistribuido con las mismas garantías que el código fuente. Esta posición es más estricta que la del kernel upstream, que acepta firmware binario redistribuible cuando es necesario para que el hardware funcione. La consecuencia práctica es que GNU Linux-libre no es la opción ideal para quien necesite compatibilidad máxima de hardware. Sí lo es para entornos donde la libertad del software es un requisito —instituciones académicas, fundaciones de software libre, activistas digitales— o para hardware explícitamente soportado sin blobs (como el proyecto Libre Computer o placas compatibles con el movimiento RYF de la FSF). En Costa Rica, el MICITT y las universidades públicas (UCR, TEC) que han adoptado políticas de software libre son el contexto más cercano donde GNU Linux-libre tiene relevancia institucional.
La publicación de GNU Linux-libre 7.1 es también una oportunidad para plantear el debate que el proyecto GNU no resuelve sino que encarna: en 2026, con hardware Wi-Fi 7 (Realtek 8922D), docks USB-C con DisplayPort MST y SoCs Qualcomm en millones de dispositivos, ¿cuántos usuarios pueden sostener un sistema completamente libre sin sacrificar funcionalidad básica? La respuesta honesta es que pocos. El Wi-Fi 7 requiere firmware Realtek para funcionar; los docks DisplayPort MST usan chips Lontium que no tienen driver libre. Rechazar esos blobs significa, en la práctica, no tener conectividad inalámbrica moderna o no poder conectar múltiples monitores vía USB-C. El proyecto GNU Linux-libre asume que los usuarios elegirán hardware compatible con software libre, pero el mercado de hardware compatible es estrecho y caro comparado con el hardware convencional. La contraparte del argumento también es sólida: sin proyectos como GNU Linux-libre que documenten y señalen cada blob en el kernel upstream, la presión para que los fabricantes de hardware publiquen sus especificaciones y permitan drivers libres sería menor. GNU Linux-libre es útil no solo como sistema operativo sino como auditoría pública del estado de libertad del kernel. Para Costa Rica, la política de software libre del Estado —contemplada en directrices del MICITT— enfrenta exactamente esta tensión cuando el hardware de los servidores públicos requiere firmware no libre para operar.
CachyOS publicó esta semana una nueva versión de características para su distribución basada en Arch Linux orientada al rendimiento. El proyecto se distingue por compilar sus repositorios con optimizaciones que las distribuciones generalistas evitan: Profile-Guided Optimization (PGO), Link-Time Optimization (LTO) y BOLT (Binary Optimization and Layout Tool), además de paquetes específicos para las microarquitecturas x86-64-v3 (Haswell y posterior, con AVX2) y x86-64-v4 (Skylake-X y posterior, con AVX-512). La nueva versión integra de forma opcional el kernel Linux 7.2-rc1 en sus repositorios testing, acompañado del scheduler EEVDF con los parches de rendimiento habituales del proyecto. Para el kernel estable, CachyOS continúa ofreciendo múltiples variantes: linux-cachyos (optimizado para escritorio), linux-cachyos-server (ajustado para cargas de servidor), y linux-cachyos-lts basado en el kernel 6.12 LTS. El gestor de instalación Calamares recibió actualizaciones que simplifican la selección del perfil de microarquitectura durante el proceso de instalación, eliminando la necesidad de editar archivos de configuración manualmente. Para desarrolladores que compilan código de forma intensiva en su máquina de trabajo, los benchmarks publicados por el proyecto muestran mejoras de entre el 8% y el 23% en tiempos de compilación de proyectos grandes como LLVM y Firefox respecto a paquetes genéricos x86-64.
Con el lanzamiento de Linux 7.2-rc1, el reloj corre para dos de las distribuciones que más de cerca siguen el ciclo upstream del kernel. Fedora 45 —cuyo release está programado para octubre de 2026— y Ubuntu 26.10 —la versión no-LTS de Canonical de ese mismo mes— tienen previsto incluir Linux 7.2 como kernel predeterminado si la versión estable llega en tiempo. El calendario es ajustado pero factible: si el ciclo de release candidates de 7.2 sigue el patrón estándar (rc1 a rc7, una versión por semana), el kernel estable estaría disponible para mediados a finales de agosto, dando a los equipos de integración de Fedora y Ubuntu aproximadamente seis semanas para empaquetar, probar e integrar antes de sus fechas límite de freeze. Para los usuarios de Costa Rica que dependen de estas distribuciones —Ubuntu LTS es el estándar de facto en muchas empresas tecnológicas y en las universidades públicas— la noticia relevante es que el hardware moderno (GPUs AMD con soporte DRM mejorado, controladores NVMe de nueva generación, soporte de certificados en TPM 2.0) llegará con mayor madurez a sus escritorios y servidores hacia finales del año.
El 1 de julio de 2026 el ecosistema Linux llega con más noticias simultáneas que de costumbre. Linux 7.2-rc1 cierra la ventana de merge con el árbol más grande de la historia del kernel; GNU Linux-libre 7.1 defiende la frontera de la libertad del software eliminando tres grupos de blobs; CachyOS empuja los límites del rendimiento en hardware moderno; y Fedora 45 y Ubuntu 26.10 esperan en la puerta al kernel estable. Para el ecosistema Linux en Costa Rica —que tiene su núcleo en el MICITT, las universidades públicas (UCR, TEC, UNA), y una comunidad técnica activa en empresas de la zona franca tecnológica del GAM— el primer semestre terminó con señales positivas. La mejora continua en soporte de hardware moderno (Wi-Fi 6E/7, USB4, GPUs AMD y NVIDIA) reduce la fricción de adopción. El debate sobre firmware libre sigue vigente y tiene implicaciones directas para las políticas de software libre del Estado. El segundo semestre arranca con el kernel en pruebas, las distribuciones en preparación, y la comunidad global de contribuidores procesando 43 millones de líneas de código que representan décadas de trabajo colectivo.