Vivaldi 7.9 revoluciona su navegador permitiéndote auto-ocultar sus componentes para que sólo te centres en la web

Vivaldi 7.9

Vivaldi 7.9 no deja de sorprendernos. Hace menos de dos meses nos entregaron la v7.8 del navegador, incluyendo la posibilidad de crear mosaicos arrastrando y soltando pestañas, entre otras novedades. Hoy han lanzado Vivaldi 7.9, y han introducido algo que, por lo menos a mí, me recuerda un poco a Zen Browser: una función que permitirá auto-ocultar ciertos elementos para que nuestra navegación sea mucho más inmersiva, tal y como podréis ver en el vídeo de debajo.

Ahora mismo, si pulsamos F11, la pestaña (o pestañas si usamos la vista dividida) se mostrará a pantalla completa, lo mismo que ya vemos en otros navegadores. Pero en Vivaldi 7.9, si pulsamos F11 después de Ctrl (o Comando en macOS), activaremos lo que en inglés se llama «Auto-hide»: ocultará todo y se mostrará si pasamos el cursor por encima.

Vivaldi 7.9 y su Auto-Hide

He de reconocer un par de cosas, siendo la primera que no puedo hablar mucho de cómo funciona porque aún no ha llegado a mi distribución Linux. La segunda es que es algo que yo llevaba tiempo esperando. No tal y como la han implementado, que va más allá de lo que yo quería, pero sí la posibilidad de ocultar la barra de paneles y que apareciera pasando el cursor por encima. Si no estoy equivocado, Vivaldi 7.9 permitirá configurar qué se oculta, y si elegimos sólo la barra de paneles, hará justamente lo que yo estaba esperando.

Pero no voy a mentir: lo que han implementado es aún mejor. No me permitirá hacer aquello que quería hacer sólo con el panel; podré hacerlo también en la barra de URL, pestañas y panel inferior. Ya tengo ganas de usarlo.

Nueva manera de abrir los enlaces

Vivaldi 7.9 añadirá otra manera para abrir los enlaces. La idea es que no perdamos el hilo de lo que estábamos haciendo. Y es que, cuando abrimos un enlace y no está configurado para que se abra en segundo plano, de una página iremos a otra. Si estamos intentando averiguar algo de un tema en concreto, es posible que terminemos perdiendo el enlace original. Siempre podemos mirar en el historial, pero es más engorroso.

En esta versión se ha añadido la opción «Abrir enlace como pestaña secundaria», lo que abrirá el enlace al lado de la pestaña actual. Una vez elegida esta opción, cualquier enlace adicional en el que se haga clic en la pestaña original se seguirá cargando en la pestaña secundaria.

Mail ahora se abre en su propio compositor

Vivaldi Mail también llega con cambios importantes. Ahora se puede abrir el editor en una ventana separada, lo que nos da mayor control y flexibilidad. Por si esto no fuera suficiente, ahora es más fácil cambiar entre texto enriquecido y texto sin formato, sólo pulsando un botón.

Podéis lee estas novedades en el enlace que hemos proporcionado al principio de este artículo, y la lista completa de cambios en este otro enlace.


GNOME 50 da el salto definitivo a Wayland con más rendimiento y accesibilidad

GNOME 50

La llegada de GNOME 50 “Tokyo” marca un punto de inflexión para uno de los escritorios más extendidos en el ecosistema Linux, donde distribuciones como Ubuntu, Fedora, Debian o openSUSE tienen una presencia destacada tanto en entornos domésticos como profesionales. Esta versión no persigue un cambio radical en el aspecto visual, pero sí apunta alto en lo técnico, con mejoras que se notan en el rendimiento gráfico, la accesibilidad y el uso del escritorio remoto.

En un contexto en el que cada vez más usuarios están abandonando Windows para pasarse a Linux —impulsados en parte por el final del soporte de Windows 10 y el rechazo a migrar a Windows 11—, GNOME 50 llega en un momento clave. Muchas personas se están encontrando con un entorno de escritorio más pulido, más amigable para principiantes y, al mismo tiempo, mejor preparado para juegos, trabajo remoto y uso profesional diario.

GNOME 50: Wayland, VRR y adiós definitivo a X11

Uno de los movimientos más importantes de GNOME 50 es la apuesta prácticamente total por Wayland, dejando atrás el viejo servidor gráfico X11. Según el propio proyecto, el soporte para sesiones sobre X11 se ha eliminado por completo desde las fases alfa, con lo que este lanzamiento se entiende como un escritorio diseñado “de serie” para Wayland y muy vinculado a systemd. Esta decisión permite implementar tecnologías modernas de imagen y sincronización que con X11 eran mucho más problemáticas o directamente inviables.

En el apartado gráfico, la gran protagonista es la tasa de refresco variable (VRR), que deja de ser una opción experimental para integrarse como característica estable dentro de Mutter 50, el compositor de ventanas de GNOME. Gracias a ello, el sistema puede ajustar la frecuencia del monitor a la tasa de fotogramas de las aplicaciones o juegos en tiempo real, dando como resultado animaciones más suaves y reduciendo fenómenos como el tearing o el stuttering. Además, Mutter añade un cursor de baja latencia con VRR activado, algo especialmente relevante para quienes juegan o trabajan con aplicaciones gráficas exigentes.

Junto a la VRR, GNOME 50 refuerza el escalado fraccional en sesiones Wayland, una función que también abandona la etiqueta de “experimental”. Ahora se puede usar de forma predeterminada, sin recurrir a herramientas avanzadas como Dconf o utilidades externas. Este escalado fraccional está pensado sobre todo para pantallas de alta resolución, permitiendo ajustar la interfaz a valores como 125% o 150%, en lugar de saltar bruscamente de 100% a 200%. El resultado es una experiencia más cómoda en portátiles con pantallas 2K o 4K, cada vez más habituales en el mercado.

La gestión del color también sube de nivel. Mutter 50 incorpora la versión 2 del protocolo de gestión de color de Wayland y un pipeline de color más moderno, capaz de compartir pantalla manteniendo los metadatos de HDR. Esto ayuda a evitar que los colores parezcan “lavados” al grabar o retransmitir contenido de alto rango dinámico, algo relevante para creadores de contenido, educadores o profesionales que trabajan con vídeo e imagen desde Linux.

GNOME 50 introduce ajustes específicos para NVIDIA y mejoras notables en juegos

Uno de los frentes donde GNOME 50 ha prestado especial atención es el soporte para tarjetas gráficas NVIDIA, tradicionalmente más delicadas en Linux por las particularidades de su controlador oficial. Mutter incorpora una serie de parches orientados a corregir problemas de stuttering y sincronización de fotogramas, con el objetivo de ofrecer animaciones más estables y una sensación de mayor fluidez tanto en el escritorio como en aplicaciones 3D.

Estas optimizaciones se notan especialmente en el terreno del gaming bajo Linux, algo que interesa cada vez más a usuarios que vienen de Windows. En pruebas comparativas con el mismo controlador estable de NVIDIA, se ha observado que una distribución con GNOME 50 y kernel actualizado ofrece un rendimiento superior frente a versiones anteriores. Este escenario es especialmente visible en la futura Ubuntu 26.04 LTS, que llegará con GNOME 50 como escritorio predeterminado y servirá durante años como referencia para muchos usuarios.

En equipos con tarjetas de gama alta, como una RTX 5090, la diferencia de rendimiento frente a la generación previa con GNOME anterior y kernel más viejo puede situarse aproximadamente entre un 10% y un 20% en determinados juegos, siempre usando el mismo driver gráfico. En tarjetas algo más modestas, como una RTX 5080, la mejora sigue estando presente aunque sea algo más contenida. Estos incrementos no solo se aprecian en juegos, sino también en pruebas sintéticas como benchmarks tipo GravityMark, que reflejan mejor aprovechamiento de la GPU y una menor aparición de tirones.

La combinación de VRR estable, parches específicos para NVIDIA y un stack gráfico más moderno posiciona a GNOME 50 como una opción más sólida para quienes quieren jugar en Linux sin renunciar a una experiencia fluida. Para jugadores que optan por distribuciones como Ubuntu, Fedora Workstation o Arch Linux, esto se traduce en menos problemas de sincronización, transiciones más suaves y mejor respuesta de entrada en títulos exigentes.

Escritorio remoto con aceleración por hardware y enfoque profesional

El escritorio remoto es otro de los puntos fuertes de esta versión. GNOME 50 introduce un nuevo sistema de aceleración por hardware que se apoya en Vulkan y VA-API para codificar y decodificar vídeo de forma más eficiente. Esto implica sesiones remotas más fluidas, con menos latencia y, al mismo tiempo, un consumo energético menor, algo importante en portátiles utilizados en teletrabajo o educación a distancia.

Además de la aceleración, se han incorporado elementos pensados para un uso más serio del escritorio remoto: sincronización explícita para mejorar la estabilidad en GPUs NVIDIA, soporte para pantallas HiDPI, autenticación mediante Kerberos —frecuente en entornos corporativos y educativos— y la posibilidad de gestionar sesiones remotas a través del servicio systemd gnome-headless-session. Todo ello convierte a GNOME 50 en una propuesta más competitiva para administradores de sistemas, empresas y centros educativos que dependen del acceso remoto a escritorios Linux.

Esta combinación de menor retardo, mejor calidad de imagen y herramientas de autenticación integradas encaja bien con el auge del teletrabajo, donde muchas organizaciones se apoyan en escritorios Linux para tareas de desarrollo, administración de sistemas o formación técnica.

Control parental avanzado y mejoras en el uso familiar en GNOME 50

GNOME 50 también da un paso importante en el ámbito del control parental, un apartado que suele ser clave para familias que comparten un mismo ordenador en casa. La nueva versión permite configurar límites de tiempo de uso, establecer horarios de descanso e incluso bloquear automáticamente la sesión cuando se alcanza el máximo establecido. Estas funciones facilitan que padres y madres gestionen el tiempo de pantalla de menores de forma menos manual y más transparente.

El sistema no se limita a bloquear aplicaciones sueltas, sino que se integra con el resto del escritorio, haciéndolo más adecuado para hogares que empiezan a adoptar Linux como alternativa a Windows. Para el perfil de usuario que en España está migrando desde Windows 10 y quiere un entorno más controlado para los hijos, esta capa de control parental en GNOME 50 puede ser un argumento de peso frente a otros escritorios que aún no ofrecen algo tan integrado.

Archivos (Files) más rápido, estable y cómodo

El gestor de ficheros, conocido actualmente como Archivos (Files) y antes como Nautilus, recibe una serie de ajustes pensados para mejorar tanto el rendimiento como la comodidad en el día a día. Internamente, se ha trabajado en una carga más rápida de iconos y miniaturas, un uso de memoria más contenido y una adopción más amplia del lenguaje de marcado Blueprint para definir la interfaz.

Otra novedad técnica relevante es el uso de la biblioteca Glycin para decodificación de imágenes en un entorno aislado y de alto rendimiento. Esta separación ayuda a que fallos en el proceso de decodificación no afecten a todo el gestor de archivos, algo importante cuando se manejan grandes cantidades de imágenes o formatos poco habituales. Para quienes trabajan con fotografía o diseño en Linux, esta mejora se traduce en una aplicación más estable y menos propensa a bloqueos.

En lo que respecta a la experiencia de uso, el renombrado por lotes se ha hecho más intuitivo, mostrando resaltados visuales del texto que se va a reemplazar y ofreciendo un flujo más claro para gestionar grandes volúmenes de ficheros. También se introduce un nuevo cuadro de diálogo para la gestión de subtítulos en la vista de cuadrícula y se acortan las descripciones de operaciones en la barra lateral, de modo que la interfaz quede más limpia y fácil de leer.

Configuración del sistema más clara y ordenada

La aplicación de Configuración también recibe una serie de ajustes que, aunque no resulten muy espectaculares a primera vista, ayudan a que el sistema sea más sencillo de manejar. En el apartado de “Fecha y hora” se añade la posibilidad de elegir el primer día de la semana, detalle pequeño pero útil para adaptarse a costumbres locales, donde muchas personas prefieren arrancar el calendario en lunes.

El panel de sonido ahora diferencia de forma más clara entre dispositivos de salida (altavoces, auriculares, barras de sonido) y de entrada (micrófonos) para reducir confusiones. Esta separación resulta práctica para videollamadas, creación de contenido o clases en línea, donde cambiar rápidamente entre un micro USB y uno integrado puede evitar más de un quebradero de cabeza.

Por su parte, la sección de gestión del color recibe múltiples correcciones, sobre todo en lo referente a la calibración de pantalla. Se actualizan también los detalles relacionados con el módem y la conectividad móvil, mejorando la información y el control sobre conexiones de datos, algo que usuarios de portátiles con SIM integrada valorarán en desplazamientos.

Accesibilidad reforzada: Orca y movimiento reducido

La accesibilidad ha sido tradicionalmente uno de los puntos delicados de Wayland, y GNOME 50 intenta avanzar de forma notable en este terreno. El lector de pantallas Orca recibe una renovación importante, empezando por una nueva ventana de preferencias con un diseño más coherente con el resto del escritorio y una configuración de carácter global. Esto implica que muchos ajustes dejan de hacerse aplicación por aplicación, simplificando la vida a usuarios con discapacidad visual.

Entre las novedades de Orca destaca el cambio automático de idioma en función del contenido, un modo de exploración que se amplía a todo el documento, un “modo fijo” afinado que se activa por defecto en aplicaciones basadas en Electron y una mejor compatibilidad con Braille. Se introduce también la revisión del ratón en sesiones Wayland, facilitando seguir lo que ocurre en pantalla a través del lector.

GNOME 50 incorpora además una opción de movimiento reducido dentro de la Configuración, pensada para personas que puedan experimentar mareos o molestias con demasiadas animaciones y efectos visuales. Al activar esta opción, el sistema limita transiciones y movimientos, dejando una experiencia visual más estática y amigable para quienes necesitan minimizar estímulos. Todo este conjunto de cambios refuerza la posición de GNOME como escritorio accesible para un amplio abanico de usuarios.

Nuevas aplicaciones y ampliación del ecosistema GNOME

En el apartado de aplicaciones, GNOME 50 no se queda corto. Entre las incorporaciones que llaman la atención encontramos Gradia, una herramienta para editar y anotar capturas de pantalla antes de compartirlas. Permite añadir fondos degradados, sombras paralelas y relleno personalizado, dando un aspecto más pulido y profesional a lo que, de otro modo, serían simples recortes de pantalla. Para quienes realizan documentación, guías o contenido formativo, esta app puede agilizar el trabajo sin recurrir a soluciones externas.

Otra utilidad destacada es Constrict, orientada a la compresión de vídeo con un enfoque práctico: en lugar de obligar al usuario a probar diferentes tasas de bits y resoluciones, pide un tamaño final objetivo y calcula automáticamente los parámetros óptimos de resolución, fotogramas por segundo y calidad de audio. Esta aproximación es especialmente interesante para quienes necesitan enviar vídeos por correo, plataformas con límite de tamaño o servicios internos de empresa.

Al margen de estas aplicaciones concretas, GNOME 50 amplía y actualiza el conjunto de herramientas incluidas en el núcleo del escritorio y en su ecosistema de aplicaciones (GNOME Circle). Se mencionan mejoras en el visor de documentos —con un sistema de anotaciones más completo para añadir texto, resaltar o dibujar—, un calendario más funcional con mejor gestión de asistentes y exportación de eventos en formato ICS, y otros pequeños retoques que, sin ser llamativos por sí solos, suman valor al conjunto.

GNOME 50 en las principales distribuciones

Como suele suceder con cada lanzamiento del proyecto, GNOME 50 no llega al mismo tiempo a todas las distribuciones. Es previsible que Fedora Workstation, Arch Linux, openSUSE Tumbleweed y otras distros de actualización continua lo integren con relativa rapidez. En muchos casos, bastará con actualizar el sistema para disponer de la nueva versión del escritorio.

En el caso de Ubuntu, la integración más relevante será en Ubuntu 26.04 LTS, cuya publicación está prevista para finales de abril y que se convertirá en la referencia a largo plazo para una gran parte de usuarios. Esta versión llegará con GNOME 50 como entorno predeterminado —adaptado con los retoques de Canonical— y con un kernel de Linux más moderno, lo que, como se ha comprobado en distintas pruebas, se traduce en un comportamiento mejorado frente a versiones previas como Ubuntu 25.10, especialmente en juegos y tareas gráficas.

Distribuciones como Debian, muy extendida en servidores y en algunas administraciones públicas, suelen ir más despacio en la adopción de grandes cambios, pero GNOME 50 irá abriéndose paso según se vayan consolidando los ciclos de publicación. En todo caso, usuarios con más experiencia pueden recurrir a imágenes de prueba como GNOME OS, instalar distros que ya lo incluyan o usar repositorios de desarrollo en rolling releases como openSUSE Tumbleweed o Arch Linux, siempre asumiendo el riesgo de inestabilidad que conlleva adelantarse a la rama estable.

Para quienes no quieran complicarse, lo más sensato sigue siendo esperar a que la distribución favorita ofrezca GNOME 50 como actualización estable. De este modo se garantiza una mejor compatibilidad con el resto del software empaquetado y se minimizan errores, especialmente en equipos de producción o en entornos donde no conviene jugar con versiones todavía en pruebas.

En conjunto, GNOME 50 “Tokyo” refuerza la sensación de que el escritorio de referencia en distros como Ubuntu o Fedora ha dado un paso más hacia un entorno moderno, centrado en Wayland, con mejor rendimiento gráfico, escritorio remoto más sólido, accesibilidad reforzada y un ecosistema de aplicaciones algo más completo. Todo ello llega en un momento en el que muchos usuarios están valorando seriamente dar el salto a Linux, y se encuentran con un escritorio que, sin estridencias visuales, resulta más maduro para uso diario, juegos, teletrabajo y tareas profesionales.


GNOME 50 Tokyo potencia Wayland, juegos y accesibilidad en Linux

GNOME 50

El lanzamiento de GNOME 50 “Tokyo” supone un punto de inflexión para uno de los escritorios más extendidos en el ecosistema Linux, donde distribuciones como Ubuntu, Fedora, Debian u openSUSE son habituales tanto en casa como en la oficina. Esta versión no busca un cambio radical de apariencia, sino apuntalar el escritorio con mejoras técnicas que se notan en el uso diario, sobre todo en rendimiento gráfico, accesibilidad y trabajo remoto.

En un contexto en el que cada vez más usuarios dejan atrás Windows 10, muchos reacios a dar el salto a Windows 11, GNOME 50 llega en un momento delicado pero interesante. Quienes prueban Linux por primera vez se encuentran con un entorno más pulido, más amigable para quien empieza y, a la vez, más preparado para juegos, teletrabajo y entornos profesionales donde la estabilidad y el rendimiento son clave.

Wayland como base, VRR estable y adiós a X11 en GNOME 50

Uno de los movimientos más relevantes de GNOME 50 es su apuesta casi total por Wayland como servidor gráfico, dejando el soporte para sesiones X11 fuera del foco del desarrollo. Desde fases tempranas del ciclo se ha ido retirando X11, de modo que esta versión se perfila como un escritorio diseñado de origen para Wayland y fuertemente integrado con systemd, algo que encaja con la dirección que siguen muchas distribuciones modernas.

En el plano gráfico, la gran protagonista es la tasa de refresco variable (VRR), que abandona definitivamente el estado experimental y pasa a ser una capacidad estable en Mutter 50, el compositor de ventanas que acompaña al escritorio. Gracias a la VRR, el sistema ajusta la frecuencia de actualización del monitor a los fotogramas que generan juegos y aplicaciones, lo que ayuda a reducir cortes de imagen, tirones y sensación de falta de fluidez. Además, se ha incluido un cursor de baja latencia compatible con VRR, algo que se nota especialmente en videojuegos y en software que exige gran precisión con el puntero.

Junto a la VRR, GNOME 50 consolida el escalado fraccional en sesiones Wayland, pensado para pantallas de alta densidad de píxeles. Esta función también deja de considerarse experimental y pasa a estar disponible de forma predeterminada, sin necesidad de recurrir a herramientas como el editor de Dconf o utilidades de terceros. El usuario puede seleccionar factores como 125% o 150% en lugar de saltar de golpe del 100% al 200%, algo especialmente útil en portátiles 2K o 4K, muy habituales ya en el mercado.

La gestión del color también recibe un impulso importante. Mutter 50 implementa la versión 2 del protocolo de gestión de color de Wayland y un pipeline de color moderno, capaz de compartir la pantalla sin perder los metadatos HDR. Esta mejora evita que la imagen parezca deslavada al grabar o retransmitir contenido de alto rango dinámico, algo relevante para creadores de contenido, docentes y profesionales que trabajan con vídeo o fotografía desde Linux.

Ajustes específicos para NVIDIA y salto de rendimiento en juegos

El soporte para tarjetas gráficas NVIDIA ha sido históricamente una de las asignaturas más delicadas en Linux, y GNOME 50 intenta suavizar ese frente. Mutter incorpora múltiples parches dirigidos a corregir problemas de stuttering y sincronización de fotogramas, con el objetivo de lograr animaciones más uniformes, menos microcortes y una sensación general de fluidez mayor tanto en el escritorio como en las aplicaciones 3D.

Estos cambios se dejan notar especialmente en el ámbito del gaming bajo Linux, un terreno en el que las distribuciones quieren competir de tú a tú con Windows. En pruebas comparativas utilizando el mismo controlador estable de NVIDIA, se ha observado que una distribución equipada con GNOME 50 y un kernel reciente logra mejor rendimiento en juegos frente a versiones anteriores del mismo sistema. Las diferencias se perciben con claridad en la próxima Ubuntu 26.04 LTS, que adoptará GNOME 50 como entorno por defecto y que está llamada a convertirse en referencia para muchos usuarios domésticos y profesionales.

En configuraciones con GPUs de gama alta, como una RTX 5090, se han registrado incrementos de entre un 10% y un 20% en tasas de fotogramas en títulos probados respecto a Ubuntu 25.10 con GNOME previo y kernel más antiguo, siempre usando el mismo controlador gráfico. Con modelos algo más modestos, como una RTX 5080, la mejora sigue existiendo, aunque con un margen algo menor dependiendo del juego. Este comportamiento más ágil se aprecia también en herramientas de prueba sintéticas y benchmarks del estilo de GravityMark, que sirven para medir el aprovechamiento de la GPU y la estabilidad general.

La combinación de VRR maduro, parches orientados a NVIDIA y un stack gráfico actualizado refuerza la posición de GNOME 50 como escritorio apto para jugar en Linux sin renunciar a fluidez. Estas mejoras se traducen en menos tirones, transiciones más limpias y una mejor respuesta del sistema en títulos exigentes, incluso usando drivers propietarios.

Escritorio remoto acelerado por hardware y uso profesional

El escritorio remoto se ha convertido en una pieza central para teletrabajo, educación y administración de sistemas, y GNOME 50 dedica una parte importante de las novedades a este ámbito. La nueva versión introduce un soporte de aceleración por hardware basado en Vulkan y VA-API que permite codificar y decodificar la señal de vídeo de forma más eficiente, con impacto directo en la fluidez de las sesiones remotas y en la reducción de la latencia.

Este enfoque más moderno conlleva menor consumo energético y menor lag, algo especialmente sensible en portátiles y equipos que funcionan durante muchas horas fuera de la oficina. A ello se suman mejoras como la sincronización explícita para estabilizar la experiencia en GPUs NVIDIA, el soporte para pantallas HiDPI en sesiones remotas, la posibilidad de autenticación mediante Kerberos —muy extendida en redes corporativas y universitarias— y la gestión de sesiones sin interfaz directa a través del servicio systemd gnome-headless-session. Este conjunto de cambios hace que GNOME 50 resulte más competitivo en entornos profesionales donde la administración remota de escritorios Linux es el pan de cada día.

En empresas, centros educativos y administraciones públicas que emplean Linux para desarrollo, formación técnica o gestión interna, contar con un escritorio remoto más solvente y con soporte de hardware actual supone un avance significativo, reduciendo la necesidad de soluciones de terceros y facilitando la integración con la infraestructura existente.

Control parental más completo para equipos compartidos

Más allá del ámbito profesional, GNOME 50 incorpora mejoras pensadas para el hogar, entre ellas un sistema de control parental avanzado integrado en el propio escritorio. Este nuevo conjunto de opciones permite establecer límites de tiempo de uso de la pantalla, definir franjas horarias de descanso y bloquear el acceso cuando se alcanza el tiempo máximo configurado, algo muy útil en ordenadores compartidos por toda la familia.

En lugar de depender de herramientas ajenas poco integradas, el control parental de GNOME 50 trabaja junto con el resto de componentes del escritorio, ofreciendo un enfoque más ordenado y sencillo de administrar. Para familias que están migrando desde Windows y buscan controlar mejor el uso que hacen los menores del PC, este tipo de funciones pueden inclinar la balanza a favor de un escritorio Linux que resulte cómodo y configurable sin grandes complicaciones.

Archivos (Files) gana velocidad, estabilidad y mejor usabilidad

El gestor de ficheros de GNOME, conocido como Archivos (Files), también da un salto notable, aunque quizá menos vistoso que las novedades gráficas. En el interior de la aplicación se han introducido cambios para conseguir una carga más rápida de iconos y miniaturas, reducir el consumo de memoria y aumentar el uso de Blueprint como lenguaje de marcado para la definición de la interfaz, lo que facilita su mantenimiento y evolución futura.

Otro punto relevante es la adopción de la biblioteca Glycin para la decodificación de imágenes en un entorno aislado. Este enfoque permite que la reproducción de imágenes se ejecute en un espacio separado y de alto rendimiento, evitando que errores o bloqueos al abrir ciertos formatos acaben afectando al resto del gestor de archivos. Para quienes manejan grandes colecciones de fotos, materiales gráficos o bibliotecas multimedia, esta separación aporta una mayor sensación de solidez.

En el apartado de usabilidad, el renombrado masivo de ficheros se vuelve más intuitivo, con resaltados visuales del texto a reemplazar que ayudan a no cometer errores al tratar con grandes lotes de archivos. Se añade un nuevo cuadro de diálogo para gestionar subtítulos en la vista de cuadrícula y se han acortado las descripciones de las operaciones en la barra lateral, de modo que la interfaz resulte visualmente más limpia y fácil de leer, algo que se nota en monitores pequeños o cuando se trabaja con varias ventanas a la vez.

Aplicación de Configuración más clara y mejor adaptada

La herramienta de Configuración del sistema de GNOME 50 estrena una serie de ajustes que, aunque discretos, ayudan a que el entorno sea más sencillo de entender para quien llega desde otros sistemas. En el apartado de “Fecha y hora” se incorpora la opción de elegir cuál es el primer día de la semana, un detalle que parece menor pero que facilita adaptar el calendario a las costumbres locales, algo especialmente útil en países donde se suele empezar la semana laboral en lunes.

El panel de sonido distingue de forma clara entre dispositivos de entrada y salida, identificando mejor auriculares, altavoces, barras de sonido y micrófonos. Este cambio reduce confusiones típicas en videollamadas, retransmisiones o clases en línea, cuando es necesario cambiar deprisa de un micro integrado a uno USB o a una interfaz de audio externa. También se han actualizado los datos relacionados con el módem y la conectividad móvil, lo que ayuda a gestionar mejor conexiones de datos en portátiles con SIM, algo cada vez más habitual en entornos de trabajo flexible.

Por último, el área de gestión del color recibe varias correcciones, sobre todo en lo que respecta a la calibración de pantallas. Este tipo de ajustes interesan de manera particular a profesionales del diseño y la imagen que trabajan desde Linux y necesitan una representación del color fiable, algo que hasta hace pocos años solía ser un punto débil frente a otras plataformas.

Accesibilidad reforzada: Orca evoluciona y llega el movimiento reducido

La accesibilidad, y en concreto su integración con Wayland, era uno de los puntos donde GNOME tenía margen de mejora, y la versión 50 intenta avanzar de forma clara en este ámbito. El lector de pantallas Orca se beneficia de una renovación profunda, empezando por una ventana de preferencias con diseño más coherente con el resto del escritorio y una configuración global que evita tener que repetir ajustes aplicación por aplicación, algo que históricamente podía resultar engorroso.

Entre las novedades, Orca incorpora cambio automático de idioma según el contenido, un modo de exploración extendido a todos los elementos de los documentos, un “modo fijo” afinado que se activa automáticamente en aplicaciones basadas en Electron y mejoras de compatibilidad con dispositivos Braille. Además, se introduce la revisión del ratón en sesiones Wayland, permitiendo seguir de forma más precisa lo que ocurre en pantalla mediante el lector de pantalla.

GNOME 50 añade también una opción de movimiento reducido en la Configuración, orientada a usuarios que puedan experimentar mareos o molestias ante animaciones intensas y efectos visuales continuos. Al habilitar esta opción, el sistema reduce o elimina muchas de esas transiciones, generando una experiencia visual más tranquila. En conjunto, estas novedades hacen que el escritorio resulte más accesible para personas con discapacidad visual o sensibilidad a ciertos estímulos, ampliando el perfil de usuarios que pueden utilizar Linux a diario sin recurrir a soluciones externas.

Nuevas apps y ecosistema GNOME más completo

GNOME 50 no se limita al núcleo del escritorio, sino que también amplía su ecosistema de aplicaciones, tanto en la base como en GNOME Circle. Entre las nuevas incorporaciones destaca Gradia, una aplicación dedicada a refinar y anotar capturas de pantalla antes de compartirlas. Permite aplicar fondos degradados, añadir sombras paralelas y configurar márgenes personalizados, lo que ayuda a dar un aspecto más cuidado a las capturas, algo muy útil en documentación técnica, manuales internos o contenidos formativos.

Otra novedad reseñable es Constrict, una aplicación de compresión de vídeo enfocada a cumplir límites de tamaño concretos sin necesidad de que el usuario tenga que ajustar parámetros técnicos a mano. En lugar de jugar con tasas de bits, resolución y calidad de audio a base de prueba y error, basta con indicar el tamaño final objetivo y dejar que la aplicación calcule la configuración adecuada de resolución, fotogramas por segundo y compresión. Este enfoque resulta especialmente práctico para quienes necesitan enviar vídeos por correo, subirlos a plataformas con tope de tamaño o compartir material audiovisual en redes internas de empresa.

Además de estas nuevas aplicaciones, GNOME 50 trae mejoras a componentes ya conocidos. El visor de documentos estrena un sistema de anotaciones más completo, que facilita resaltar texto, añadir comentarios o trazar líneas con mayor precisión, algo muy útil al trabajar con PDFs en entornos académicos o de oficina. El calendario incorpora una vista de asistentes más clara, la posibilidad de exportar eventos en formato ICS y una creación de citas más ágil, pequeños cambios que mejoran el uso en el día a día sin necesidad de recurrir a aplicaciones externas.

Disponibilidad de GNOME 50 en distribuciones y cómo probarlo

Como suele ocurrir con los grandes lanzamientos, GNOME 50 no aparece al mismo tiempo en todas las distribuciones. El proyecto publica el escritorio y son los responsables de cada distro quienes deciden cuándo y cómo integrarlo. En entornos rolling release como Arch Linux u openSUSE Tumbleweed se espera que la adopción sea relativamente rápida, llegando mediante una actualización ordinaria del sistema. Fedora Workstation también suele situarse entre las primeras en adoptar la nueva versión del escritorio.

En el caso de Ubuntu, la llegada más significativa se producirá con Ubuntu 26.04 LTS, cuyo lanzamiento está previsto para finales de abril y que integrará GNOME 50 como escritorio por defecto, con los ajustes y personalizaciones habituales de Canonical. Esta versión LTS, muy utilizada por su soporte prolongado, ofrecerá un stack gráfico más moderno y un rendimiento superior en juegos y aplicaciones gráficas frente a versiones previas como Ubuntu 25.10, tal y como han mostrado ya varias pruebas con hardware NVIDIA.

Para quienes quieran probar GNOME 50 sin esperar a la versión estable de su distribución, existen varias posibilidades. Una opción es instalar una distro que ya lo incluya, usando una imagen ISO reciente de Fedora, de una versión en desarrollo de Ubuntu o de una rolling release que lo haya incorporado. Otra alternativa es montar una máquina virtual con VirtualBox o VMware e instalar en ella una distribución con GNOME 50, de manera que se testeen todas las novedades sin tocar el sistema principal.

El propio proyecto ofrece además GNOME OS, una imagen pensada para probar las últimas versiones del escritorio en un entorno controlado, aunque no se recomiende para uso diario. Por último, los usuarios avanzados pueden recurrir a repositorios de desarrollo o ramas inestables en distros como Arch Linux u openSUSE Tumbleweed, asumiendo el riesgo de posibles fallos. Para la mayoría, no obstante, la opción más sensata sigue siendo esperar a que GNOME 50 llegue como actualización estable a su distribución favorita, garantizando así mayor compatibilidad y menos quebraderos de cabeza.

Con este conjunto de cambios, GNOME 50 “Tokyo” consolida la imagen de un escritorio que apuesta fuerte por Wayland, refuerza el rendimiento gráfico, mejora de manera notable el escritorio remoto, amplía las opciones de accesibilidad y enriquece su ecosistema de aplicaciones. Todo ello se produce en un momento en el que muchas personas se plantean dar el salto a Linux, y se encuentran con un entorno que, sin grandes estridencias visuales, se muestra más maduro para uso cotidiano, juegos, teletrabajo y tareas profesionales de todo tipo.


Blender 5.1 llega mejorando notablemente el rendimiento de Cycles, Eevee y el sistema de animación.

Blender 5.1

La llegada de Blender 5.1 marca otro paso importante para uno de los programas de creación 3D de código abierto más utilizados, tanto en estudios pequeños como en producción independiente. No es una revolución completa, pero sí una actualización muy amplia que toca casi todos los apartados del software.

Esta versión se centra sobre todo en mejorar el rendimiento, reforzar la estabilidad y ampliar las posibilidades técnicas en áreas clave como el render, la animación, la edición de vídeo, la composición y la integración en pipelines profesionales. Todo ello sin abandonar la filosofía de software libre y manteniendo la descarga gratuita para Windows, macOS y Linux.

Novedades destacadas en render: Cycles y Eevee más rápidos

En el terreno del render, Blender 5.1 se centra en que las escenas se calculen más rápido y con mejor aprovechamiento del hardware. Cycles, el motor de producción, obtiene incrementos de velocidad tanto en CPU como en GPU, mientras que Eevee acelera la compilación de materiales y reduce el uso de memoria de texturas.

En Cycles, las pruebas realizadas muestran que el render por CPU en Windows es ahora entre un 5% y un 20% más rápido, según la escena y el hardware empleado. La GPU también gana terreno, con incrementos de alrededor de un 5-10% en distintas configuraciones y sistemas operativos, lo que se nota especialmente en escenas complejas o animaciones de larga duración.

El cambio más llamativo para quienes usan gráficas de AMD es que, con Blender 5.1, el trazado de rayos por hardware mediante HIP-RT pasa a estar activado por defecto. Esto permite aprovechar de manera más directa las capacidades de ray tracing de estas tarjetas en Cycles, sin tener que tocar configuraciones avanzadas.

En Eevee, el motor en tiempo real, se ha revisado el proceso de compilación de shaders. Al preprocesar las fuentes, los materiales se compilan considerablemente más rápido: en la escena de prueba Barbershop se observa una mejora de entre el 25% y el 50%, dependiendo de si se utiliza el backend OpenGL, Vulkan o Metal y de si es una compilación «en frío» (sin caché previa).

Además, Eevee reduce ahora el consumo de memoria de texturas gracias a un sistema que permite solapar framebuffers y texturas de render en distintos momentos del fotograma. Según las notas técnicas, esto se traduce en un ahorro de alrededor del 30-40% de memoria gráfica, algo que puede marcar la diferencia en proyectos pesados.

Otra mejora práctica en Eevee es la incorporación de nuevos controles de intensidad de rutas de luz, que facilitan ajustar el equilibrio entre iluminación directa e indirecta sin necesidad de retocar la configuración de muestreo, lo que agiliza el ajuste fino del look final.

Raycast: nuevo nodo para efectos no fotorrealistas y proyección

Entre las funciones nuevas, uno de los protagonistas de Blender 5.1 es el nodo Raycast, disponible en Eevee. Este nodo lanza rayos adicionales dentro de la escena y devuelve información de la primera superficie que encuentra, lo que abre la puerta a una amplia variedad de efectos de sombreado creativos.

Al conocer con precisión el punto más cercano donde impacta el rayo o la distancia recorrida, se pueden montar configuraciones para sombras toon, efectos tipo rayos X o sistemas de proyección de calcas (decals) sobre geometrías complejas. De hecho, durante el desarrollo se popularizó un montaje de proyección de decals realizado por artistas de animación 3D, que demostraba cómo este nodo permite técnicas que antes requerían soluciones mucho más rebuscadas.

El propio equipo de Blender ha puesto a disposición de la comunidad varios archivos de ejemplo descargables, donde se pueden estudiar en detalle configuraciones de Raycast para sombreado tipo cómic, efectos de rayos X o proyección de gráficos sobre superficies. Eso sí, se advierte de que este nodo puede resultar computacionalmente costoso, por lo que recomiendan hornear ciertos resultados cuando se utilice de forma intensiva.

Compositor: nuevo nodo Mask to SDF y vínculos con el editor de vídeo

El sistema de composición integrado de Blender lleva varias versiones recibiendo mejoras y Blender 5.1 continúa esa tendencia con nuevas herramientas y optimizaciones de rendimiento. Una de las incorporaciones más interesantes es el nodo Mask to SDF, que transforma cualquier máscara en un campo de distancia firmado (Signed Distance Field).

Este tipo de representación permite calcular para cada píxel la distancia al borde de la máscara, lo que hace muy sencillo construir efectos de bordes suaves, brillos, erosión o dilatación de formas y montajes basados en la distancia, como desenfoques procedurales que se expanden desde un contorno concreto.

El Compositor también incorpora compatibilidad con nodos utilitarios ya presentes en otros contextos, como Radial Tiling, Boolean, Integer, Vector e Index Switch, ampliando así las posibilidades a la hora de construir árboles de nodos complejos para postproducción.

En cuanto al rendimiento, varios de los nodos más usados han sido optimizados de manera significativa. Operaciones como Blur, Directional Blur, Vector Blur, Glare, Lens Distortion y Anti-Aliasing se ejecutan ahora entre 1,2 y 2 veces más rápido, lo que puede marcar una gran diferencia al componer secuencias largas o trabajos con muchas capas.

Una novedad especialmente relevante para quienes montan vídeo dentro de Blender es la llegada del nodo Sequencer Strip Info. Este nodo lee atributos de las tiras en el Video Sequence Editor (VSE), como tiempos de inicio y fin, lo que permite sincronizar con precisión efectos de composición con los cortes y transiciones de la línea de tiempo de vídeo.

Video Sequence Editor: audio mejorado y flujo con el Compositor

El Video Sequence Editor, el sistema interno para corte y edición de vídeo, también recibe varios ajustes que apuntan a un flujo de trabajo más flexible, sobre todo en el tratamiento del audio. A partir de esta versión, es posible modificar el tono de las pistas de sonido directamente desde el VSE.

El cambio de tono se puede controlar mediante semitonos o factores de escala, por ejemplo, indicando que una pista suene un 30% más grave. Además, se suma la posibilidad de aplicar efectos de eco a las tiras de audio, lo que amplía las opciones creativas básicas sin necesidad de pasar por un editor externo.

Otra mejora útil son las metastrips con corrección de volumen global. Cuando se agrupan varias tiras, como dos pistas de audio, ahora se puede ajustar el volumen conjunto de toda la metastrip, facilitando el control del nivel general sin tener que editar cada pista por separado.

La integración entre VSE y Compositor se refuerza también desde el propio flujo de trabajo: no solo se pueden sincronizar efectos mediante el nodo Sequencer Strip Info, sino que resulta posible crear directamente la configuración del VSE desde el Compositor, acercando ambos entornos y simplificando la organización de proyectos donde montaje y postproducción se realizan dentro de Blender.

Animación: rigs complejos mucho más ágiles

En animación, Blender 5.1 combina nuevas herramientas con una mejora muy notable en el rendimiento de evaluación de personajes. Una incorporación destacada es el modificador de suavizado gaussiano en el Editor de Curvas (Graph Editor), que permite suavizar F-curves de manera no destructiva.

Esta herramienta está pensada, entre otras cosas, para reducir el ruido en datos de captura de movimiento sin perder la información original, ya que el suavizado se aplica como un modificador y las claves de animación permanecen intactas. Se advierte, eso sí, que puede ser exigente en recursos, por lo que conviene no aplicarlo de forma indiscriminada a demasiadas curvas a la vez.

En cuanto a rendimiento, la evaluación de Actions y Shape Keys se ha optimizado de forma considerable. En pruebas con un procesador AMD Ryzen de 12 núcleos y 24 hilos, evaluando un armature con alrededor de 2.600 huesos durante 1.000 fotogramas, las tasas de fotogramas se multiplican por un factor de entre 2,25 y 2,3, dependiendo de la cantidad de hilos aprovechados.

Para las Shape Keys, que se usan para morph targets y expresiones faciales, las mejoras son aún más llamativas: en una malla de aproximadamente un millón de vértices, las tasas de fotogramas pueden ser de 2,3 a 4 veces superiores. Esto se traduce en una manipulación mucho más fluida de personajes complejos, algo especialmente apreciable en producciones de animación y videojuegos.

Geometría y volúmenes: nuevos nodos para texto y rejillas voxel

El sistema de Geometry Nodes, que permite crear herramientas y efectos procedurales, recibe varias incorporaciones orientadas tanto al texto como al trabajo con volúmenes. El nodo Strings to Curves se amplía con numerosos sockets de entrada adicionales, lo que permite animar prácticamente cualquier parámetro relacionado con el texto.

A partir de ahora es más sencillo construir montajes en los que se controlen la separación de caracteres, alineaciones, cajas de texto y otros atributos de forma procedimental. Esto facilita la creación de efectos tipográficos animados sin necesidad de recurrir a herramientas externas, algo que puede interesar especialmente a quienes producen piezas de motion graphics.

En el ámbito de los volúmenes, la comunidad ha contribuido una serie de nodos nuevos diseñados para manipular rejillas de vóxeles, muy útiles en efectos volumétricos. El nodo Clip Grid permite desactivar todos los vóxeles fuera de un cubo definido; por su parte, Cube Grid Topology genera una rejilla cúbica con todos los vóxeles activos.

Otros nodos, como Grid Mean y Grid Median, calculan la media y la mediana de los valores de todos los vóxeles de una rejilla, respectivamente, lo que ayuda a analizar o normalizar datos volumétricos. Los nodos Grid Dilate y Grid Erode permiten expandir o contraer las zonas activas en la rejilla; combinando una dilatación seguida de una erosión se pueden cerrar agujeros en el volumen con relativa facilidad.

Finalmente, el nodo Grid to Points crea un punto en cada vóxel activo de la rejilla, puntos que se pueden usar para instanciar objetos. Por ejemplo, se puede representar cada vóxel mediante un cubo, algo muy práctico para depurar y visualizar el estado interno de las rejillas volumétricas durante el desarrollo de configuraciones complejas.

Interfaz, nodos y mejoras de flujo de trabajo

La interfaz de Blender y los sistemas basados en nodos también reciben su ración de mejoras. Según los desarrolladores, en la UI se han aplicado cerca de un centenar de correcciones y pequeños ajustes, entre los que destaca la posibilidad de buscar controles por nombre dentro del panel de Preferencias, agilizando el acceso a opciones concretas.

Otra mejora de usabilidad es la opción de redimensionar las vistas en cuadrícula (quad view) arrastrando el punto central, algo que hace más cómodo adaptar el espacio de trabajo a las necesidades de cada tarea sin recurrir a menús adicionales.

En la parte de nodos, una novedad muy práctica es que ahora se pueden copiar y pegar árboles de nodos entre distintas instancias de Blender utilizando el portapapeles del sistema. Esto incluye la posibilidad de transferir configuraciones entre diferentes tipos de editores de nodos, como el Shader Editor y el Compositor, lo que facilita reutilizar configuraciones y librerías de efectos.

Además, se introduce un nuevo nodo Bone Info en Geometry Nodes, que permite acceder a la posición de los huesos desde flujos de trabajo procedurales. Aunque se trata todavía de un paso inicial, esta posibilidad abre la puerta a exploraciones en rigging procedural y sistemas de animación más avanzados basados en nodos.

Grease Pencil, escultura y pintura

El conjunto de herramientas de Grease Pencil, pensado para animación 2D dentro de un entorno 3D, también evoluciona en Blender 5.1 con cambios de flujo de trabajo relevantes. Entre ellos, destaca la opción de controlar los rellenos directamente, sin depender únicamente de los materiales asociados a los trazos.

Además, se añade la posibilidad de crear agujeros en las áreas de relleno, ya sea mediante nuevos operadores que realizan operaciones de tipo booleano sobre las formas, o aprovechando el importador de SVG. Esto amplía de forma notable la flexibilidad a la hora de diseñar personajes y fondos con áreas vacías o recortes complejos.

En las herramientas de Escultura y Pintura, la mayor parte de los cambios se centra en correcciones y estabilidad, pero se incluye un nuevo pincel Blur. Este pincel está pensado específicamente para suavizar colores sobre la superficie al trabajar en modo Sculpt, evitando tener que recurrir a los pinceles de arrastre de color (Smear) o de pintura tradicionales para lograr un efecto de difuminado.

Video, VR y Vulkan: rendimiento y experiencia inmersiva

Más allá de la edición de vídeo clásica, Blender sigue reforzando sus capacidades en realidad virtual. En la versión 5.1, el sistema de teletransporte dentro de escenas VR se ha reescrito por completo para aproximarse más a las convenciones de los juegos actuales y reducir las molestias asociadas al movimiento continuo, como los mareos.

La nueva implementación indica de manera clara el destino del teletransporte, e introduce un widget que evita saltar sin querer al interior de paredes o zonas no deseadas, mostrando un aviso en rojo cuando la posición elegida no es adecuada. Además, se mantiene y se amplía la compatibilidad con OpenXR, incluyendo soporte en macOS, lo que resulta relevante para estudios que trabajan con distintos sistemas operativos.

En el plano gráfico, Blender avanza en su transición desde OpenGL hacia Vulkan como backend principal. Hasta ahora, una de las áreas donde Vulkan iba por detrás era la previsualización de escenas en VR, donde el rendimiento resultaba inferior. Con Blender 5.1, ese último cuello de botella se ha eliminado y Vulkan se sitúa al menos al nivel de OpenGL en todos los escenarios evaluados.

Este avance, sumado a tiempos de carga más rápidos y un mejor aprovechamiento del hardware moderno, acerca el momento en que Vulkan se convierta en la opción por defecto en futuras versiones. Además, el soporte de Vulkan se refuerza con características como un nuevo «pool» de texturas específico y una mayor estabilidad general.

Integración en pipeline, formatos y requisitos del sistema

Para su integración en entornos profesionales, Blender 5.1 se alinea con los estándares del sector actualizando componentes clave. El programa adopta Python 3.13 y OCIO 2.5, lo que lo acerca a las especificaciones de la VFX Reference Platform de 2026, habitual en muchos estudios de efectos visuales y animación.

En el apartado de entrada y salida de datos, se introduce soporte de exportación AVIF y se mejoran los exportadores de USD, glTF y FBX. En el caso de FBX, las versiones generadas incluyen ahora las normales asociadas a las Shape Keys, lo que se traduce en una mejor compatibilidad con motores de juego y otros programas 3D cuando se exportan personajes y animaciones.

Blender 5.1 mantiene su distribución bajo licencia GPLv3, con acceso abierto al código fuente. El software es gratuito y se puede descargar para sistemas Windows (a partir de la versión 8.1), macOS (13.0 en adelante) y Linux con glibc 2.28 o superior, cubriendo así la mayoría de entornos habituales tanto domésticos como de estudio.

Estabilidad y calidad: más de 350 errores corregidos

Junto con las novedades visibles, una parte muy importante del trabajo en Blender 5.1 se ha dedicado a reforzar la estabilidad y la calidad general. Dentro de la iniciativa conocida como «Winter of Quality», que se ha desarrollado entre diciembre y enero, se han corregido más de 350 errores reportados por la comunidad.

El área más beneficiada ha sido el conjunto de herramientas de modelado 3D, con cerca de 60 correcciones, pero las herramientas de vídeo y la interfaz gráfica no se quedan atrás, con en torno a medio centenar de arreglos cada una. El Compositor, el editor de secuencias de vídeo y los propios núcleos de Cycles y del sistema también han recibido refactorizaciones y limpiezas de código, lo que debería traducirse en un comportamiento más predecible y robusto.

Blender 5.1 incluye asimismo actualizaciones en áreas como la creación de metadatos de escenas, la reorganización interna de algunos módulos y otros cambios que, aunque menos visibles para el usuario final, contribuyen a que el programa responda mejor en proyectos de larga duración o con archivos muy pesados.

Con este conjunto de mejoras, Blender 5.1 se consolida como una actualización amplia y muy orientada al uso diario: más estabilidad, mejor rendimiento en render y animación, nuevas opciones en nodos, vídeo y VR, y una integración más sólida en pipelines profesionales. Para usuarios  que ya trabajan con Blender en animación, VFX, videojuegos o visualización, la versión supone un salto tangible en comodidad y fiabilidad, manteniendo al mismo tiempo el modelo de software libre que caracteriza al proyecto.


KDE Plasma 6.6.3 llega con mejoras de rendimiento y estabilidad

Plasma 6.6.3

La comunidad de KDE mantiene un ritmo de desarrollo constante y, además de trabajar en las próximas funciones de Plasma 6.7, ha publicado una nueva actualización de mantenimiento para su entorno de escritorio actual. Se trata de KDE Plasma 6.6.3, una versión centrada en pulir la experiencia diaria y corregir comportamientos que afectaban al rendimiento en determinadas configuraciones.

En lugar de introducir grandes cambios visuales, esta entrega se enfoca en mejoras técnicas que influyen en la fluidez del sistema, especialmente en equipos que usan escalado fraccionado o que aprovechan las capacidades de screencasting bajo Wayland. Para usuarios de distribuciones GNU/Linux, esta actualización irá llegando progresivamente a través de los repositorios habituales.

Qué supone KDE Plasma 6.6.3 dentro de la serie 6.6

KDE Plasma 6.6.3 se presenta como la tercera actualización de mantenimiento de la rama 6.6 del entorno de escritorio. Llega aproximadamente dos semanas después de Plasma 6.6.2, siguiendo el calendario habitual de revisiones periódicas con el que KDE corrige errores detectados tras las versiones anteriores.

Como es habitual en este tipo de lanzamientos, no se trata de una edición con cambios rompedores, sino de una versión orientada a refinar la estabilidad y el comportamiento interno. El objetivo es que las distribuciones que ya ofrecen Plasma 6.6 puedan proporcionar a sus usuarios una experiencia más consistente, con menos incidencias y un uso más eficiente de los recursos.

Mejoras en KWin y screencasting con PipeWire 1.6

Uno de los puntos destacados de KDE Plasma 6.6.3 está en el gestor de ventanas KWin, que es el componente encargado de dibujar y gestionar las ventanas en el escritorio. En esta versión se ha reforzado el manejo de la función de screencasting cuando se utiliza con PipeWire 1.6 o versiones posteriores.

El screencasting, ya sea para compartir pantalla en videollamadas, grabar tutoriales o retransmitir videojuegos, depende cada vez más de PipeWire en sesiones Wayland. Con Plasma 6.6.3, KWin mejora su robustez y compatibilidad con PipeWire 1.6, reduciendo la probabilidad de fallos o comportamientos irregulares al capturar la pantalla en entornos modernos.

Para usuarios que participan con frecuencia en reuniones en línea o generan contenido audiovisual desde su escritorio GNU/Linux, estos ajustes pueden traducirse en sesiones de screencasting más estables, menos cuelgues inesperados y una integración más fiable con aplicaciones que usan este sistema de captura.

Menor uso de CPU y GPU en pantalla completa con escalado fraccionado

Otro aspecto clave de KDE Plasma 6.6.3 afecta al rendimiento en pantallas que utilizan escalado fraccionado, una función cada vez más habitual en monitores de alta resolución, como los paneles 2K o 4K. Este tipo de escalado permite ajustar la interfaz a porcentajes como 125 % o 150 %, en lugar de limitarse a valores enteros.

En esta actualización, cuando una ventana se ejecuta a pantalla completa en modo de direct scanout en pantallas con escalado fraccionado, se ha optimizado la forma en que se gestiona la imagen para reducir tanto la carga de la CPU como de la GPU. Esta mejora es especialmente interesante en portátiles y equipos con recursos más ajustados, donde cada optimización se nota en el consumo energético y en la temperatura.

En la práctica, esto puede traducirse en reproducción de vídeo más fluida, menor uso del ventilador durante sesiones de juego a pantalla completa y una sensación general de sistema más ligero cuando se trabaja con aplicaciones que aprovechan este modo de visualización. Aunque el cambio es técnico, el impacto lo perciben directamente quienes utilizan resoluciones altas combinadas con escalados no enteros.

Con esta nueva revisión, Plasma 6.6.3 se posiciona como una actualización recomendable para quienes usan este escritorio a diario: no introduce grandes sorpresas visuales, pero sí ajusta piezas importantes como KWin, PipeWire y la gestión del escalado fraccionado, con el objetivo de ofrecer un entorno más eficiente, estable y cómodo en distribuciones GNU/Linux actuales.


Ubuntu 26.04 cambiará los colores de los iconos de las carpetas, finalizando otra larga tradición

Nuevos iconos en carpetas de Ubuntu 26.04

La próxima versión del sistema de Canonical será una LTS, y aunque se espera que se priorice la estabilidad, también es un momento importante que sólo tiene lugar cada dos años. Ubuntu 26.04 romperá algunas tradiciones que van de nuevas aplicaciones por defecto a unos asteriscos a modo de feedback en sudo, y recientemente ha aparecido otra en las Daily Build que podéis ver en la imagen de cabecera.

A la izquierda de la imagen tenemos cómo se ven las carpetas en Ubuntu 25.10, la última estable que es una provisional o interim (soportada durante 9 meses); a la derecha se muestra cómo serán los iconos en las carpetas de Ubuntu 26.04. Para empezar, un primer vistazo nos permite entender que han cambiado los colores. Antes eran carpetas grises por fuera y moradas/anaranjadas en lo que sería interior; ahora son naranjas, con una parte interior más oscura para mejorar el contraste.

Carpetas naranjas en Ubuntu 26.04

Cabe destacar que esto se acerca un poco más a lo que ofrece un GNOME puro, aunque el Nautilus más puro muestra carpetas en color beige. Es cada tema el que elige de qué color mostrar las carpetas, y siendo el naranja el color de acento predeterminado en Ubuntu, es también el color elegido para las carpetas en Ubuntu 26.04.

Por otra parte, también se han suavizado las formas de las carpetas. Antes eran más pronunciadas o agresivas, y en Resolute Raccoon se ven más formas más finas.

Mención especial al icono de la carpeta del escritorio, que ahora muestra una pantalla de ordenador, con el borde izquierdo más grueso que se supone que es el dock, mientras que antes mostraba lo que sería un escritorio. ¿Mejor? ¿Peor? Cada uno tendrá su opinión, pero ese escritorio es algo que también aparece en otros entornos gráficos como KDE Plasma.

Ubuntu 26.04 llegará el 23 de abril con esta y otras novedades, entre las que destaca GNOME 50 y probablemente Linux 7.0.


CachyOS desbanca a Arch Linux en ProtonDB y gana peso entre los jugadores de PC

CachyOS enero 2026

El panorama del gaming en Linux lleva años cambiando a un ritmo que, hace una década, pocos se habrían creído. Lo que antes era casi terreno exclusivo de usuarios muy avanzados se ha convertido en una alternativa real para jugar en PC, hasta el punto de que cada vez más personas comentan que sus títulos funcionan incluso mejor que en Windows, sobre todo cuando se combina una buena distribución con Proton y las tecnologías de Valve.

En ese contexto de cambio continuo, se acaba de producir un giro llamativo en las preferencias de los jugadores de escritorio: CachyOS ha adelantado a Arch Linux como la distribución con más reportes de rendimiento en ProtonDB. No se trata de un detalle menor; es el fin de una racha que se mantenía desde 2021 y que consolida a CachyOS como una opción cada vez más habitual entre los usuarios más implicados en probar y documentar el rendimiento de sus juegos en Linux, también en mercados europeos donde el interés por las alternativas libres va al alza.

CachyOS adelanta a Arch Linux en ProtonDB

Durante años, Arch Linux ha sido la referencia para muchos jugadores que querían exprimir al máximo su hardware bajo Linux. Su filosofía de «hágalo usted mismo», con una base mínima y paquetes siempre muy actualizados, ha sido sinónimo de control total a costa de exigir conocimientos técnicos que no todo el mundo está dispuesto a adquirir.

Frente a esa propuesta, CachyOS plantea algo distinto: sigue siendo una distribución basada en Arch, pero se entrega ya preparada para usar desde el primer arranque, con una configuración más amigable y un gran énfasis en la optimización. La idea es que el sistema saque más partido del procesador y del resto de componentes del PC mediante compilaciones y ajustes pensados para ganar velocidad y estabilidad, algo especialmente atractivo para quienes priorizan un rendimiento sólido en juegos sin tener que montar el sistema pieza a pieza.

Según los datos recopilados por distintos portales especializados como Boiling Steam, los reportes enviados desde CachyOS a ProtonDB han superado en número a los de Arch Linux. ProtonDB, muy conocido entre la comunidad europea de jugadores en Linux, es la plataforma donde miles de personas informan de cómo les funcionan los juegos de Windows ejecutados a través de Proton, detallando si el título va perfecto, requiere ajustes o presenta problemas relevantes.

Que CachyOS marque ahora la pauta no significa que sea automáticamente «la mejor distro para jugar» para todo el mundo, pero sí refleja que cada vez más jugadores comprometidos están apostando por ella. Son usuarios que no solo juegan, sino que se toman el tiempo de probar, medir, documentar y compartir sus resultados, algo que suele anticipar tendencias que luego terminan extendiéndose al resto de la comunidad.

Dos años de crecimiento hasta alcanzar el primer puesto

El ascenso de CachyOS no ha sido un golpe de suerte ni un fenómeno de moda repentina. Los datos publicados apuntan a un crecimiento sostenido a lo largo de aproximadamente dos años. En las gráficas compartidas por Boiling Steam se aprecia cómo la distribución empieza a ganar visibilidad con fuerza a comienzos de 2024, para terminar adelantando a Arch Linux en número de reportes de ProtonDB.

Desde 2021, Arch Linux había acumulado la mayor cantidad de informes de rendimiento en la plataforma, lo que reflejaba su popularidad entre los jugadores más tecnófilos. El hecho de que CachyOS haya roto esa racha histórica indica que parte de ese perfil de usuario está migrando hacia una solución que ofrece un punto intermedio: mantiene la base Arch, con su rapidez a la hora de recibir software reciente, pero reduce la complejidad de la configuración inicial y añade optimizaciones adicionales para mejorar la experiencia.

En Europa y en España, donde el uso de Linux para tareas de desarrollo y servidores está bastante asentado, esta tendencia empieza a notarse también en el ámbito doméstico. Cada vez más jugadores que ya utilizaban Linux para trabajar o estudiar se plantean aprovechar el mismo sistema para sus ratos de ocio, y una distro más accesible y centrada en rendimiento resulta especialmente atractiva en este contexto.

Qué nos cuentan realmente los datos de ProtonDB

Aun así, los responsables de los análisis piden cautela a la hora de interpretar estos resultados. Desde Boiling Steam se recalca que las estadísticas de ProtonDB describen a un segmento muy específico de usuarios: personas que juegan en Linux y además se implican activamente en reportar el rendimiento de sus partidas. No es, por tanto, una fotografía directa de todo el ecosistema Linux ni de todos los gamers que usan el sistema.

También se subraya que estos informes pueden no representar al conjunto de usuarios profesionales de Linux ni al total de jugadores casuales. Es difícil imaginar, por ejemplo, que un arquitecto de sistemas en la nube vaya a basar sus servidores en CachyOS solo porque lidere las estadísticas de ProtonDB. Aun así, muchos analistas coinciden en que este tipo de cambios suele ser un buen indicador de hacia dónde puede moverse el mercado más amplio a medio plazo.

Ya hubo señales parecidas en el pasado con distribuciones como Manjaro, que llegó a gozar de una presencia muy notable entre los entusiastas y, poco a poco, fue perdiendo terreno frente a alternativas consideradas más modernas o mejor mantenidas. El desplazamiento de Arch Linux por parte de CachyOS en los reportes de ProtonDB podría ser un síntoma de que parte de la comunidad busca una combinación distinta de control, facilidad de uso y rendimiento.

Sin influencia de Steam Deck: solo equipos de sobremesa

Un matiz importante de la estadística es que Steam Deck no entra en la ecuación. Boiling Steam aclara que los datos que analizan se refieren únicamente a ordenadores de escritorio tradicionales, excluyendo la consola portátil de Valve, que utiliza su propio sistema basado en Arch (SteamOS) y que en las gráficas aparece categorizado aparte, por ejemplo bajo la etiqueta HoloISO.

Esto significa que el liderazgo de CachyOS frente a Arch Linux en ProtonDB se debe estrictamente a usuarios de PC de sobremesa y portátiles, no al enorme empuje que Steam Deck ha dado al gaming en Linux en los últimos años. De hecho, el gran parque de consolas de Valve podría haber distorsionado por completo las cifras si se hubiese mezclado en la misma categoría que las instalaciones de Arch Linux en escritorio.

Al separar claramente estos entornos, el cambio de posición cobra un significado distinto: hablamos de una competencia directa en equipos de escritorio, donde los usuarios eligen distribución en función de la combinación de rendimiento, estabilidad, facilidad de instalación y soporte de la comunidad. En esa carrera, CachyOS parece estar ganando presencia frente a la tradición y veteranía de Arch.

Por qué CachyOS resulta atractiva para jugadores exigentes

Más allá de las cifras, hay varios factores que ayudan a entender por qué CachyOS está calando entre los gamers que usan Linux. Uno de los principales es su enfoque en la optimización del rendimiento, que va desde la selección de kernels y compilaciones ajustadas hasta configuraciones predeterminadas pensadas para aprovechar mejor la CPU y la GPU sin que el usuario tenga que afinarlo todo a mano.

Ese enfoque reduce una de las barreras clásicas de Arch Linux: el tiempo y los conocimientos necesarios para dejar el sistema perfectamente preparado para jugar. Con CachyOS, muchos usuarios encuentran un camino intermedio: siguen disfrutando de un entorno de base Arch, con software reciente y mucha flexibilidad, pero con menos esfuerzo inicial para alcanzar un resultado fluido en títulos modernos ejecutados vía Proton o nativamente.

En el caso de España y otros países europeos, donde cada vez hay más interés por alternativas a Windows para el día a día, esta propuesta encaja bien con el perfil de jugador que quiere un solo sistema operativo para trabajar y jugar sin tener que lidiar con instalaciones complicadas. El hecho de que la comunidad en torno a CachyOS esté muy centrada en el rendimiento en juegos refuerza su atractivo para quienes buscan exprimir al máximo su hardware sin sacrificar demasiado tiempo en configuraciones avanzadas.

Todo este movimiento alrededor de CachyOS, ProtonDB y el desplazamiento de Arch Linux como distro con más reportes de rendimiento no supone un cambio radical de un día para otro, pero sí dibuja un escenario en el que las preferencias de los jugadores de escritorio en Linux empiezan a reordenarse. Si la tendencia se mantiene, es probable que veamos a más usuarios europeos y españoles interesarse por distribuciones enfocadas en el rendimiento y la facilidad de uso, mientras que proyectos como Arch seguirán siendo la elección de quienes valoran por encima de todo el control absoluto y la personalización extrema.


FFmpeg 8.1 da un salto en aceleración GPU, metadatos y nuevos códecs

ffmpeg 8.1

La actualización a FFmpeg 8.1, de nombre en clave «Hoare», marca un punto importante en la evolución de este conocido framework multimedia de código abierto. La nueva versión estable llega con un foco claro en la aceleración por GPU, la gestión avanzada de metadatos y la incorporación de códecs y formatos emergentes, cambios que interesan tanto a usuarios finales como a profesionales del vídeo.

El equipo de desarrollo recomienda de forma expresa que todos los usuarios, distribuidores e integradores que no trabajen con la rama git más reciente actualicen a FFmpeg 8.1. Más allá de las mejoras internas y correcciones de errores, se introducen capacidades que pueden simplificar flujos de trabajo complejos, sobre todo en entornos de posproducción, streaming y herramientas de análisis multimedia.

Nueva versión estable FFmpeg 8.1 «Hoare» y contexto del lanzamiento

FFmpeg 8.1 se publica como versión estable sucesora de FFmpeg 8.0, lanzada a mediados de 2025, y consolida meses de desarrollos que hasta ahora solo estaban disponibles en el repositorio principal. La fecha de salida de esta iteración se sitúa a mediados de marzo de 2026, y el proyecto la presenta como la referencia recomendada frente a versiones anteriores, tanto para uso doméstico como para distribuciones Linux, soluciones comerciales y sistemas integrados.

En esta entrega se combinan nuevas funciones experimentales (como algunos decodificadores de audio de nueva generación) con características ya maduras relacionadas con la aceleración hardware y la gestión de contenidos multimedia profesionales. Todo ello se complementa con un paquete de correcciones de errores y pequeños retoques en distintas áreas de la herramienta de línea de comandos y las bibliotecas subyacentes.

Impulso a la aceleración de vídeo con Vulkan

Uno de los bloques más destacados de FFmpeg 8.1 es el refuerzo del soporte para Vulkan como plataforma de cómputo. El proyecto incorpora aceleración con shaders de cómputo Vulkan para realizar tanto codificación como decodificación de vídeo en códecs que no están cubiertos por las extensiones oficiales de Vulkan Video. Esta aproximación permite descargar más trabajo del procesador y mantener el flujo de datos dentro de la GPU.

La novedad más visible en este terreno es la implementación de códecs Apple ProRes y DPX basada íntegramente en Vulkan. Hasta ahora, muchos flujos mezclaban pasos en CPU y GPU, con transferencias de memoria de ida y vuelta que penalizaban la latencia y complicaban el mantenimiento del código. Con FFmpeg 8.1 se apuesta por que los datos permanezcan dentro de la memoria gráfica mientras se procesan, reduciendo cuellos de botella en cadenas de posproducción exigentes como las que se utilizan en estudios y plataformas de emisión.

Además, se introducen optimizaciones específicas para códecs basados en Vulkan y soporte para realizar escalado de vídeo mediante la infraestructura «swscale» aprovechando esta API. Esta integración abre la puerta a que aplicaciones que se apoyan en FFmpeg puedan combinar decodificación, procesado intermedio y recodificación sobre Vulkan sin tener que pasar por la CPU en cada paso intermedio.

Direct3D 12: codificación H.264 y AV1 en la GPU

En sistemas Windows, FFmpeg 8.1 refuerza también la parte de aceleración con la llegada de codificación H.264 y AV1 mediante Direct3D 12 (D3D12). Este soporte permite manejar flujos de vídeo directamente en la GPU en pipelines basados en D3D12, algo relevante para estaciones de trabajo y soluciones de streaming que funcionan sobre hardware moderno de fabricantes como AMD, Intel o NVIDIA.

Junto a la codificación, se incorporan nuevos filtros específicos para D3D12, como scale_d3d12 (escalado), mestimate_d3d12 (estimación de movimiento) y deinterlace_d3d12 (desentrelazado). Estos filtros facilitan que tareas de preprocesado habituales —redimensionado, análisis de movimiento y limpieza de contenidos entrelazados— se ejecuten en la GPU sin abandonar el entorno D3D12, lo que ayuda a crear flujos de trabajo de «GPU encoding» más coherentes y eficientes.

Novedades en códecs de vídeo: JPEG-XS y metadatos LCEVC

En el terreno de los códecs de vídeo, FFmpeg 8.1 introduce soporte inicial para JPEG-XS, un estándar pensado para compresión de baja latencia y alta calidad, habitual en entornos de producción y distribución profesional. La nueva versión añade un analizador (parser) específico para JPEG-XS, así como soporte de codificación y decodificación apoyado en el proyecto SVT-JPEG-XS a través de la biblioteca libsvtjpegxs.

Además de poder leer y generar flujos de este formato, la herramienta incorpora funciones para multiplexar y desmultiplexar bitstreams JPEG-XS en bruto. Esto es especialmente útil para integradores que manejan enlaces de contribución, sistemas de transporte profesional o infraestructuras broadcast, incluidos los despliegues sobre redes IP que se están extendiendo en Europa.

Por otro lado, se suma soporte para metadatos LCEVC (Low Complexity Enhancement Video Coding), incluyendo análisis, transporte y filtrado de bitstreams con esta información asociada. Aunque LCEVC actúa como capa de mejora sobre códecs ya implantados, disponer de soporte directo en FFmpeg facilita la experimentación y el despliegue en servicios de vídeo bajo demanda, plataformas OTT y pruebas piloto que se están llevando a cabo en distintos países.

Avances en audio: xHE-AAC, MPEG-H 3D Audio e IAMF

El audio también recibe una atención notable. FFmpeg 8.1 incorpora de forma experimental decodificación xHE-AAC Mps212, una variante de alto rendimiento del conocido códec AAC, utilizada en servicios de streaming adaptativo y emisiones digitales. Aunque su estado se considera todavía experimental, permite empezar a trabajar con este formato dentro de flujos de análisis o conversión.

Se añade asimismo la posibilidad de decodificar MPEG-H 3D Audio a través de la biblioteca libmpeghdec. Este estándar de audio tridimensional, empleado en algunos entornos de radiodifusión avanzada y experiencias inmersivas, gana así presencia en herramientas que dependen de FFmpeg, algo especialmente relevante para emisoras y productoras que preparan contenidos inmersivos.

En paralelo, se amplía el manejo de audio espacial dentro de IAMF (Immersive Audio Model and Formats). FFmpeg ahora es capaz de tratar un abanico mayor de elementos de audio espacial, incluyendo el soporte para muxing y demuxing de elementos Ambisonic en el modo de proyección IAMF. Estas capacidades resultan útiles para aplicaciones de realidad virtual, experiencias inmersivas y plataformas que buscan ofrecer sonido 3D con mayor precisión.

Metadatos e imágenes: EXIF y nuevas posibilidades

Otra área reforzada es la gestión de metadatos, donde FFmpeg 8.1 incorpora un nuevo sistema de análisis de metadatos EXIF. Gracias a esta función, el framework puede leer con más precisión información de captura y atributos asociados a imágenes fijas y ciertos tipos de contenidos multimedia, como datos de cámara, orientación, fecha u otros campos técnicos.

Para profesionales que trabajan con grandes volúmenes de imágenes o secuencias fijas —como en flujos de postproducción, archivística o fotoperiodismo—, este mejor tratamiento de EXIF facilita automatizar clasificación, filtrado y recuperación de contenido. También abre la puerta a crear herramientas específicas para la gestión de catálogos, ya que la extracción de metadatos se integra de forma nativa en el ecosistema FFmpeg.

Formatos y contenedores: HXVS/HXVT e IAMF

En cuanto a formatos y contenedores, FFmpeg 8.1 incorpora un nuevo demultiplexor «hxvs» capaz de analizar el contenedor HXVS/HXVT, un formato utilizado en cámaras IP. Esta incorporación responde a la creciente adopción de sistemas de videovigilancia y monitorización basados en IP en Europa, donde la capacidad de inspeccionar y convertir flujos de cámaras es clave para integradores y empresas de seguridad.

La expansión en los tipos de elementos de audio espacial que pueden tratarse dentro de IAMF se suma a este bloque de novedades relacionadas con formatos. Juntas, estas mejoras refuerzan el rol de FFmpeg como herramienta de referencia para manejar contenedores y flujos complejos, tanto en entornos de producción como en sistemas de monitorización o análisis en tiempo real.

Funciones específicas de hardware y captura

El listado de mejoras incluye también nuevas capacidades ligadas a hardware concreto. En FFmpeg 8.1 se incorpora soporte para codificación por hardware H.264 y HEVC en plataformas Rockchip. Este tipo de SoC, presente en mini-PC, dispositivos embebidos y soluciones de bajo consumo, tiene una presencia creciente en proyectos de cartelería digital, pasarelas multimedia y sistemas IoT.

Se añade asimismo la posibilidad de realizar captura de ventanas y monitores basada en la API Windows.Graphics.Capture. Esta función facilita la grabación y el streaming de escritorio en sistemas Windows modernos con menores limitaciones que aproximaciones antiguas, algo útil tanto para creadores de contenido como para soluciones corporativas de formación o soporte remoto.

Por el lado de AMD, FFmpeg 8.1 estrena un nuevo filtro vpp_amf que aprovecha las capacidades de vídeo del hardware de la marca. Este filtro se integra en la ya amplia gama de herramientas de procesado basadas en GPU, y puede aprovecharse para tareas como escalado, conversión de formatos o mejora de imagen dentro de pipelines que apoyan su carga en la aceleración por hardware.

Mejoras en las herramientas de línea de comandos

Las utilidades incluidas en FFmpeg también reciben pequeños ajustes. Entre ellos destaca la incorporación de la opción «ffprobe -codec», que permite obtener información centrada en los códecs al analizar flujos de audio y vídeo. Esta mejora es especialmente útil para desarrolladores y administradores que utilizan ffprobe como parte de scripts de monitorización o validación de contenidos.

Otra novedad es la capacidad de mostrar únicamente los campos «refs» de la sección de flujo al cargar fotogramas con ffprobe, lo que ayuda a inspeccionar estructuras de referencia de vídeo sin ruido adicional. Paralelamente, se ha eliminado el antiguo manejador del protocolo HLS, simplificando el código y confiando en implementaciones más modernas que ya estaban integradas en el proyecto.

Correcciones, mejoras internas y recomendación de actualización

Además de las funcionalidades visibles, FFmpeg 8.1 llega acompañado de un número considerable de correcciones de errores y ajustes internos que mejoran la estabilidad general. Aunque muchas de estas modificaciones no se ven directamente en la interfaz de usuario o en las opciones de línea de comandos, contribuyen a que las aplicaciones basadas en FFmpeg funcionen de manera más predecible.

En conjunto, la combinación de nuevas funciones, soporte ampliado de hardware y codecs emergentes hace que el proyecto recomiende con claridad actualizar a FFmpeg 8.1 siempre que no se utilice ya la rama git más reciente. Tanto distribuidores de software como proveedores de servicios de vídeo encontrarán en esta versión una base más sólida para sus productos y plataformas.

Con todo este paquete de cambios, FFmpeg 8.1 consolida su papel como pieza central en flujos de trabajo de vídeo y audio, desde la creación de contenidos hasta la emisión y el análisis técnico: la ampliación del soporte para Vulkan y D3D12, la integración de códecs como JPEG-XS, xHE-AAC o MPEG-H 3D Audio, y las mejoras en metadatos, audio inmersivo y utilidades de línea de comandos sitúan a esta versión como una actualización especialmente relevante para quienes trabajan a diario con medios digitales.


SparkyLinux 2026.03 llega con lo último de Debian Testing, entre lo que destaca Linux 6.19.6

SparkyLinux 2026.03

El equipo de desarrollo de SparkyLinux ha lanzado una nueva actualización de sus imágenes ISO para la rama semi-rolling. Se trata de SparkyLinux 2026.03, que llega con el nombre en clave «Tiamat» y trae consigo lo último del repositorio de Debian Testing, actualizado al 14 de marzo de 2026.

Como es habitual en su modelo de desarrollo, esta nueva versión no introduce una nueva rama, sino que actualiza los instaladores para quienes deseen hacer una instalación limpia. Los usuarios que ya tengan una edición Rolling en sus equipos no necesitan descargar nada; con mantener su sistema actualizado (apt update && apt upgrade) tendrán todos estos paquetes desde hace días.

SparkyLinux 2026.03 Tiamat: Novedades y Detalles Técnicos

Esta actualización pone especial énfasis en ofrecer el hardware más reciente gracias a su núcleo. Por defecto, las nuevas imágenes incorporan el kernel Linux 6.19.6, aunque los repositorios de Sparky ya tienen preparadas otras alternativas como la serie 7.0-rc3, la 6.19.8, o las LTS 6.18.18 y 6.12.77 para quienes prefieran máxima estabilidad.

En el apartado de aplicaciones, encontramos las versiones ESR (Extended Support Release) de Firefox y Thunderbird, concretamente la 140.8. Pero si necesitas lo último del navegador de Mozilla, también puedes instalar la versión Firefox 148 directamente desde los repositorios de la distribución.

La instalación también recibe mejoras. Se ha actualizado el instalador gráfico Calamares a la versión 3.4.2, que ahora técnicamente permite contraseñas de un solo carácter durante el proceso, aunque los desarrolladores recomiendan encarecidamente usar una contraseña segura de entre 8 y 12 caracteres. Por otro lado, el instalador por línea de comandos (sparky-installer) ahora ofrece la posibilidad de instalar la versión ia32 de GRUB para UEFI en máquinas de 64 bits.

Un detalle importante para equipos modernos: si tu equipo usa UEFI, la instalación requiere una conexión a internet activa, y se recomienda usar el instalador gráfico Calamares. Para equipos más antiguos con BIOS, tanto el instalador CLI como el gráfico funcionan sin problemas.

SparkyLinux 2026.03 está disponible para arquitectura amd64 en múltiples sabores, incluyendo LXQt, KDE Plasma, MATE, Xfce, una versión MinimalGUI con Openbox, y una MinimalCLI solo para terminal. Puedes encontrar las nuevas imágenes en la página de descarga del proyecto.


Limine: bootloader moderno, portátil y multiprotocolo que actúa como referencia del Limine Boot Protocol y soporta Linux

Limine

Cuando se habla de Limine en Internet, mucha gente piensa directamente en un gestor de arranque moderno para sistemas operativos, pero también es una expresión jurídica latina muy usada en el ámbito procesal. Este doble significado hace que el término genere cierta confusión, sobre todo cuando se busca información en Google y aparecen resultados tanto tecnológicos como legales. Aquí vamos a poner orden y a explicar sólo lo que nos interesa, que es la alternativa a GRUB.

Limine es un bootloader multiprotocolo de nueva generación, muy popular en el mundo Linux y entre desarrolladores de sistemas operativos. A lo largo del artículo veremos qué es Limine como software, qué ofrece frente a otros gestores de arranque como GRUB o rEFInd, cómo se instala y configura en distintas plataformas y qué herramientas auxiliares tiene.

Qué es Limine como gestor de arranque

Limine es un gestor de arranque avanzado, portátil y multiprotocolo, escrito principalmente en C y ensamblador, que funciona como referencia oficial de su propio protocolo de arranque: el Limine Boot Protocol. A la vez, actúa como bootloader generalista capaz de cargar Linux, otros kernels compatibles y de encadenar (chainload) a otros cargadores de arranque ya instalados en el sistema.

Uno de los objetivos clave de Limine es proporcionar una alternativa más robusta a GNU GRUB y, al mismo tiempo, ofrecer un protocolo moderno que simplifique la vida a quienes desarrollan kernels. La idea es que, una vez que el bootloader termina su trabajo, el kernel reciba un entorno de 64 bits bien preparado, con menos “chapuzas” y pasos intermedios que en especificaciones más antiguas como Multiboot o Multiboot2.

Este proyecto está desarrollado por @mintsuki y otras personas colaboradoras, bajo licencia BSD-2-Clause. La versión estable pertenece a la rama 10.x y las releases siguen un esquema de versionado semántico (Semantic Versioning), lo que facilita entender rápidamente si un cambio es menor, mayor o de tipo parche.

Arquitecturas y plataformas compatibles

Limine presume de ser muy portátil a nivel de arquitectura. A partir de la información oficial, actualmente soporta, entre otras, las siguientes plataformas:

  • IA-32 (x86 de 32 bits), con soporte garantizado a partir de CPUs de clase Pentium Pro (i686).
  • x86-64, es decir, la arquitectura de 64 bits de escritorio más extendida en PCs actuales.
  • aarch64 (arm64), habitual en servidores ARM y algunos dispositivos de escritorio modernos.
  • riscv64, cada vez más presente en entornos experimentales y de investigación.
  • loongarch64, con un soporte aún experimental según la propia documentación del proyecto.

En la práctica, cualquier sistema x86-64, aarch64, riscv64 o loongarch64 con firmware UEFI entra dentro de los objetivos de soporte de Limine. Para la arquitectura x86 de 32 bits, como se ha comentado, el soporte está enfocado a procesadores relativamente modernos (i686 en adelante), dejando fuera generaciones muy antiguas.

Protocolos de arranque admitidos

Una de las razones por las que Limine tiene tan buena acogida entre usuarios avanzados es que reconoce varios protocolos de arranque, lo que le permite funcionar como una especie de “hub” para distintos sistemas operativos y bootloaders.

Entre los protocolos soportados se incluyen:

  • Protocolo Linux, para arrancar directamente kernels de GNU/Linux junto con su initramfs.
  • Protocolo Limine, el propio protocolo nativo del proyecto, especialmente pensado para facilitar el trabajo a desarrolladores de kernels personalizados.
  • Multiboot 1, una especificación muy extendida en sistemas operativos alternativos y proyectos educativos.
  • Multiboot 2, la evolución de la anterior, con nuevas características y mayor flexibilidad.
  • Chainloading, es decir, la capacidad de delegar el control a otro bootloader, como el cargador de Windows o rEFInd.

Gracias a este enfoque multiprotocolo, Limine se adapta bien a escenarios de multiboot donde conviven Linux, otros sistemas experimentales y cargadores de arranque ya presentes en el disco. No pretende monopolizar todo, sino servir de capa de orquestación flexible.

Esquemas de particionado y sistemas de archivos

En cuanto al particionado del disco, Limine funciona con los esquemas más habituales en sistemas de escritorio y servidores. Concretamente, admite:

  • MBR (Master Boot Record), el clásico esquema de particiones usado durante décadas.
  • GPT (GUID Partition Table), el estándar moderno recomendado, especialmente con UEFI.
  • Medios sin particionar, útil en ciertos casos como imágenes ISO o configuraciones muy sencillas.

Respecto a los sistemas de archivos, aquí Limine adopta una filosofía deliberadamente minimalista. El bootloader solo soporta de forma nativa unos pocos formatos:

  • FAT12, FAT16 y FAT32, muy comunes en particiones de sistema EFI (ESP) y medios extraíbles.
  • ISO9660, el estándar típico utilizado para CDs y DVDs.

Este listado relativamente corto es intencional. Limine no pretende entender todos los sistemas de archivos que pueda usar el sistema operativo en su raíz (ext4, Btrfs, XFS, ZFS, etc.), sino centrarse en una capa muy concreta: la de los ficheros de arranque (núcleo, initramfs, microcódigo y similares) ubicados en una partición FAT o en un medio ISO. El propio proyecto deja claro que, si tu sistema de archivos no aparece en esa lista, se recomienda consultar antes la FAQ en lugar de abrir incidencias o pull requests pidiendo soporte directo.

Esto implica que, en configuraciones UEFI típicas, el kernel y el initramfs deben residir en la ESP FAT32 o en otra partición FAT dedicada, mientras que la raíz del sistema puede estar en Btrfs, ext4, ZFS, etc. Para los usuarios que vienen de otros bootloaders, esto puede chocar un poco, pero tiene sentido dentro de la filosofía de diseño de Limine.

Requisitos mínimos del sistema

En lo relativo a los requisitos de hardware, Limine se mantiene bastante conservador pero razonable. Para sistemas x86 de 32 bits, el soporte se garantiza a partir de la generación Pentium Pro / i686. Todo lo anterior puede funcionar o no, pero no está dentro de las metas oficiales.

Para arquitecturas de 64 bits en general, todas las máquinas x86-64, aarch64, riscv64 y loongarch64 con UEFI están dentro del ámbito soportado. Esto incluye desde equipos de sobremesa y portátiles relativamente modernos hasta servidores y algunos dispositivos ARM avanzados.

Distribución, versiones y binarios precompilados

La forma principal de obtener Limine es a través de su repositorio oficial en Codeberg, donde se mantiene el código fuente y la documentación. Desde la versión 7.x en adelante, el proyecto utiliza versionado semántico (por ejemplo, 10.5.0), lo que facilita saber si una actualización puede traer cambios incompatibles o solo correcciones.

Para hacer la vida más sencilla a los usuarios, el proyecto proporciona ramas y etiquetas “-binary” que contienen binarios precompilados para cada versión puntual. Estas ramas tienen nombres como v10.x-binary o v10.8.5-binary, y permiten clonar directamente una release lista para usar sin pasar por todo el proceso de compilación.

Un ejemplo muy típico sería clonar la última release binaria de la rama 10.x con un comando similar a git clone con la rama v10.x-binary y profundidad 1. Si se quiere una versión concreta, se cambia por la etiqueta exacta, por ejemplo v10.8.5-binary. Una vez clonado el repositorio binario, basta con ejecutar make en el directorio correspondiente para reconstruir utilidades de usuario como el ejecutable limine. Además, se proporcionan binarios para Windows, lo que facilita preparar medios de arranque desde sistemas de Microsoft.

Instalación genérica: fuentes vs binarios

Si has clonado una de las ramas binarias, los pasos clásicos de compilación desde cero dejan de ser estrictamente necesarios. Aun así, el proyecto remite a ficheros como INSTALL.md, USAGE.md y 3RDPARTY.md para quien quiera construir Limine desde las fuentes, revisar la licencia de terceros o profundizar en detalles de uso más avanzados.

En resumen, existen dos grandes enfoques para instalar Limine en tu sistema:

  • Usar paquetes de la distribución (por ejemplo, en Arch Linux o Gentoo), aprovechando scripts y hooks ya preparados.
  • Clonar desde Codeberg, bien sea la rama de código fuente principal o una rama de binarios, para un control más directo y fino sobre la instalación.

Instalación y despliegue en Arch Linux

Arch Linux ofrece un paquete oficial limine, que se instala con el gestor de paquetes pacman. Tras instalar dicho paquete, la documentación de Arch aconseja seguir los apartados de “Deploying the boot loader” y “Configuration” para completar la puesta en marcha.

Despliegue en sistemas UEFI

En un sistema UEFI típico, la instalación de Limine consiste en copiar el binario EFI adecuado a la partición del sistema EFI (ESP) y asegurarse de que el firmware lo ve como una opción de arranque. En el caso de máquinas x86-64, se utiliza normalmente el archivo BOOTX64.EFI ubicado en /usr/share/limine/.

El flujo habitual en Arch Linux sería crear primero un directorio en la ESP, por ejemplo esp/EFI/arch-limine, y después copiar el ejecutable EFI a ese directorio. Si se trata de una UEFI de 32 bits, en vez de BOOTX64.EFI se usaría BOOTIA32.EFI. Una vez copiado, se puede registrar la entrada en el firmware usando efibootmgr, especificando el disco (/dev/sdX) y el número de partición de la ESP, junto con la ruta al binario EFI dentro de dicha partición.

Este paso con efibootmgr no es automático: Limine no escribe entradas NVRAM por su cuenta, así que es responsabilidad del usuario crear una nueva entrada de arranque, por ejemplo con la etiqueta “Arch Linux Limine Boot Loader”.

Despliegue en BIOS con MBR

En equipos que arrancan en modo BIOS con tabla de particiones MBR, la instalación de Limine se divide en dos partes. Por un lado, hay que copiar el archivo limine-bios.sys (que contiene el código de la tercera etapa del bootloader) a alguna partición cuyo sistema de archivos esté soportado (normalmente FAT) y que forme parte del mismo disco donde se instalará el arranque.

El archivo limine-bios.sys puede vivir en el directorio raíz, en /boot, en /limine o en /boot/limine. Una configuración muy típica es tener una partición FAT montada en /boot y copiar ahí el archivo dentro de /boot/limine/. Después, se ejecuta el comando limine bios-install /dev/sdX (donde /dev/sdX es el disco, no la partición) para escribir las etapas iniciales del bootloader en el MBR y sectores adyacentes del disco.

Despliegue en BIOS con GPT

Si el disco usa particiones GPT y se arranca igualmente en modo BIOS, hace falta un pequeño ajuste adicional. En este caso, Limine requiere una partición especial sin sistema de archivos donde almacenar su código de arranque temprano. Esta partición debe tener al menos 32 KiB y usar el GUID de tipo 21686148-6449-6E6F-744E-656564454649, conocido como “BIOS boot partition”.

Una vez creada esa partición, se ejecuta de nuevo limine bios-install, esta vez especificando el dispositivo que incluye número de partición. Si no se indica, la herramienta intentará detectar automáticamente la partición adecuada. Como en el caso MBR, hay que asegurarse de que limine-bios.sys se copie a alguna partición soportada del mismo disco.

Unidades preparadas para UEFI y BIOS a la vez

Una ventaja interesante del enfoque de Limine es que permite construir unidades booteables híbridas que funcionen tanto en firmware UEFI como en BIOS clásico. Mientras el disco use MBR y contenga una ESP adecuada (que además puede ser la misma partición FAT usada como /boot para BIOS), se pueden seguir a la vez los pasos de despliegue UEFI y BIOS.

Este tipo de configuración es muy útil cuando se quiere montar, por ejemplo, un USB instalador universal que pueda iniciarse en equipos antiguos con BIOS y en máquinas más nuevas con UEFI sin tener que mantener dos medios distintos.

Configuración básica en Arch: limine.conf

Limine no proporciona de serie un archivo de configuración predeterminado; es decir, hay que crear “limine.conf” a mano. Este fichero instruye al bootloader sobre qué sistemas operativos y kernels están disponibles y cómo debe mostrarlos en el menú de arranque.

En sistemas UEFI, lo más cómodo es situar limine.conf en el mismo directorio que el ejecutable EFI de Limine, ya que el bootloader mira ahí primero. Esto facilita tener varias instalaciones independientes de Limine en una misma ESP, cada una con su propia configuración. En BIOS, o si no se ha puesto el fichero junto al binario EFI, la configuración debe ir en el directorio raíz, /boot, /limine o /boot/limine de una partición soportada del disco donde se instaló Limine.

El nombre del archivo debe ser exactamente limine.conf. Dentro de ese fichero, la notación boot():/ hace referencia a la partición donde reside el propio limine.conf. Si el kernel y el initramfs están en otra partición diferente (por ejemplo, una partición FAT de /boot distinta de la ESP), es posible cambiar boot():/ por uuid(PARTUUID):/, usando el PARTUUID de la partición FAT correspondiente.

Un ejemplo sencillo para un sistema Arch con un único kernel podría definir un timeout de 5 segundos, un protocolo linux, la ruta al kernel (por ejemplo boot():/vmlinuz-linux), la línea de comandos con el UUID de la raíz y el modo lectura-escritura, y el module_path para el initramfs. Aunque la sintaxis exacta ha ido cambiando con las versiones, la documentación oficial detalla al milímetro las claves posibles.

Conviene tener presente que en algunas máquinas la UEFI no inicializa todos los discos si está activada la opción de “fast boot”. En esos casos, Limine puede fallar al abrir imágenes de otros discos con errores del estilo “Failed to open image with path…”. La solución suele pasar por desactivar el arranque rápido o habilitar en la BIOS la inicialización de todos los dispositivos de almacenamiento.

Memtest86+ y Windows en Limine

Una de las ventajas prácticas de usar Limine como gestor de arranque principal es que puede integrarse con herramientas externas como Memtest86+ o con el propio cargador de Windows, todo gestionado desde limine.conf.

Para usar Memtest86+ en sistemas UEFI, basta con instalar el paquete memtest86+-efi y añadir una entrada en la configuración indicando protocolo efi y la ruta, normalmente algo como boot():/memtest86+/memtest.efi. En sistemas BIOS, se emplea el paquete memtest86+ clásico y se define una entrada con protocolo linux y la ruta memtest.bin, indicando igualmente dónde se encuentra el archivo.

Para Windows en modo UEFI, se puede aprovechar el chainloading: se declara una entrada en Limine con protocolo efi y una ruta del estilo boot():/EFI/Microsoft/Boot/bootmgfw.efi. En algunos casos, puede ser recomendable usar de nuevo la notación uuid(PARTUUID):/ en lugar de boot():/ si el fichero de configuración está en una partición distinta de la ESP principal donde vive el cargador de Windows.

Automatización con pacman hooks

En Arch Linux se recomienda crear hooks de pacman para que, cada vez que se actualice el paquete limine, se reprograme automáticamente el bootloader. Hay dos ejemplos típicos: uno para UEFI y otro para BIOS.

En UEFI, el hook suele ejecutar un simple cp para copiar el binario BOOTX64.EFI desde /usr/share/limine a la ruta concreta de la ESP (por ejemplo, esp/EFI/arch-limine/) tras cada actualización. En BIOS, el hook acostumbra a lanzar limine bios-install /dev/sdX y copiar de nuevo el archivo limine-bios.sys a /boot/limine/. Eso sí, hay que ser muy cuidadoso con la ruta del disco usada en el hook, porque si cambian los nombres de dispositivo (por mover el disco de equipo, enchufar nuevas unidades, etc.), se podría sobreescribir el MBR de otro disco sin querer.

Herramientas auxiliares en Arch: limine-entry-tool y limine-snapper-sync

Para automatizar la gestión de entradas de arranque y la integración con snapshots de Btrfs, el ecosistema de Arch ofrece varias herramientas complementarias a Limine.

Por un lado, existen utilidades como limine-entry-tool (y scripts asociados) que se encargan de generar y actualizar entradas de kernels e initramfs al instalar o actualizar paquetes de núcleo. Estas herramientas incluyen hooks para mkinitcpio y dracut: en lugar de llamar directamente a mkinitcpio o dracut, se utilizan comandos adaptados como limine-mkinitcpio o limine-dracut que, además de generar la imagen de arranque, actualizan limine.conf en la ESP.

La configuración se centraliza en un fichero como /etc/default/limine, donde se pueden ajustar opciones muy útiles, por ejemplo:

  • Definir ESP_PATH manualmente si bootctl --print-esp-path no detecta bien la partición EFI.
  • Activar o desactivar la generación automática de initramfs de fallback (opción DRACUT_FALLBACK).
  • Elegir si se prefiere arrancar usando UKI (Unified Kernel Image) con ENABLE_UKI.
  • Buscar y añadir otros bootloaders presentes en la ESP (systemd-boot, rEFInd, etc.) gracias a la opción FIND_BOOTLOADERS.
  • Configurar Limine como fallback de la UEFI con ENABLE_LIMINE_FALLBACK, de modo que, si la firmware borra las entradas personalizadas, use automáticamente Limine.

Por otro lado, la herramienta limine-snapper-sync (disponible en AUR) añade integración entre Snapper y Limine para sistemas con Btrfs. Esta utilidad permite crear entradas de arranque para snapshots, restaurar el sistema a estados anteriores (usando métodos como rsync, replace o el propio Snapper), generar entradas de “backup” tras una restauración, reparar ficheros de arranque dañados copiándolos desde snapshots recientes e incluso avisar de posibles problemas de hardware si detecta discrepancias en los hashes de archivos críticos.

Para que funcione, es necesario que limine.conf contenga algún indicador como //Snapshots o /Snapshots en la entrada principal del sistema. Además, hay que ajustar variables como ROOT_SUBVOLUME_PATH o ROOT_SNAPSHOTS_PATH si se usa un layout de Snapper personalizado. Una vez configurado, se puede lanzar limine-snapper-sync para comprobar que todo va bien y, si funciona, habilitar el servicio limine-snapper-sync.service para mantener sincronizadas las entradas con la lista de snapshots de forma automática.

Instalación y configuración en Gentoo

En Gentoo, Limine se encuentra disponible en el árbol principal de ebuilds, pero puede aparecer inicialmente enmascarado. Para poder instalarlo, hay que añadir el paquete sys-boot/limine a un fichero dentro de /etc/portage/package.accept_keywords/, lo que esencialmente permite el uso de palabras clave (keywords) más “inestables” o de prueba para ese paquete concreto.

Adicionalmente, Gentoo permite ajustar USE flags para compilar únicamente aquello que interesa. Por ejemplo, en una máquina AMD64 con UEFI, se pueden activar solo las opciones relacionadas con EFI para esa arquitectura, reduciendo así el tamaño y la complejidad de la instalación. El listado completo de USE flags soportadas se puede consultar con los comandos habituales de Portage.

Tras desmascarar y ajustar las USE flags, se instala Limine con la orden habitual de emerge sobre sys-boot/limine. A partir de ahí, el proceso de configuración discurre de forma similar a Arch, pero con algunas particularidades descritas en la wiki de Gentoo.

Copia de archivos para UEFI y BIOS en Gentoo

La guía de Gentoo enfatiza que Limine necesita un punto de montaje vfat en /boot, que será la ESP en sistemas UEFI y una partición FAT dedicada en sistemas BIOS. Antes de copiar nada, se recomienda comprobar con lsblk que /boot está realmente montado en la partición correcta.

En el caso de UEFI, se sigue una estructura de directorios estándar (/boot/EFI/BOOT/ u otra similar) y se copia el binario EFI correspondiente desde /usr/share/limine. La mayoría de las UEFI detectan esta estructura por defecto sin necesidad de usar efibootmgr, aunque, si el firmware es quisquilloso o si se quiere más control, se puede crear una entrada NVRAM manualmente con dicho programa.

En BIOS, el proceso se parece mucho al de Arch: se copia limine-bios.sys al root de /boot o a un subdirectorio (por ejemplo, /boot/limine), y luego se ejecuta limine bios-install /dev/sdX para escribir el código en el MBR. La documentación recuerda una vez más que hay que sustituir sdX por el disco correcto, ya sea un dispositivo SATA, NVMe o eMMC, y que debe tener tabla de particiones DOS (MBR) para ese método concreto.

Sintaxis moderna de limine.conf en Gentoo

Desde las versiones 9.x, Limine ha dejado de admitir la sintaxis de configuración “legacy” utilizada en ramas 7.x y 8.x. Por tanto, al actualizar desde versiones antiguas, es obligatorio adaptar el archivo limine.conf al nuevo formato. En instalaciones nuevas no hay que preocuparse, siempre que se siga la documentación reciente.

La wiki de Gentoo ofrece ejemplos de configuración genéricos pensados para sistemas con el kernel de distribución sys-kernel/gentoo-kernel o sys-kernel/gentoo-kernel-bin y raíz en Btrfs. Dichos ejemplos muestran cómo usar boot():/ para hacer referencia a la partición de /boot, cómo pasar parámetros al kernel para que monte la raíz desde un subvolumen Btrfs (por ejemplo, rootflags=subvol=/@), y cómo especificar una entrada separada para microcódigo o initramfs.

También se proporciona un ejemplo adaptado a root en ZFS, donde la línea de comandos del kernel incluye el parámetro root=zfs:pool/dataset y se cargan de antemano los módulos necesarios para ZFS a través de la opción modules. Esto resulta especialmente útil porque ZFS no suele estar integrado directamente en el kernel, sino como módulos externos que se instalan con paquetes como sys-fs/zfs-kmod.

Configuraciones de arranque dual con Windows

La wiki de Gentoo detalla cómo realizar doble arranque con Windows usando Limine tanto en UEFI como en BIOS. En UEFI, el enfoque es el mismo que en Arch: una entrada con protocolo efi que apunta al archivo bootmgfw.efi de Microsoft, agrupando incluso varias entradas en un sistema jerárquico (por ejemplo, con “subentradas” para diferentes sistemas bajo una cabecera común).

En BIOS, el chainloading es similar pero apuntando a otra partición en MBR. Hay que especificar cuidadosamente el disco y la partición, y a veces hace falta algo de prueba y error hasta dar con la combinación que arranca el Windows correcto. En ambos escenarios, la principal diferencia respecto a GRUB es que Limine no depende de os-prober para detectar otros sistemas; se definen las entradas de forma manual, pero con una sintaxis muy legible.

Uso, comunidad y soporte alrededor de Limine

Además de las wikis de Arch y Gentoo, Limine está empaquetado en varias distribuciones más: aparece como opción en el instalador oficial de Arch (archinstall), se incluye en EasyOS (derivado de Puppy Linux), forma parte de CachyOS, Chimera Linux y KaOS, y es utilizado como bootloader en proyectos como Cosmos y soportado por SerenityOS. Todo esto refuerza su papel como alternativa real y moderna frente a bootloaders tradicionales.

El desarrollo está coordinado a través de su repositorio en Codeberg y de su web oficial, pero la comunidad también se mueve en canales como una sala de Matrix (#limine:matrix.org) y una comunidad en Fluxer, donde se puede pedir ayuda, compartir información o simplemente charlar sobre novedades. Quien quiera apoyar el proyecto económicamente puede hacerlo mediante Liberapay, aunque las donaciones se presentan siempre como algo totalmente opcional.

Como curiosidad, la documentación menciona de forma desenfadada créditos como “Photo by Pixabay”, mostrando cierto cuidado por los detalles visuales en la presentación oficial del proyecto.

Debate sobre /boot en FAT32 y multiboot con varias distros

En algunos foros y debates técnicos, se ha planteado una preocupación recurrente sobre el uso de Limine en escenarios con múltiples distribuciones Linux instaladas en un mismo SSD. El caso típico es el de alguien que tiene varias distros con raíces en Btrfs, particiones separadas para /boot (a veces en Btrfs, otras en ext4) y una ESP FAT32 común. Algunas distros exigían antaño una partición /boot dedicada, y mezclar los kernels de varias instalaciones en la misma ruta se sabe que puede terminar en desastre si una sobreescribe archivos de otra.

El punto conflictivo suele ser que Limine exige que el /boot que él usa sea FAT32 (la ESP en sistemas UEFI o una partición FAT en BIOS), lo que implica que el kernel y los archivos de arranque se guardan en una partición FAT y no en ext4 o Btrfs. Ante esto, algunos usuarios se preguntan:

  • Si instalar otras distros con ese esquema no es arriesgado, porque podrían machacar los ficheros de /boot de las demás.
  • Si no resulta inseguro o inestable tener el núcleo en un sistema de archivos FAT32, comparado con alternativas “de toda la vida” como ext4.

La documentación oficial de Limine remite principalmente a la herramienta de gestión de entradas y a la filosofía de mantener todo en una partición FAT mínima y controlada, pero en la práctica, quienes buscan un sistema multiboot muy automatizado suelen valorar alternativas como rEFInd (capaz de detectar automáticamente Linux y Windows y de integrarse con snapshots Btrfs) o GRUB, con su larga historia y utilidades como os-prober.

En cualquier caso, la clave con Limine es entender que no intenta resolver todos los escenarios por sí mismo: opta por una aproximación más sencilla y acotada (FAT + archivos de arranque) y deja al usuario y a las herramientas de la distro la responsabilidad de organizar el resto de la arquitectura de particiones y snapshots.