NICALINUX

PeaZip 10.9 ya está disponible y llega como una actualización importante de este gestor y compresor de archivos de código abierto, utilizado en sistemas GNU/Linux, BSD, macOS, ReactOS y Windows. El proyecto, mantenido por Giorgio Tani, sigue centrado en pulir la experiencia diaria de gestión de ficheros y archivos comprimidos en equipos de escritorio.

Tras algo más de dos meses desde la anterior versión, PeaZip 10.8, esta nueva entrega se orienta sobre todo a mejorar la usabilidad: se introducen menús contextuales alternativos, nuevos atajos de teclado y una navegación más fluida entre paneles. En conjunto, los cambios apuntan a que el programa resulte más cómodo tanto para usuarios habituales como para quienes solo lo usan de forma puntual para comprimir y descomprimir archivos.

PeaZip 10.9 introduce menús contextuales renovados y atajos de teclado adicionales

Una de las novedades más visibles está en los nuevos menús contextuales alternativos para las acciones de «Abrir con» y «Renombrar». Estas opciones se han reorganizado para que resulte más rápido elegir con qué aplicación abrir un archivo o cambiarle el nombre sin tener que navegar por múltiples cuadros de diálogo, algo especialmente útil en entornos de trabajo con muchos ficheros.

La actualización también incorpora nuevos atajos de teclado para los visores de texto y hexadecimal que se integran en la propia aplicación. Estos accesos directos permiten, por ejemplo, cambiar entre modos de visualización o ajustar el zoom sin recurrir siempre al ratón, lo que puede agilizar bastante el flujo de trabajo de usuarios avanzados o administradores que consultan con frecuencia el contenido interno de los archivos.

Mejoras en el visor de imágenes integrado

Otra mejora importante en este apartado es la gestión automática de las barras de desplazamiento. Cuando la imagen excede el tamaño disponible, se muestran barras verticales y horizontales solo cuando hacen falta, evitando así redimensionados forzados o recortes de la imagen, algo que en pantallas pequeñas o configuraciones multimonitor puede marcar la diferencia en la comodidad de uso.

Visor de texto más potente y flexible en PeaZip 10.9

El visor de texto interno también da un salto de calidad con la capacidad de detectar cabeceras BOM (Byte Order Mark). Esta mejora técnica ayuda a que PeaZip interprete mejor la codificación de los ficheros de texto, reduciendo problemas típicos como caracteres extraños o símbolos incorrectos cuando se abren documentos en diferentes idiomas o procedentes de distintos sistemas.

Además, se añaden varios atajos de teclado para manejar funciones habituales del visor de texto, como activar o desactivar el ajuste de línea (word wrap), establecer si la búsqueda debe distinguir mayúsculas y minúsculas, conmutar el uso de negrita, alternar el tipo de letra monoespaciada o ajustar el nivel de zoom. Estas preferencias pueden guardarse como opciones persistentes en la interfaz, de forma que el usuario no tenga que reconfigurarlas cada vez que abre un archivo.

El visor hexadecimal (Hex viewer) también se beneficia de estas mejoras al incorporar soporte para fuente monoespaciada. Esto facilita la lectura de datos binarios y la comparación visual de bytes, algo especialmente relevante para tareas técnicas como el análisis de ficheros o la revisión rápida de cabeceras en entornos profesionales.

Rendimiento mejorado en archivos RAR y grandes volúmenes

En el plano del rendimiento, PeaZip 10.9 perfecciona la detección automática del binario RAR en sistemas no Windows. Esto significa que, cuando el usuario tiene instaladas las herramientas correspondientes, el programa las localizará de forma más fiable, mejorando la compatibilidad con este formato tan extendido en el intercambio de archivos comprimidos.

También se ha trabajado en la velocidad y la eficiencia a la hora de navegar por archivos comprimidos con muchos elementos. Cuando un archivo contiene miles de ficheros o directorios internos, la nueva versión responde mejor y reduce los tiempos de espera al listar el contenido, algo muy valorable en contextos laborales donde se manejan copias de seguridad, repositorios de software o colecciones extensas de documentos.

El tratamiento de los archivos multivolumen se ha mejorado igualmente, con una gestión más sólida de los distintos fragmentos en que se puede dividir un archivo comprimido. Junto a esto, la ventana de progreso de tareas ofrece ahora una información más clara y detallada, de manera que el usuario sabe mejor qué está haciendo el programa en cada momento mientras comprime, descomprime o verifica datos.

Gestión de archivos temporales y respuesta más fluida en PeaZip 10.9

Para mejorar la reactividad del gestor de archivos, PeaZip introduce un sistema de eliminación asíncrona de los ficheros temporales generados durante las previsualizaciones. En lugar de bloquear la interfaz mientras borra estos elementos, la aplicación gestiona ese proceso en segundo plano, permitiendo al usuario seguir trabajando con mayor sensación de fluidez.

Se suma, además, la posibilidad de eliminar el archivo comprimido actual directamente desde el menú desplegable situado a la derecha del botón «Eliminar del archivo». Este pequeño ajuste de interfaz reduce pasos cuando se quieren limpiar rápidamente archivos ya innecesarios tras haber extraído su contenido.

Nuevas opciones para el botón central del ratón

Otra novedad interesante es la opción de personalizar el comportamiento del botón central del ratón. El usuario puede elegir entre varias acciones, como subir un nivel en la carpeta, retroceder en la navegación, renombrar elementos, abrir en una nueva pestaña (opción configurada por defecto) u optar por abrir en una ventana independiente.

Esta capacidad de asignar funciones al clic central ofrece un manejo más adaptado a cada entorno de trabajo. Quienes trabajan con muchas pestañas pueden preferir mantener la apertura en nuevas pestañas, mientras que otros quizá se sientan más cómodos abriendo ventanas separadas o utilizando el botón central para moverse entre directorios con mayor rapidez.

Secuencia de cierre y arranque más robusta

Los desarrolladores han revisado la forma en que la aplicación se cierra para garantizar que la configuración se guarde a tiempo, incluso en situaciones en las que la eliminación sincronizada de ficheros temporales resulta especialmente lenta. Este cambio busca evitar que se pierdan ajustes o preferencias del usuario cuando se dan estas circunstancias menos habituales.

También se ha reordenado la secuencia de arranque para que el programa funcione de manera más uniforme en todos los conjuntos de widgets. Entre otros aspectos, la barra de progreso aparece ahora antes durante el inicio, lo que ayuda a percibir que la aplicación está arrancando y reduce posibles confusiones o la tentación de forzar el cierre pensando que se ha quedado congelada.

Integración en escritorios Linux y actualización de iconos

En el ecosistema GNU/Linux y otros sistemas de escritorio libres, PeaZip 10.9 actualiza su documentación de integración con FreeDesktop. Esto permite una mejor convivencia con escritorios habituales en Europa como GNOME, KDE Plasma, Xfce o similares, facilitando la asociación de tipos de archivo, la presencia en menús y la correcta aparición de accesos directos.

La documentación específica para entornos de empaquetado como Flatpak y otros sistemas de sandboxing también se ha puesto al día, con el objetivo de que la aplicación se comporte de forma más predecible y coherente dentro de estos contenedores. Junto a ello, se han retocado varios iconos para adaptarlos mejor a los temas visuales actuales y mejorar la legibilidad en pantallas de alta resolución.

Núcleo actualizado y disponibilidad de PeaZip 10.9 en varias plataformas

Bajo el capó, PeaZip 10.9 incorpora Pea 1.29 como backend por defecto. Esta pieza es la encargada de gestionar internamente muchas de las operaciones de compresión y descompresión, por lo que su actualización contribuye a mantener la compatibilidad con formatos modernos y a mejorar la estabilidad general del programa.

La nueva versión se puede descargar desde la página web oficial del proyecto en forma de binarios listos para usar en sistemas GNU/Linux, BSD, macOS y Windows. En el caso concreto de Linux, se ofrecen versiones con interfaces basadas en GTK2, GTK3 y Qt 6, lo que permite integrarse mejor con diferentes escritorios y preferencias de los usuarios europeos y españoles que utilizan distribuciones variadas.

En conjunto, PeaZip 10.9 se presenta como una actualización centrada en pulir detalles que marcan la diferencia en el día a día: desde un visor de texto e imágenes más cómodo hasta una navegación más rápida por archivos comprimidos grandes, pasando por una mejor integración en escritorios modernos y opciones de personalización adicionales. Sin introducir cambios radicales, la versión refuerza la sensación de herramienta madura y estable para quienes necesitan gestionar archivos y compresiones a menudo en su equipo.

Si sueles trastear con aplicaciones en formato AppImage en tu escritorio Linux, seguramente ya te habrás dado cuenta de que gestionarlas a mano puede ser un auténtico rollo: mover archivos, dar permisos de ejecución, crear accesos directos, iconos, actualizaciones… Todo eso, una y otra vez. Aquí es donde entra en juego AppManager, una herramienta pensada precisamente para hacerte la vida más fácil con los AppImages, pero además con un toque visual muy cuidado y un flujo de uso que recuerda mucho a macOS.

Este artículo se centra en explicar en detalle qué es AppManager, cómo funciona y por qué se ha convertido en uno de los gestores de AppImages más interesantes para escritorios GTK. También verás qué tecnologías utiliza por debajo, cómo maneja las actualizaciones de forma automática y por qué su interfaz con ventana de arrastrar y soltar es tan cómoda para el día a día. La idea es que, cuando termines de leer, tengas una visión muy clara de si esta utilidad encaja o no en tu forma de trabajar con Linux.

¿Qué es AppManager y para qué sirve?

AppManager es una aplicación de escritorio desarrollada con GTK y Libadwaita, escrita en el lenguaje de programación Vala, cuyo objetivo es gestionar AppImages de forma sencilla y visual. En lugar de tener que manejar tú mismo los archivos .AppImage, darles permisos, moverlos a una ruta concreta y crear accesos directos, AppManager automatiza todo ese proceso con un par de clics y un sistema muy intuitivo de arrastrar y soltar.

Su función principal es actuar como gestor centralizado de AppImages en el escritorio Linux: permite instalarlas, desinstalarlas, integrarlas con el menú de aplicaciones y mantenerlas al día mediante un sistema de actualización en segundo plano. De esta forma, los AppImages se comportan casi como si vinieran de un repositorio tradicional, pero sin renunciar a la portabilidad y aislamiento que caracteriza a este formato.

La herramienta está pensada especialmente para quienes usan entornos de escritorio basados en GTK, ya que su interfaz se integra muy bien en escritorios como GNOME, gracias a Libadwaita. Aun así, se puede usar en otros entornos sin mayor problema, siempre que tengas las dependencias necesarias.

Interfaz estilo macOS con arrastrar y soltar

Uno de los rasgos más llamativos de AppManager es su ventana de instalación al estilo macOS. Cuando haces doble clic sobre cualquier archivo con extensión .AppImage, en lugar de ejecutarse directamente la aplicación o abrirse un cuadro de diálogo genérico, se abre una ventana específica de AppManager en la que puedes arrastrar el archivo para instalarlo en tu sistema.

Esta ventana de arrastrar y soltar imita ese flujo típico de macOS en el que simplemente arrastras la app hacia una zona marcada para que quede instalada. Aquí ocurre algo similar: arrastras el AppImage a la interfaz de AppManager y la herramienta se encarga de mover el archivo a la ubicación adecuada, marcarlo como ejecutable, registrar las entradas de escritorio y copiar los iconos necesarios.

Gracias a este enfoque, instalar una AppImage se siente como un proceso limpio y coherente, no como manejar un archivo suelto que no sabes bien dónde colocar. Además, el estilo visual basado en GTK/Libadwaita da una sensación moderna y integrada con el propio sistema, alejada de las ventanas genéricas o poco pulidas que a veces se ven en herramientas más rudimentarias.

Soporte para AppImage SquashFS y DwarFS

AppManager no se limita a un único tipo de empaquetado, sino que ofrece compatibilidad con AppImage basadas en SquashFS y DwarFS. Estas dos tecnologías son sistemas de archivos comprimidos que se usan para empaquetar las aplicaciones dentro del AppImage, y cada una tiene sus particularidades en cuanto a rendimiento, tamaño y comportamiento; puedes consultarlo en nuestro glosario de Linux.

El soporte tanto de SquashFS como de DwarFS significa que puedes usar AppManager con un amplio abanico de AppImages, independientemente del método de empaquetado elegido por el desarrollador de la aplicación. No te tienes que preocupar de si una app concreta está construida con un sistema u otro: la herramienta se encarga de gestionarlo por debajo para que tú solo veas “funciona o no funciona”, y en la práctica, funcione casi todo.

Esta compatibilidad amplia es clave porque el ecosistema AppImage es muy variado y, sin un gestor que entienda los diferentes formatos, el usuario se vería obligado a manejar ciertas aplicaciones de forma manual, perdiendo la comodidad de unificar toda la gestión en una misma interfaz.

Instalación con un par de clics

En el flujo más habitual de uso, basta con hacer doble clic sobre un archivo .AppImage para que se abra la ventana especial de AppManager. Desde ahí, se muestra una interfaz preparada para que arrastres ese mismo archivo -o incluso otros- al área de instalación. Nada de comandos extraños ni rutas rebuscadas.

Una vez arrastras el archivo, AppManager se encarga de mover la AppImage a una ubicación fija en tu sistema, donde quedará almacenada como el resto de aplicaciones gestionadas por la herramienta. Así evitas tener la app perdida en la carpeta de Descargas o en cualquier ruta improvisada, algo muy común cuando se trabaja con AppImages de forma manual.

Este sistema tiene otra ventaja importante: permite que la desinstalación sea igual de limpia. Como AppManager sabe exactamente dónde ha colocado cada AppImage y qué ficheros de integración ha creado, eliminar la aplicación se reduce a un proceso controlado y sin restos, en lugar de andar borrando archivos a mano con el riesgo de dejar basura por el sistema.

Integración en el escritorio: entradas y iconos

Además de colocar las AppImages en la ruta adecuada, AppManager se ocupa de crear las entradas de escritorio necesarias. Esto significa que, una vez instalada la aplicación, la verás aparecer en el menú de aplicaciones de tu entorno de escritorio, igual que cualquier programa instalado desde el repositorio de tu distribución.

La herramienta también se encarga de copiar y registrar los iconos correspondientes, de manera que la app no solo sea accesible desde el lanzador, sino que además tenga su propio icono reconocible, tanto en el menú como en el dock o el panel, dependiendo del entorno que uses. De esa forma, visualmente no hay diferencia entre una AppImage gestionada por AppManager y una aplicación tradicional.

Esta integración es uno de los puntos donde más se nota el trabajo del desarrollador: el objetivo es que el usuario no tenga que pensar en “estoy usando AppImages”, sino simplemente en “estoy usando aplicaciones en mi sistema”. El formato pasa a ser un detalle técnico, mientras que la experiencia se mantiene coherente y cómoda.

Actualizaciones automáticas en segundo plano

Otro de los grandes puntos fuertes de AppManager es su sistema de auto-actualización en segundo plano. A diferencia de gestionar AppImages a mano, donde tienes que estar pendiente de descargar nuevas versiones manualmente, con esta herramienta el propio gestor puede ocuparse de actualizar las aplicaciones cuando detecta versiones más recientes compatibles.

Este proceso de actualización está pensado para que sea lo menos intrusivo posible. Se ejecuta en segundo plano, sin bloquear el uso del sistema ni obligarte a estar interactuando continuamente. Cuando las aplicaciones se actualizan, la idea es que tú prácticamente ni te enteres, salvo que consultes la versión o veas nuevas funciones en la propia app.

La presencia de un mecanismo de auto-actualización coloca a AppManager en una posición muy interesante dentro del ecosistema AppImage, ya que soluciona uno de los puntos tradicionalmente más débiles de este formato: la necesidad de que el usuario esté atento a cuándo salen versiones nuevas y se ocupe de sustituir manualmente el archivo antiguo.

Uso eficiente del ancho de banda con zsync

Para mejorar todavía más la experiencia de actualización, AppManager aprovecha las actualizaciones delta mediante zsync. Esta tecnología permite descargar únicamente las partes del archivo que han cambiado entre versiones, en lugar de volver a bajar el AppImage completo desde cero cada vez que hay una actualización.

En la práctica, esto se traduce en un ahorro notable de ancho de banda y tiempo, especialmente si trabajas con aplicaciones grandes o si tu conexión no es precisamente rápida. Al funcionar con “deltas”, las descargas suelen ser mucho más ligeras, haciendo que actualizar varias aplicaciones seguidas sea mucho más llevadero.

El uso de zsync también es beneficioso desde el punto de vista de la eficiencia general: reduce la carga en los servidores que alojan las AppImages y hace que el proceso de actualización sea más sostenible a largo plazo, algo que, aunque muchas veces no se menciona, también forma parte de una buena arquitectura de distribución de software.

Desinstalación sencilla y sin restos

Tan importante como instalar es poder desinstalar una aplicación sin dejar rastro. AppManager incluye funciones para eliminar las AppImages que ya no necesites, borrando tanto el archivo principal como las entradas de escritorio y los iconos asociados que se crearon durante la instalación.

Al manejar todo el ciclo de vida de cada AppImage, el gestor puede evitar que queden archivos huérfanos repartidos por el sistema. Esto es algo que muchas veces se pasa por alto cuando se gestionan AppImages de forma manual, pues es fácil borrar solo el archivo ejecutable y olvidarse de la integración que se había hecho con el escritorio.

El resultado es un sistema más ordenado, en el que sabes que las aplicaciones que aparecen en tu menú están realmente instaladas y en uso, y no son restos de intentos antiguos o pruebas que se quedaron mal desinstaladas.

Tecnologías usadas: GTK, Libadwaita y Vala

AppManager está construido sobre GTK y Libadwaita, dos piezas fundamentales en el ecosistema GNOME actual. Gracias a estas bibliotecas, la interfaz se integra perfectamente con los escritorios modernos basados en GTK, respetando temas, estilo visual y patrones de diseño recomendados.

El lenguaje de programación elegido para la herramienta es Vala, una opción muy habitual en proyectos que apuntan a una integración estrecha con el stack de GNOME. Vala permite escribir código conciso que, por debajo, se compila a C, ofreciendo un rendimiento sólido sin perder expresividad ni comodidad de desarrollo.

Gracias a esta combinación tecnológica, AppManager consigue un equilibrio interesante: rendimiento nativo, interfaz moderna y buen encaje en el entorno de escritorio. Para el usuario final, todo esto se traduce en una aplicación que se siente ligera, rápida y visualmente coherente con el resto del sistema.

Distribución como AppImage

Resulta bastante curioso y, a la vez, muy lógico que AppManager esté disponible él mismo como AppImage. Es decir, el gestor de AppImages se distribuye también en este formato, lo que facilita mucho su uso en distintas distribuciones de Linux sin necesidad de paquetes específicos para cada una.

Al ofrecerse como AppImage, puedes descargar el archivo desde su repositorio oficial y ejecutarlo prácticamente en cualquier distribución moderna, siempre que tenga las dependencias básicas necesarias para GTK y Libadwaita. Este enfoque refuerza la idea de que el propio gestor “predica con el ejemplo” utilizando el mismo formato que luego va a gestionar.

El lugar de referencia para obtener la aplicación es Github, donde el desarrollador publica las versiones de AppManager en forma de AppImage listas para descargar. Desde ahí puedes hacerte con la versión más reciente, probarla y, si te convence, integrarla completamente en tu flujo de trabajo con aplicaciones empaquetadas en este formato.

Privacidad y política de datos del desarrollador

El autor de AppManager es Mitchell Vermaning, responsable del desarrollo de esta utilidad. En el contexto de las plataformas de distribución de software, se indica que el desarrollador no ha proporcionado a Apple detalles sobre sus prácticas de privacidad y gestión de datos, algo relevante si se consulta información relacionada con el ecosistema de aplicaciones y las políticas de cada plataforma.

Si te preocupa cómo se manejan los datos y qué tipo de información puede recopilar o no el desarrollador, la recomendación es consultar directamente la política de privacidad oficial proporcionada por él mismo. Esa política es la que aclara qué datos se recogen, con qué fin y bajo qué condiciones, ofreciendo un marco más preciso que cualquier resumen externo.

En cualquier caso, al tratarse de una aplicación que se distribuye principalmente a través de Github como AppImage, los usuarios tienen control sobre la descarga y ejecución del programa en su propio entorno. Aun así, como con cualquier otra aplicación de escritorio, es buena práctica revisar la documentación y la política de privacidad asociada para tener un cuadro completo.

Ventajas frente a gestionar AppImages a mano

Manejar AppImages de forma manual implica, en general, descargar el archivo, hacerlo ejecutable, colocarlo en algún directorio y, si quieres una buena integración, crear un .desktop e iconos a mano. No es que sea imposible, pero es un proceso repetitivo y propenso a errores, sobre todo si gestionas muchas aplicaciones.

AppManager resuelve este problema proporcionando un flujo unificado para instalación, integración y actualización. Con la ventana de arrastrar y soltar estilo macOS, el usuario no tiene que recordar rutas ni comandos; todo se hace desde una interfaz gráfica pensada para ser intuitiva y rápida de usar.

Además, el soporte de actualizaciones automáticas con zsync y el control completo sobre la desinstalación hacen que las AppImages se comporten casi como paquetes gestionados por un gestor de software tradicional, pero manteniendo la independencia de cada aplicación. Esto es especialmente útil para quienes prefieren no depender al cien por cien de los repositorios de su distribución o quieren probar versiones más recientes de ciertos programas.

¿Para quién es especialmente interesante AppManager?

AppManager resulta especialmente atractivo para usuarios que usan AppImages de forma habitual en entornos basados en GTK y valoran tenerlo todo bien organizado. Si descargas a menudo aplicaciones en este formato, ya sea para probar software nuevo o porque prefieres no instalar paquetes del sistema, la herramienta te ahorra mucho tiempo y pequeños dolores de cabeza.

También es una buena opción para quienes buscan una experiencia visual cuidada, cercana a lo que ofrece macOS en su flujo de instalación, pero dentro del mundo Linux. El gesto de arrastrar y soltar para instalar, combinado con la integración automática en el menú de aplicaciones, hace que trabajar con AppImages se sienta mucho más natural.

Por último, si te preocupa tener tus aplicaciones actualizadas sin tener que revisarlas una a una, el mecanismo de auto-actualización con soporte para zsync es un punto muy a favor. Permite mantener varias herramientas al día con un coste mínimo, tanto en tiempo como en ancho de banda.

A la vista de todo lo que ofrece, AppManager consigue que el formato AppImage deje de ser “un archivo suelto” en tu carpeta de Descargas y pase a funcionar como parte integral de tu escritorio Linux, con instalación visual al estilo macOS, integración perfecta en el menú, actualizaciones automáticas y una gestión limpia de iconos y accesos directos, todo ello empaquetado en una aplicación moderna hecha con GTK, Libadwaita y Vala y distribuida como AppImage desde Github.

Si usas KDE o alguna distribución como Manjaro, openSUSE o Fedora con Plasma, tarde o temprano te habrás topado con KWrite y Kate en el menú de aplicaciones. A simple vista parecen casi lo mismo y, de hecho, mucha gente se pregunta por qué están los dos instalados, si son la misma app o si se puede borrar uno sin cargarse el otro.

La realidad es que KWrite y Kate son dos “hermanos” muy cercanos, que comparten casi todo el motor interno, pero están pensados para usos distintos: uno como editor ligero y sencillo, y el otro como entorno de edición avanzado para programación y proyectos grandes. Vamos a ver con calma qué los diferencia, qué comparten, de dónde vienen y cuándo te merece la pena usar cada uno.

Origen y relación entre KWrite y Kate

Desde hace unos veinte años, KWrite y Kate han ido siempre de la mano en el ecosistema KDE. Históricamente, KWrite fue el primero: un editor de texto de ventana única (SDI) que ya venía en las versiones tempranas de KDE como el típico bloc de notas “vitaminado”.

Con el tiempo, uno de los desarrolladores principales de KDE decidió crear Kate como variante de múltiples documentos (MDI), pensada para trabajar con varias pestañas, más paneles y funciones orientadas a programación. Es decir, Kate nació explícitamente como la versión más potente y multi-documento de KWrite.

Durante muchos años, ambos proyectos siguieron caminos de desarrollo algo separados. KWrite cambió poco: se mantenía como un editor simple, con mejoras puntuales y corrección de errores, pero sin volverse una “suite” enorme. Mientras, Kate fue recibiendo reimplementaciones de características como el sistema de pestañas, la gestión de sesiones, plugins avanzados, terminal integrada y soporte para proyectos.

Sin embargo, el núcleo de edición que usaban ambos es el mismo: la biblioteca KTextEditor del framework de KDE. Gracias a esto, tanto en KWrite como en Kate disfrutas de una experiencia de edición muy potente, muy por encima de un bloc de notas plano típico, incluso aunque visualmente KWrite parezca “básico”.

Un único código base: cuando Kate “se come” a KWrite

En los últimos años se tomó una decisión importante en el proyecto: evitar código duplicado y hacer que KWrite reutilice directamente la base de código de Kate, desactivando las funciones más avanzadas. Esta idea surgió cuando se quiso añadir pestañas a KWrite.

Un desarrollador (Waqar, muy activo en el proyecto) empezó a implementar soporte de pestañas en KWrite. El problema era que en el repositorio de Kate ya se habían reescrito las pestañas varias veces, tanto en el núcleo como mediante plugins, y no tenía sentido añadir otra implementación más que hubiera que mantener a largo plazo.

Para evitar esa duplicación, el equipo decidió que KWrite no tendría una base de código independiente, sino que utilizaría el mismo núcleo que Kate con un modo “recortado”. KWrite se construye ahora como una especie de Kate simplificado sin sesiones, sin plugins y con la interfaz más limpia. Técnicamente, lo que cambia entre uno y otro es principalmente la función principal (main) y algunas comprobaciones en el código compartido para activar o ocultar partes de la interfaz.

Gracias a este cambio, se eliminaron alrededor de mil líneas de código específicas de KWrite y solo hubo que añadir unas pocas líneas al código común. El resultado es que ambos editores comparten prácticamente toda la lógica, incluyendo el sistema de pestañas moderno, el análisis de parámetros de línea de comandos y el comportamiento básico de edición.

Eso sí, aunque hayan unificado la base interna, KWrite sigue teniendo su propia personalidad: no comparte instancias entre ventanas, no tiene gestión de sesiones, no carga plugins avanzados, no ofrece terminal integrada ni lenguaje de servidor (LSP), entre otras cosas. Si quieres esas funciones, te toca irte a Kate.

KTextEditor: el motor común de edición

Tanto KWrite como Kate se apoyan en la misma biblioteca de edición, KTextEditor, parte del marco de trabajo de KDE. Esta librería es la que proporciona casi toda la “magia” de edición potente que ves en ambos programas, y además es usada también por otras aplicaciones como KDevelop u otros IDEs de KDE.

Esto significa que la experiencia pura de escribir, seleccionar, resaltar y manipular texto es prácticamente idéntica entre KWrite y Kate. Si te acostumbras a uno, no te costará nada usar el otro o incluso KDevelop, porque el comportamiento de la zona de texto es coherente en toda la familia.

Gracias a KTextEditor, ambos editores cuentan con resaltado de sintaxis para infinidad de lenguajes, análisis de modos específicos (por ejemplo, soporte para Markdown, HTML, Python, C, etc.), herramientas de edición como sangrado automático, numeración de líneas, minivista del documento y otras funciones que van bastante más allá de un editor plano.

Instalación y distribución en diferentes sistemas

En general, si usas KDE Plasma, lo más normal es que ya tengas KWrite instalado por defecto. Kate, en cambio, puede que tengas que instalarlo a mano, según la distribución.

En sistemas basados en RPM como Fedora, es tan simple como ejecutar algo del estilo sudo dnf install kwrite kate. En otras distros, los paquetes se llaman igual o muy parecido. Además, ambos se publican de forma independiente: KWrite está disponible en apps.kde.org/kwrite y Kate en apps.kde.org/kate.

En el ecosistema KDE, puedes instalarlos desde Discover dentro del propio escritorio, y KWrite también se distribuye como Flatpak para entornos donde prefieras este tipo de paquetes autocontenidos. En Manjaro, por ejemplo, los verás en Pamac como programas separados, aunque compartan código fuente y dependencias en buena parte.

Un detalle importante es que no dependen el uno del otro como paquetes. Es decir, puedes tener solo KWrite, solo Kate o los dos a la vez sin que se molesten entre sí, sin que se mezclen configuraciones y sin conflictos de dependencias directas. Funcionan como “gemelos bien educados”.

KWrite: editor ligero pero nada cutre

Si abres KWrite esperando algo tipo bloc de notas limitadísimo, te vas a llevar una sorpresa, porque es un editor ligero pero con bastantes prestaciones avanzadas. Puedes lanzarlo desde el menú de aplicaciones y ponerte a escribir tal cual, guardando textos sueltos, notas, pequeños scripts, etc.

Entre las funciones que se le atribuyen tradicionalmente, están la exportación a HTML, el bloqueo del modo de selección, el seguimiento de código y los marcadores. Todo ello lo hace muy útil tanto para tomar notas como para editar código de manera informal. También ofrece autocompletado de palabras y otras ayudas a la escritura.

Dispone de resaltado de sintaxis configurable para múltiples lenguajes, selección del modo de fin de línea (Unix, Windows, Macintosh) y la posibilidad de elegir la codificación de texto. Es cierto que no siempre detecta automáticamente la codificación del fichero, ya que suele seguir la predeterminada del sistema al abrir archivos, pero puedes cambiarla manualmente si lo necesitas.

Otra característica interesante es que permite trabajar con archivos remotos a través de protocolos como FTP o fish, integrándose con la infraestructura de red de KDE. Esto facilita editar ficheros que están en servidores sin necesidad de montar complicadas soluciones externas.

KWrite también incluye la opción de usar diferentes componentes gracias a la tecnología KParts (en versiones antiguas esto fue una novedad importante). Eso permitía incrustar, por ejemplo, una consola Konsole dentro del editor u otros componentes. Más adelante se adoptó como editor de texto por defecto el motor de Kate, consolidando esa integración.

En el contexto histórico de KDE, KWrite formaba parte del paquete kdebase y, más recientemente, se distribuye junto a Kate, con su código en un subdirectorio específico del repositorio. Todo ello refuerza la idea de que no es un proyecto totalmente separado, sino una cara distinta de la misma base tecnológica.

Funciones compartidas: marcadores, resaltado y más

Al estar basados en KTextEditor, tanto KWrite como Kate comparten algunas herramientas que marcan bastante la diferencia frente a editores muy básicos. Por ejemplo, puedes usar marcadores temporales para moverte rápido por el documento.

Con un simple atajo de teclado, como Ctrl+B para crear un marcador, puedes luego saltar a ellos desde el menú de marcadores. No se guardan dentro del archivo (no modifican el contenido real), pero mientras trabajas son una forma elegante de marcar secciones importantes. Más práctico que dejar palabras “chorra” como foobar en el texto y buscar luego, que al final siempre se puede olvidar borrar.

Otra función clave es el resaltado de sintaxis y los modos de documento. Desde el menú de herramientas puedes activar la revisión ortográfica automática, que marca errores con subrayados, y elegir modos específicos para formatos concretos: Markdown, HTML, Python, C/C++, etc. Cada modo aplica un esquema de resaltado distinto para ayudarte a leer y entender mejor el contenido.

Si quieres hilar más fino, puedes elegir directamente el tipo de resaltado independientemente del modo, por si quieres forzar un esquema visual concreto. Este tipo de flexibilidad hace que el mismo editor te sirva tanto para redactar texto plano como para depurar rápidamente un fragmento de código.

Además, muchos usuarios aprecian especialmente la vista general del documento en el lateral derecho, una especie de miniatura muy vertical de todo el texto. Aunque parezca pequeña, es sorprendentemente útil para localizar secciones, títulos o trozos de código y saltar con un solo clic a la zona aproximada.

Qué ofrece Kate por encima de KWrite

La gran pregunta es: si la edición de texto “pura y dura” es casi la misma, ¿por qué pasar de KWrite a Kate? La respuesta está en todo lo que rodea al texto cuando trabajas como programador o con proyectos complejos: paneles, plugins, sesiones y terminal.

Kate añade una barra lateral donde puedes ver el sistema de ficheros o un directorio de proyecto. Además, maneja el concepto de “proyecto”, de modo que puede relacionar archivos entre sí (por ejemplo, un .cpp con su .h, o varios ficheros de configuración de un mismo módulo) y ofrecerte navegación más inteligente entre ellos.

Incluye también una terminal integrada que se despliega con una tecla (normalmente F4), lo que te permite ejecutar comandos, compilar, lanzar scripts o usar herramientas de consola sin salir del propio editor. Incluso puedes mandar el contenido del documento a la terminal de forma directa, lo que, para desarrollo y scripting, ahorra bastante tiempo.

Otro plus es la gestión de sesiones. Kate puede guardar diferentes configuraciones de ventanas, pestañas, proyectos abiertos y preferencias, de modo que tengas perfiles distintos para cada tipo de trabajo (por ejemplo, un entorno para C++, otro para edición web, otro para notas de documentación, etc.).

Además, Kate admite una amplia variedad de plugins que añaden funcionalidades avanzadas: integración con servidores de lenguaje (LSP) para autocompletado inteligente, análisis estático, terminales mejoradas, depuración, herramientas específicas para lenguajes concretos, y un largo etcétera. Este ecosistema de extensiones es lo que, en la práctica, convierte a Kate en una especie de mini-IDE para muchos desarrolladores.

Por todo esto, muchos usuarios describen Kate como una herramienta muy completa para programadores, mientras que KWrite se ve como el editor “limpio” para tareas rápidas o simples, aunque siga teniendo opciones potentes bajo el capó.

Diferencias prácticas en la interfaz y el comportamiento

Cuando comparas las dos ventanas lado a lado, te das cuenta de que la interfaz de KWrite y la de Kate son casi idénticas en los elementos que comparten: barra de herramientas, área de texto, minivista lateral, menús básicos… La diferencia principal viene de los paneles y vistas adicionales.

En KWrite no verás las vistas de herramientas laterales que sí aparecen en Kate para explorador de proyectos, terminal acoplada y otros paneles derivados de plugins. También cambia la configuración por defecto del toolbar y de la barra de URL (ruta del archivo), que pueden venir activadas o desactivadas según el modo.

A nivel de comportamiento, KWrite no comparte instancias ni sesiones. Cada vez que lo abres, es como un editor independiente y no se mete en historias de gestión avanzada de sesiones. Tampoco carga plugins complejos, por lo que no tendrás algunas de las funciones “fancy” que sí ofrece Kate.

En ambos puedes usar pestañas con un comportamiento muy parecido: abrir múltiples documentos, hacer apertura rápida, dividir la vista en paneles, etc. Esta es una mejora importante respecto al KWrite de hace 20 años, que era de ventana única estricta. Hoy en día, gracias a compartir código con Kate, KWrite puede tener pestañas sin arrastrar consigo todo el peso del resto de características.

Uso real: de la edición ligera al desarrollo profesional

Entre los usuarios de KDE hay opiniones bastante claras sobre cuándo tiene sentido usar KWrite, Kate o incluso KDevelop. En general, se suele ver KWrite como el más liviano, KDevelop como el más pesado orientado a grandes proyectos y Kate en un punto intermedio, ideal para el día a día del programador que no necesita un mega-IDE.

Mucha gente nueva en KDE pregunta cuál elegir, y la respuesta habitual es algo así: si solo quieres editar texto, tomar notas, tocar algún script o archivo de configuración, KWrite va sobrado. Si programas de forma habitual, manejas muchos ficheros y aprecias cosas como proyectos, terminal integrada y sesiones, entonces Kate encaja mucho mejor.

Hay incluso usuarios que, aun sin usar KDE como escritorio principal, siguen tirando de KWrite porque les gusta su equilibrio entre sencillez y potencia. Un ejemplo típico es alguien en XFCE que mantiene algunas aplicaciones KDE como Krusader o KWrite porque les resultan imprescindibles, y ajusta las dependencias para evitar lo que considera “bloat” (componentes como kactivities, knewstuff o kuserfeedback si no les saca partido).

También se ven casos de personas que intentan buscar alternativas no-KDE a KWrite (como ciertos editores para GTK o Qt independientes) y, al probarlas, echan en falta detalles clave como el modo de edición en bloque (selección vertical parcial de líneas) o un comportamiento robusto al comentar múltiples líneas. Mientras no encuentran un sustituto que cumpla con todas esas funciones, terminan quedándose con KWrite como herramienta principal.

Otros editores en el entorno KDE: KDevelop y KEdit

Dentro del ecosistema KDE no todo es KWrite y Kate; hay otras aplicaciones relacionadas con la edición de texto y el desarrollo, como KDevelop o el veterano KEdit.

KDevelop es un IDE completo, mucho más pesado, pensado ya para proyectos grandes, refactorizaciones complejas, depuración integrada, asistentes y un largo catálogo de herramientas. Aprovecha también KTextEditor como motor de edición, por lo que la sensación de escribir es familiar si vienes de Kate o KWrite, pero a nivel de interfaz y requisitos de recursos juega en otra liga.

KEdit, por su parte, sigue existiendo en algunos entornos como editor alternativo. Una de sus particularidades históricas es el soporte para texto bidireccional, algo relevante para idiomas escritos de derecha a izquierda. Formaba parte en su día del paquete kdeaddons y servía un nicho concreto en cuanto a tipología de texto.

En cualquier caso, el usuario medio de KDE hoy en día se mueve sobre todo entre KWrite como editor ligero, Kate como entorno de edición avanzado y, cuando necesita aún más, KDevelop como IDE especializado.

Licencia, tecnología y mantenimiento

A nivel técnico, KWrite (y por extensión Kate) está escrito en C++ usando Qt para la interfaz y distribuido bajo licencia LGPL. Esto lo convierte en software libre, integrable en otros proyectos y mantenido por un equipo de desarrolladores bastante amplio dentro de la comunidad KDE.

Sus repositorios de código están alojados en la infraestructura de KDE y con espejos en plataformas como GitHub, tanto para el propio editor como para los frameworks subyacentes: KTextEditor y KSyntaxHighlighting, entre otros. También existen sistemas de seguimiento de bugs donde se pueden reportar errores y hacer seguimiento de su resolución.

El equipo anima de forma constante a que nuevos colaboradores se sumen al desarrollo, ya sea para añadir funciones, pulir detalles o mejorar el rendimiento. El hecho de que KWrite y Kate compartan ahora casi todo el código hace que cada corrección o mejora repercuta automáticamente en ambos editores, reduciendo esfuerzo duplicado y aumentando la calidad general.

En la práctica, esto se traduce en que cada pequeña mejora que entra en el repositorio beneficia a todo el ecosistema de editores KDE, no solo a Kate y KWrite, sino también a las aplicaciones que usan sus frameworks, reforzando su papel como referencia dentro del escritorio Plasma.

Mirando el conjunto, para un usuario final de KDE es difícil encontrar hoy un equilibrio mejor entre un editor ligero pero potente como KWrite y una herramienta de desarrollo versátil como Kate, más aún sabiendo que ambos se mantienen en paralelo, comparten la misma base, no entran en conflicto entre sí y cubren desde el uso más simple de bloc de notas hasta flujos de trabajo muy exigentes en programación.

La llegada de Mesa 25.3.5 supone el último coletazo importante de la rama 25.3 antes de que la esperada serie 26.0 tome el relevo como nueva versión estable del stack gráfico. Aunque pueda parecer una actualización menor, estamos ante un punto de mantenimiento muy pulido que concentra un buen puñado de correcciones críticas pensadas para dar estabilidad máxima a quienes prefieren no vivir al filo de la navaja con las versiones más recientes.

Esta versión se centra en arreglar fallos, mejorar la fiabilidad de los drivers Vulkan (tanto en AMD como en Intel y Qualcomm), pulir aspectos de Vulkan Video, y añadir pequeñas correcciones en drivers más veteranos como R600. Además, se publica en un momento clave dentro del calendario de lanzamientos de Mesa, con un histórico de versiones muy activo que va encadenando ramas 23.x, 24.x y 25.x, y ya con las primeras candidatas de Mesa 26 rodando por ahí. Muchos de estos cambios remiten a nuevos drivers y ajustes en ramas previas que han ido allanando el camino.

Novedades clave de Mesa 25.3.5

La base de Mesa 25.3.5 está centrada en la estabilidad, pero eso no quiere decir que sea una actualización irrelevante. Entre las mejoras más notables están las relacionadas con Vulkan Video en los drivers RADV (AMD) e Intel ANV, así como múltiples arreglos de bugs distribuidos por varios drivers, incluyendo R600, TURNIP (Qualcomm Adreno) y NVK. En particular se recogen arreglos clave en RADV y soporte mejorado en códecs.

Tal y como detallan las notas y los anuncios de terceros, esta versión incorpora un «wide assortment of different fixes» para los drivers Vulkan de Intel y AMD, así como algún retoque para hardware Radeon antiguo. A ello se suman ajustes concretos en la forma de calcular tamaños de tiles para el códec de vídeo en RADV, correcciones de parámetros específicos como maxActiveReferencePictures en decodificación H.264 y una decisión bastante conservadora por parte del driver Intel ANV en lo referente a la codificación de vídeo con Vulkan; de hecho, al igual que en versiones previas como Mesa 25.2.6, se observa la tendencia a priorizar la estabilidad sobre la exposición temprana de funciones.

El resultado global es una versión que apunta de forma directa a quienes necesitan un entorno gráfico lo más estable posible, tanto en equipos de escritorio como en portátiles con GPU integrada, o en dispositivos que tiran de Qualcomm Adreno. Si vienes de 25.3.4 o anteriores dentro de la misma rama, tiene todo el sentido del mundo actualizar.

Cambios en RADV y Vulkan Video (AMD)

Una de las áreas más trabajadas en Mesa 25.3.5 es el soporte de Vulkan Video sobre RADV, el driver Vulkan para GPUs AMD dentro de Mesa. El texto original del anuncio comenta que ahora se utiliza un método «more reliable» para calcular los tamaños de tile, algo que resulta crucial para garantizar que la decodificación de vídeo funcione sin artefactos ni bloqueos extraños.

Este cambio responde a problemas detectados en el cálculo previo de esos tiles, que podían provocar errores en la reproducción de vídeo acelerada por GPU en determinadas combinaciones de hardware y códec. Al pasarse a un esquema más robusto de cálculo, se minimizan los riesgos de lecturas fuera de rango, corrupción de memoria o fallos sutiles que luego se traducen en glitches en el vídeo.

Además, se menciona de forma específica una corrección relacionada con maxActiveReferencePictures en la decodificación H.264 dentro del código de Vulkan Video de RADV. En códecs como H.264, la cantidad de imágenes de referencia simultáneamente activas es un parámetro clave para el correcto funcionamiento de la decodificación: si se gestiona mal, puede haber frames perdidos, tirones o incluso cuelgues del proceso.

Con estos ajustes, Mesa 25.3.5 apunta de manera directa a mejorar la experiencia de quienes utilizan Linux como plataforma multimedia y confían en la aceleración por GPU para reproducir contenidos H.264. No es un cambio vistoso a nivel de interfaz, pero sí muy importante de cara a la estabilidad en el día a día.

Intel ANV y la desactivación de la codificación de vídeo

En el lado de Intel, las notas destacan un movimiento llamativo: el driver Intel ANV deshabilita la codificación de vídeo vía Vulkan Video para las generaciones de hardware más recientes, al menos de forma temporal. Concretamente, se habla de Meteor Lake, las GPUs discretas Alchemist (Arc) y hardware aún más nuevo.

El motivo principal es que la implementación de Vulkan Video encode no ha sido suficientemente probada en esas plataformas. En lugar de exponer una funcionalidad potencialmente inestable a los usuarios, el equipo de Mesa ha optado por ocultarla hasta que esté mejor testeada y pulida. Es una decisión conservadora, pero muy sensata si lo que se busca es dar confianza a los administradores de sistemas y a usuarios avanzados; recuerde que recientemente se discutieron cambios relacionados con un parche muy importante para el driver Intel que también priorizaba la fiabilidad.

Esto quiere decir que, si tienes un portátil o sobremesa con Intel Meteor Lake o una GPU Arc y dependes de Mesa, en la versión 25.3.5 no verás disponible la parte de encode de Vulkan Video, aunque sí podrás aprovechar el resto de capacidades del driver ANV. Esta medida no afecta a la decodificación ni al uso «normal» de Vulkan para juegos y aplicaciones 3D.

Más allá de esta desactivación, también se integran varias correcciones de bugs en el driver ANV que no se detallan una a una en el resumen, pero que forman parte de ese «variety of other random bug fixes» mencionado. En la práctica, podemos esperar una mejora en estabilidad y en el cumplimiento estricto de la especificación Vulkan, lo que reduce el riesgo de crashes en juegos punteros o en benchmarks exigentes.

Mejoras generales en los drivers RADV y ANV

Además de los cambios concretos en Vulkan Video, el lanzamiento de Mesa 25.3.5 incluye un buen puñado de arreglos generales en los drivers Vulkan de AMD (RADV) e Intel (ANV). El anuncio habla de «a variety of other random bug fixes», que normalmente cubren desde pequeños fallos de validación hasta correcciones de regresiones introducidas en versiones anteriores.

En RADV, este tipo de correcciones suelen tener que ver con títulos concretos de juegos o aplicaciones que exhiben comportamientos raros (cuelgues, errores visuales, problemas de sincronización, etc.). Muchas veces, estas correcciones se documentan como patches específicos para algunos motores gráficos o para ciertas extensiones de Vulkan utilizadas de forma intensiva en juegos AAA.

En ANV, el enfoque es similar: reforzar el cumplimiento con la especificación Vulkan y garantizar que las optimizaciones de rendimiento no rompan nada. Es frecuente ver parches que evitan contentions de memoria, ajustes en el manejo de pipelines gráficos complejos o pequeñas optimizaciones que reducen el overhead del driver en determinadas situaciones.

La suma de todas estas pequeñas piezas convierte a 25.3.5 en una actualización clave para cualquier usuario que juegue en Linux con GPU AMD o Intel modernas, incluso aunque no le preocupe especialmente la parte de vídeo. A menudo, una simple corrección de sincronización puede marcar la diferencia entre un juego perfectamente estable y un infierno de cuelgues esporádicos.

Soporte para hardware antiguo: driver R600

Aunque buena parte del foco mediático cae sobre Vulkan y los GPUs actuales, esta versión también dedica atención a un viejo conocido: el driver R600 de Gallium3D. Este driver cubre las antiguas tarjetas AMD/ATI Radeon HD 2000 hasta HD 6000, hardware que sigue presente en muchos equipos reciclados, PCs secundarios o estaciones de trabajo veteranas.

Las notas indican que Mesa 25.3.5 integra «a few fixes» para ese driver, lo que significa que se siguen corrigiendo problemas puntuales incluso en hardware de hace más de una década. Esto refleja bastante bien la filosofía de Mesa: no abandonar del todo a los usuarios de GPUs antiguas, aunque evidentemente el grueso del desarrollo se centre en hardware moderno y en APIs como Vulkan.

En la práctica, estos arreglos pueden suponer que una distro reciente con Mesa actualizado continúe dando bajo nivel de incidencias en equipos con tarjetas Radeon HD antiguas, ya sea para tareas de escritorio, reproducción de vídeo o incluso juegos ligeros. No es un salto revolucionario, pero se agradece que la compatibilidad no se rompa de un día para otro.

TURNIP (Qualcomm Adreno), NVK y otros drivers

Mesa 25.3.5 también trae novedades para el ecosistema móvil y para el soporte de GPUs NVIDIA a través de drivers open source. En concreto, se mencionan varias correcciones en el driver TURNIP, responsable del soporte Vulkan para GPUs Qualcomm Adreno, muy habituales en teléfonos y algunos dispositivos ARM.

Este tipo de actualizaciones apuntan sobre todo a mejorar la estabilidad en sistemas basados en SoCs Qualcomm, que pueden estar ejecutando Linux convencional, Android u otras variantes. TURNIP ha ganado peso en los últimos años como alternativa open source potente para Vulkan en móviles, y cada bug corregido ayuda a que la experiencia sea menos dependiente de drivers propietarios.

Por otro lado, se habla de «a few NVK fixes», es decir, unos cuantos ajustes en NVK, el driver Vulkan open source para GPU NVIDIA dentro de Mesa que todavía se considera relativamente joven y en constante evolución. Estos arreglos suelen ir en la línea de mejorar compatibilidad con juegos y benchmarks, así como de cubrir huecos en la implementación de la API.

En conjunto, estas correcciones en TURNIP, NVK y otros drivers menores redondean el lanzamiento para que Mesa 25.3.5 no sea solo una actualización centrada en PC clásico, sino también en dispositivos ARM, portátiles ligeros y otras plataformas donde el soporte gráfico abierto es especialmente crítico.

Mesa 25.3.5 como parte de un ecosistema en movimiento

El lanzamiento de Mesa 25.3.5 no llega solo, sino acompañado y mencionado en contextos más amplios del ecosistema Linux. Algunas recopilaciones de noticias, como los resúmenes semanales tipo «Weekly Roundup» de medios especializados, suelen agruparlo junto a lanzamientos de otros proyectos clave como GParted, Transmission, GStreamer, OpenSSL, Proton, VirtualBox, Calibre, Tails, Linux Lite, Shotcut o TigerVNC.

Que Mesa aparezca en estas listas refleja su enorme importancia dentro del stack gráfico de Linux: casi cualquier distro moderna se apoya en sus drivers y en su implementación de OpenGL/Vulkan para acelerar escritorio, juegos y multimedia. Un simple «bug fix release» de Mesa puede tener un impacto mucho mayor que nuevas características de proyectos más pequeños.

Como complemento, el entorno de comunicación alrededor de Mesa incluye noticias breves en la web oficial, listas de correo para los anuncios de lanzamiento y actividad en redes sociales donde a veces se difunden las novedades. Si JavaScript está desactivado en el navegador, algunas de estas plataformas incluso te avisan de que actives JS o uses un navegador compatible, lo que deja ver la importancia que tiene hoy la web dinámica incluso en proyectos tan técnicos.

Por qué actualizar a Mesa 25.3.5

Si ya estás en la rama 25.3 de Mesa, la respuesta rápida es que tiene todo el sentido del mundo actualizar. Esta versión no rompe compatibilidades, no introduce cambios drásticos en APIs y se limita a corregir fallos, reducir riesgos y afinar comportamientos en drivers clave.

Quienes utilizan GPUs AMD con RADV se benefician de mejoras concretas en Vulkan Video y de correcciones generales que afectan tanto a juegos como a aplicaciones 3D. Los usuarios de Intel con ANV ven cómo se prioriza su estabilidad, aunque eso suponga renunciar temporalmente a la codificación de vídeo Vulkan en las plataformas más nuevas, hasta que esté todo más que probado.

Los propietarios de hardware antiguo Radeon HD 2000-6000 siguen recibiendo pequeños mimos a través del driver R600, mientras que los dispositivos con Qualcomm Adreno y las GPUs NVIDIA que tiran de NVK también notan un entorno un poco más robusto. El conjunto hace de 25.3.5 una actualización muy recomendable en casi cualquier escenario.

Además, teniendo en cuenta que Mesa 26.0 está a la vuelta de la esquina, mantenerse al día dentro de la rama 25.3 ayuda a que el salto a la próxima serie estable sea mucho más suave y predecible, sin arrastrar bugs viejos que ya están resueltos en el último punto de mantenimiento.

Con todo lo anterior sobre la mesa, se puede decir que Mesa 25.3.5 cierra con buen sabor de boca la etapa final de la rama 25.3: consolida el soporte para Vulkan Video en AMD, adopta una postura prudente con la codificación en Intel ANV, cuida a los usuarios de hardware antiguo mediante R600 y continúa puliendo drivers como TURNIP y NVK, todo ello enmarcado en un ciclo de lanzamientos frenético que prepara el terreno para Mesa 26.0 sin descuidar, ni un momento, la estabilidad del presente.

Semana productiva en GNOME, o al menos esa sensación me he llevado yo al echarle un vistazo a la nota sobre novedades de esta semana. Para ser honesto, gran parte de mi atención e interés se la ha llevado una aplicación de nombre AppManager, una app que quedará perfectamente en GNOME y ayudará a gestionar AppImages. Como siempre en lo relacionado en este proyecto, es una aplicación intuitiva que sin lugar a dudas probaré.

Lo que sigue es la lista de novedades que han adelantado esta semana, la que ha ido del 30 de enero al 6 de febrero.

Esta semana en GNOME

• Se ha publicado Glycin 2.1.beta. A partir de esta versión, el formato de imagen JPEG 2000 es compatible por defecto. Esto ha sido posible gracias a una nueva implementación de JPEG 2000 completamente escrita en Rust seguro. Aunque este formato de imagen no se usa mucho directamente, muchos PDF contienen imágenes JPEG 2000 desde PDF 1.5 y PDF/A-2, que admiten imágenes JPEG 2000 incrustadas. Por tanto, las imágenes extraídas de PDF con frecuencia tienen formato JPEG 2000.
• Se ha publicado Resources 1.10 con compatibilidad para nuevo hardware, software y mejoras generales. Algunos aspectos destacados:
  • Compatibilidad añadida para NPUs de AMD usando el controlador amdxdna.
  • Mejoras de accesibilidad para usuarios de lectores de pantalla y teclado.
  • Detección de aplicaciones ampliamente mejorada.
  • Reducción significativa del uso de CPU.
  • Ahora es posible buscar varios nombres de proceso a la vez usando el operador “|” en el campo de búsqueda.
• Se ha añadido otro capítulo al libro de gtk4-rs. Describe cómo usar gettext para hacer que una aplicación esté disponible en otros idiomas.
• Se ha publicado Sitra, una aplicación para instalar y gestionar fuentes de Google Fonts. También ayuda a integrar fuentes en proyectos usando fontsource npm y CDN. La aplicación sustituye a Font Downloader, que llevaba tiempo abandonada.

• AppManager es una utilidad de escritorio desarrollada con GTK/Libadwaita en Vala que facilita instalar y desinstalar AppImages en el escritorio Linux. Es compatible con formatos AppImage SquashFS y DwarFS, incluye un proceso de actualización automática en segundo plano y usa actualizaciones delta con zsync para optimizar el uso de ancho de banda. Al hacer doble clic en cualquier archivo .AppImage se abre una ventana de arrastrar y soltar al estilo macOS; basta con arrastrar para instalar y AppManager mueve la aplicación, crea las entradas de escritorio y copia los iconos.

• Se ha publicado Parabolic V2026.2.0. Registro de cambios:
  • Parabolic ha sido reescrito en C# desde C++.
  • Compatibilidad añadida para arm64 en Windows.
  • Compatibilidad añadida para opciones de calidad en listas de reproducción.
  • Compatibilidad añadida para opciones de subtítulos en listas de reproducción.
  • Compatibilidad añadida para invertir el orden de descarga de una lista de reproducción.
  • Compatibilidad añadida para recordar la selección previa de descarga inmediata en el diálogo de añadir descarga.
  • Compatibilidad añadida para mostrar las pausas de espera de yt-dlp dentro de las filas de descarga.
  • Compatibilidad añadida para habilitar actualizaciones nocturnas de yt-dlp dentro de Parabolic.
  • Rediseño de las aplicaciones en ambas plataformas para una experiencia de descarga más rápida y fluida.
  • Eliminadas las páginas de documentación, ya que Parabolic muestra documentación integrada cuando es necesario.
  • Corregido un problema por el que los créditos de traducción no se mostraban correctamente.
  • Corregido un problema por el que Parabolic se bloqueaba al añadir grandes cantidades de descargas desde una lista de reproducción.
  • Corregido un problema por el que Parabolic se bloqueaba al validar ciertas URL.
  • Corregido un problema por el que Parabolic se negaba a iniciarse debido a errores del llavero.
  • Corregido un problema por el que Parabolic se negaba a iniciarse debido a errores de VC.
  • Corregido un problema por el que Parabolic se negaba a iniciarse debido a errores de versión.
  • Corregido un problema por el que abrir el diálogo «Acerca de» congelaba Parabolic durante unos segundos.
  • Actualizado el yt-dlp incluido.
• Se ha publicado Pigeon Email Notifier, una nueva extensión de GNOME Shell para notificaciones de Gmail y correo de Microsoft mediante GNOME Online Accounts. Incluye modo solo prioridad y notificaciones persistentes y sonoras.

• Se ha publicado PyGObject 3.55.3, la tercera versión de desarrollo del ciclo actual de GNOME. Principales avances de este ciclo, que conduce a GNOME 50:
  • Compatibilidad con los métodos do_dispose y do_constructed en clases Python. do_constructed se llama después de construir un objeto y do_dispose cuando un GObject se libera.
  • Eliminación de código de marshalling duplicado para campos, propiedades, constantes y cierres de señales.
  • Eliminación de código antiguo, especialmente pygtkcompat y los envoltorios de Glib.OptionContext y OptionGroup.
  • Internamente, las referencias conmutables han sido sustituidas por referencias normales y PyGObject gestiona automáticamente los objetos «flotantes».

Y esto ha sido todo esta semana en GNOME.

Imágenes y contenido: TWIG.

Para mí, MPV es el mejor reproductor de vídeo que existe. Empecé a probarlo más cansado de esperar el lanzamiento de VLC 4.0, y no me arrepiento. Bueno, casi nunca me arrepiento, porque no siempre es fácil de usar. Por ejemplo, activar la reproducción en bucle de listas no es algo sencillo, pero siempre existe una vía porque es muy configurable. Una cosa que no me gusta de MPV es cómo abre algunos vídeos, algo que se puede solucionar tirando de scripts.

Pongamos un ejemplo: te bajas un vídeo de YouTube on yt-dlp, y ese vídeo es de una resolución más alta que la de tu pantalla. O justo la misma resolución. Si tiene la misma resolución o más, se abrirá con la barra superior en su sitio, lo que hará que el ancho esté bien, pero el vídeo sobresalga por debajo. Esto se puede solucionar con un script.

En comparación con el comportamiento de VLC, el reproductor de VideLAN suele abrirse con menús y controles en la misma ventana, por lo que nada sobresale de la pantalla. Lo que vamos a explicar aquí es cómo usar un script en MPV para que el vídeo se abra a su tamaño normal si es menor que el de nuestra pantalla o a pantalla completa si es igual o superior.

Abre los vídeos de MPV a pantalla completa según convenga

Los pasos a seguir son sencillos, aunque no lo es tanto el contenido:

1. Abrimos un editor de textos y creamos el archivo ~/.config/mpv/scripts/fullscreen-if-big.lua. El nombre puede ser otro, pero la extensión tiene que ser .lua y estar dentro de la carpeta scripts de la carpeta de configuración de MPV.
2. Dentro pegamos lo siguiente:

local mp = require 'mp'

mp.register_event("file-loaded", function()
    local w = mp.get_property_number("width")
    local h = mp.get_property_number("height")
    local dw = mp.get_property_number("display-width")
    local dh = mp.get_property_number("display-height")

    if w and h and dw and dh then
        if w >= dw or h >= dh then
            mp.set_property("fullscreen", "yes")
        end
    end
end)

Guardamos y eso sería todo. Lo que hará MPV al iniciar un vídeo será analizar el tamaño del vídeo, el tamaño de la pantalla y, en caso de ser igual o mayor que la pantalla, lo abrirá a pantalla completa. Eliminará la barra superior, pero no sobresalrá de ninguna manera, lo que a mí me parece útil.

También se puede hacer que MPV se abra siempre a pantalla completa, pero si el vídeo reproducido es muy pequeño, al ampliarlo se verá borroso.

El lanzamiento de Ardour 9.0 marca un punto de inflexión para quienes buscan una estación de trabajo de audio digital de código abierto capaz de competir con soluciones comerciales. Esta versión mayor introduce un conjunto amplio de novedades que afectan tanto al flujo de trabajo MIDI como a la grabación de audio, la automatización y la interfaz gráfica.

Para usuarios que trabajan en producción musical, podcasting, postproducción o desarrollo de herramientas de audio, esta actualización supone una opción más seria frente a DAW de pago como Pro Tools, Logic Pro o Ableton Live. La combinación de nuevas funciones creativas y mejoras de rendimiento, junto a la ausencia de suscripciones, coloca a Ardour 9.0 en una posición especialmente interesante para estudios pequeños, freelance y proyectos educativos.

Ardour 9.0: un DAW open source más maduro y orientado a producción profesional

Con Ardour 9.0 el proyecto refuerza su perfil como DAW de alto nivel dentro del ecosistema de software libre. La hoja de ruta de esta versión se ha centrado en resolver demandas históricas de la comunidad: una edición MIDI más cómoda, mayor flexibilidad para trabajar con clips y loops, procesamiento más granular de regiones y una interfaz más fluida.

El lanzamiento se acompaña de binarios listos para usar en Linux, Windows y macOS, además del código fuente, algo clave en el entorno donde muchas escuelas, radios comunitarias y estudios pequeños basan sus sistemas en distribuciones GNU/Linux. En la mayoría de distribuciones, Ardour 9.0 se puede instalar desde los repositorios o como Flatpak vía Flathub, lo que facilita su despliegue en entornos mixtos.

Ventanas de pianoroll y edición MIDI más ágil

Una de las grandes novedades es la llegada de ventanas de pianoroll dedicadas: al hacer doble clic sobre una región MIDI se abre un editor independiente, separado del timeline principal, pensado para trabajar con detalle en melodías, armonías y líneas rítmicas. Esto facilita sesiones de composición complejas con múltiples instrumentos virtuales.

El sistema ahora maneja mejor el rango visible de notas en pistas MIDI y en los propios pianorolls, ajustando la vista automáticamente para centrarse en las notas realmente utilizadas. Además, se permite desplazar todo el contenido MIDI existente dentro de una región o clip durante una operación de arrastre, algo muy útil para reubicar frases completas sin perder su relación rítmica.

Ardour 9.0 introduce también funciones como el note brushing, que simplifica la inserción rápida de notas, y mejora el tratamiento de notas superpuestas, evitando duplicados y comportamientos confusos cuando se trabaja con capas densas de información MIDI.

Strumming y modos de acordes para compositores

Dentro de la edición MIDI, la versión 9.0 añade herramientas pensadas para quienes componen con instrumentos virtuales de cuerda o arreglos armónicos complejos. El nuevo sistema de strumming de notas MIDI permite generar patrones de rasgueo ajustando desplazamientos temporales entre notas de un acorde, recreando de forma más realista guitarras y arpegios.

Se incorpora además un Chord Mode basado en step on note-off, que acelera la construcción de acordes al introducir notas de manera secuencial. Estas funciones, combinadas con la mejora general del editor MIDI, hacen que Ardour sea más atractivo para compositores de bandas sonoras, música para videojuegos o producciones pop que dependan fuertemente de instrumentos virtuales.

Grabación en clips: Ardour 9.0 se acerca al flujo tipo looper

Otra de las características más llamativas es la grabación directa en slots de cue, que transforma a Ardour 9.0 en una herramienta con un flujo de trabajo similar al de los sistemas basados en clips, como Ableton Live o Bitwig Studio. Ahora es posible grabar audio o MIDI directamente en un slot con una longitud predefinida (por ejemplo, cuatro compases) o continuar la grabación hasta detenerla manualmente.

Los clips resultantes pueden lanzarse para reproducirse en el siguiente punto de cuantización, ya sea a nivel de compás o de pulso, lo que facilita actuaciones en directo, sesiones de live looping o improvisaciones en estudio. La edición posterior de estos clips se mantiene no destructiva, respetando el enfoque tradicional de Ardour.

Este sistema de cue y clips encaja bien con proyectos de creación colaborativa o enseñanza en línea, donde se busca experimentar de forma rápida y reorganizar ideas sin necesidad de editar constantemente el timeline principal.

Region FX: efectos por región para un control milimétrico

La función Region FX permite aplicar cualquier plugin a una región de audio concreta, en lugar de procesar toda la pista o un bus completo. Esto resulta especialmente interesante en tareas de postproducción, podcasts o ficción sonora, donde es frecuente querer tratar solo ciertas frases o sonidos concretos.

Cuando se utiliza Region FX, las envolventes de ganancia y la automatización asociada se ajustan automáticamente si se realizan cambios de tiempo sobre la región, como estirarla o comprimirla. De este modo se mantiene la coherencia del proyecto sin tener que reconstruir toda la automatización a mano.

La posibilidad de concentrar efectos complejos en secciones específicas ayuda también a gestionar mejor los recursos de CPU, evitando cargar cadenas pesadas en buses globales cuando solo se necesitan en momentos puntuales.

Ardour 9.0 y el analizador perceptual y herramientas de mezcla avanzadas

Ardour 9.0 llega con una ventana de analizador perceptual en tiempo real, orientada a facilitar el análisis de mezcla y la detección de problemas de frecuencias. Esta herramienta permite visualizar el espectro vivo de varias señales y superponer pistas y buses para compararlos directamente.

Esta vista es útil para localizar solapamientos de rango entre instrumentos, ajustar la ecualización de voces o revisar la distribución de energía en una mezcla de podcast. Para estudios que trabajan en mezcla de contenido para radio digital, streaming o televisión, supone una ayuda añadida a la hora de cumplir requisitos técnicos sin recurrir a herramientas de pago.

La versión también introduce mejoras en la edición de automatización mediante teclado, permitiendo el uso de modificadores, teclas de cursor y la tecla Intro para añadir nuevos puntos de control, lo que agiliza la creación de curvas precisas de volumen, panorámica o parámetros de plugins.

Ardour 9.0 introduce interfaz renovada y foco en la experiencia de uso

En el apartado visual y de usabilidad, Ardour 9.0 presenta una barra de aplicación y controles de panel actualizados, con un contenido más limpio y reorganizado. El panel de listas del editor se ha rediseñado para que la gestión de pistas, marcadores y otros elementos sea más clara y rápida.

El cuadro de diálogo de Nueva sesión / Sesiones recientes adopta ahora una interfaz con pestañas, facilitando el acceso a proyectos ya creados y a plantillas. El área de reglas del timeline se ha revisado, añadiendo controles adicionales para el manejo de compases, tiempo y marcadores.

También se ha cambiado la ubicación de los controles MIDNAM (descripciones de nombres de notas y bancos de programas MIDI), que pasan a vivir en el menú contextual del encabezado, mejorando la organización general de la interfaz para quienes trabajan con hardware externo.

Soporte multitáctil y mejoras en GUI según plataforma

Una de las mejoras destacadas a nivel de interacción es la llegada de soporte multitáctil en Linux y Windows, aprovechando las capacidades que proporcionan los propios sistemas operativos. Esto permite manipular faders, controles y elementos de la interfaz usando varios dedos, algo interesante en estudios que utilicen pantallas táctiles como superficie de control.

La interfaz añade además barras de transporte siempre visibles y sidebars laterales, junto a un panel inferior multifunción que ayuda a reorganizar el espacio de trabajo según el tipo de proyecto: edición, mezcla, grabación en cue, etc. Los colores asignados de forma round-robin a los grupos facilitan identificar de un vistazo qué pistas están relacionadas.

En macOS se ha optimizado el rendimiento del dibujado gráfico, adaptándose a cambios recientes en las APIs de Apple que antes provocaban redibujos innecesarios. Esto se traduce en una interfaz más fluida en sesiones con muchas pistas, plugins y ventanas abiertas, reduciendo la sensación de latencia visual.

Nuevas capacidades de scripting Lua en Ardour 9.0

El motor de scripting Lua sigue ampliándose y se convierte en uno de los puntos fuertes para usuarios avanzados y desarrolladores. Ardour 9.0 incorpora nuevas opciones para la selección y manipulación de puntos de control de automatización desde scripts, lo que facilita la creación de herramientas personalizadas para tareas repetitivas.

Otra novedad es la capacidad de crear regiones MIDI directamente desde Lua, generando contenido musical de forma programática sin intervención manual. Esto abre la puerta a integraciones con sistemas de composición algorítmica, generación automática de acompañamientos o herramientas educativas interactivas.

Además, se añaden controles sobre transparencias de color y otros aspectos visuales, permitiendo a los usuarios más técnicos adaptar la interfaz a flujos específicos, por ejemplo para resaltar estados de pistas, grupos o fases de un proceso de mezcla.

Gestión avanzada de archivos, regiones y proyectos

A nivel de gestión de datos, Ardour 9.0 introduce la idea de archivos y regiones MIDI más largas que la propia información que contienen. Esta funcionalidad permite definir contenedores extensos con material que se repite o se redistribuye en el tiempo, aportando flexibilidad a la hora de organizar composiciones complejas.

La aplicación maneja ahora mejor las pistas y regiones con tempos y métricas propios, lo que facilita importar grabaciones realizadas a diferentes BPM sin perder sincronización con el proyecto principal. Esto resulta práctico para productores que reciben material de colaboradores en distintos entornos o con tempos cambiantes.

Entre las novedades prácticas, también destaca la posibilidad de importar tiras de mezcla (mixer strips) desde sesiones arbitrarias de Ardour como nuevas pistas, o de mapear pistas existentes a la cadena de procesado de otras sesiones. Esta capacidad simplifica la reutilización de configuraciones de mezcla probadas en proyectos anteriores.

Compatibilidad con controladores y formatos modernos

La versión 9.0 amplía el catálogo de mapas de control MIDI, incluyendo soporte para superficies como Behringer CMD LC-1, Novation Circuit, Nektar Impact GXP y LX, Arturia Keylab 49/61/88 mk2 o LAudio (Worlde) EasyControl.9, entre otras. Esto beneficia a músicos y técnicos que trabajan con controladores de estas marcas muy presentes en el mercado.

Asimismo, se añaden nuevos archivos MIDNAM para dispositivos como Boss GT-8 y SE-70, Whammy DT o librerías como XLN Audio – Addictive Drums, facilitando la gestión de programas y bancos desde el propio DAW.

En cuanto al formato de audio, el valor por defecto pasa a ser RF64 compatible con WAV, pensado para manejar proyectos de gran tamaño y duraciones largas sin las limitaciones tradicionales del formato WAV estándar, algo relevante en grabaciones de conciertos, obras largas o archivos de archivo sonoro.

Rendimiento, estabilidad y pequeños ajustes que se notan

El equipo de desarrollo ha trabajado también en aspectos menos visibles pero importantes. Entre ellos, una reducción de dropouts y cortes al reordenar procesadores en cadenas de efectos, esencial en sesiones con muchas pistas y plugins simultáneos.

En Windows se ha mejorado el manejo de hilos en tiempo real, lo que debería traducirse en un comportamiento más estable en sistemas multiprocesador. Algunas mejoras adicionales incluyen la disponibilidad de esquemas de color específicos para pistas seleccionadas inactivas, y la posibilidad de restaurar conexiones hardware-to-hardware en backends internos.

También se ha afinado el comportamiento de algunos plugins integrados, como el ACE Amp, que ahora ofrece activación y bypass sin clics audibles. Aunque muchas de estas mejoras puedan parecer menores, juntas contribuyen a una experiencia de uso más sólida en entornos profesionales.

Con esta versión, Ardour refuerza su papel como opción sólida para producción musical, postproducción y enseñanza del audio: combina un conjunto de funciones modernas —pianoroll independiente, grabación en clips, Region FX, analizador perceptual, scripting Lua y soporte multitáctil— con un modelo de desarrollo abierto y sin cuotas, lo que lo convierte en una alternativa atractiva para estudios, docentes y creadoras y creadores que quieren mantener control sobre sus herramientas sin renunciar a prestaciones de nivel profesional.

Libreboot se ha ganado, con los años, una fama merecida entre quienes quieren recuperar el control del arranque y del hardware de sus equipos. Con la nueva versión Libreboot 26.01, apodada “Magnanimous Max”, el proyecto da un salto interesante: amplía el abanico de placas soportadas, pule a fondo su sistema de construcción y refuerza la integración con coreboot y GRUB, todo ello manteniendo su filosofía de firmware libre y transparente.

Lejos de ser una simple versión incremental, Libreboot 26.01 llega como revisión estable tras varias RC muy probadas (en concreto, la RC4, que se ha declarado directamente estable), incorporando meses de trabajo desde la anterior 25.06. Esta entrega incluye soporte para nuevos equipos x86, mejoras profundas en la automatización del build system lbmk, actualizaciones de componentes críticos como GNU GRUB, SeaBIOS y diversas utilidades, además de un buen puñado de correcciones de bugs y refactorizaciones orientadas a la robustez a largo plazo.

Novedades clave en Libreboot 26.01 “Magnanimous Max”

La edición 26.01, publicada el 30 de enero de 2026, se presenta como una versión estable sucesora de Libreboot 25.06. A nivel interno, hay un cambio importante: la 26.01 estable es esencialmente la misma que la RC4 previa, tras someterla a pruebas adicionales que han validado su estabilidad. Quien ya hubiera flasheado 26.01 RC4 no necesita reflashear, ya que no hay cambios en el código.

El foco de esta entrega está puesto en tres frentes principales: ampliación de hardware soportado, actualización de la base técnica (coreboot, GRUB, utilidades) y una gran limpieza en el build system lbmk, orientada tanto a la seguridad (menos uso de eval, mejor gestión de temporales, control de errores) como al rendimiento (cachés de Git mejor diseñadas, uso de herramientas consistentes como sbase, libarchive, etc.).

Nuevas placas y sistemas compatibles

Uno de los titulares de Libreboot 26.01 es la incorporación de cuatro nuevos equipos oficialmente soportados, ampliando el abanico de hardware donde se puede instalar el firmware:

• HP Pro 3500 Series (port por Vesek)
• Topton XE2 N150 / X2E N150 (port por Riku Viitanen)
• Lenovo ThinkPad T580 (port por Johann C. Rode)
• Dell Latitude E7240 (port por Iru Cai)

La incorporación del Dell Latitude E7240 es especialmente llamativa porque se trata de un portátil con plataforma Intel Haswell (4ª generación), todavía muy presente en entornos laborales y domésticos. Además, en este modelo es posible realizar flasheos internos del firmware usando la herramienta dell-flash-unlock, lo que simplifica enormemente la instalación de Libreboot sin tener que abrir el equipo ni recurrir a programadores externos.

En el caso del Topton X2E N150, estamos ante un equipo tipo firewall/appliance basado en Alder Lake-N, que gana soporte gracias a un trabajo específico de integración de FSP y manejo de Intel ME adaptado a esta familia. Esto implica no comprimir el FSP para garantizar su inserción fiable, desactivar ciertos modos de depuración y ajustar la configuración de coreboot para esta placa concreta.

El HP Pro 3500, un sobremesa con CPUs Sandy Bridge o Ivy Bridge, recibe un tratamiento especial en 26.01: se amplía el espacio CBFS, se reconfigura la región ME y se ajustan varios parámetros de seguridad y arranque para aprovechar mejor la ROM. Es, en definitiva, una forma de dar una segunda vida libre a hardware de más de una década que todavía puede rendir bien con GNU/Linux o BSD.

Finalmente, el ThinkPad T580 se suma a la ya nutrida familia de portátiles Lenovo soportados. Además del propio port de placa, se han trabajado aspectos como el soporte de Thunderbolt y detalles de audio, siguiendo la línea de otros modelos Kaby Lake/Coffee Lake ya presentes en Libreboot.

Mejoras en placas ya soportadas y cambios de configuración

Además del hardware nuevo, Libreboot 26.01 introduce cambios relevantes en placas previamente soportadas, orientados a aprovechar mejor el espacio de la ROM y pulir comportamientos que en la práctica suponían molestias o limitaciones.

En el caso del HP Pro 3500 se han aplicado varias medidas específicas: ampliar el CBFS hasta igualar la región BIOS, utilizar una imagen de Intel ME truncada en lugar de simplemente limpiada, desbloquear todas las regiones de flash por defecto y establecer el bit HAP (que desactiva ME) siempre que el hardware lo permite. Además, se ha definido como estándar el uso de SeaGRUB como payload (arrancando primero SeaBIOS y después GRUB), en lugar de la configuración invertida que se utilizaba inicialmente.

En las plataformas Dell Latitude, se ha incluido un parche que desactiva el apagado térmico prematuro (a unos 87°C), delegando la gestión en los mecanismos estándar de throttling del CPU. Esto evita apagados intempestivos que, aunque “seguros”, podían resultar muy molestos en el día a día.

La gama ThinkPad T480/T480s también recibe atención: se ha corregido la detección del conector de auriculares (antes era necesario cambiar manualmente el puerto con herramientas tipo pavucontrol) y se ha ajustado el soporte de Thunderbolt, incluyendo la eliminación de configuraciones duplicadas o redundantes para que el firmware compile y funcione correctamente con las versiones más recientes de coreboot.

Otra novedad interesante es la incorporación de una configuración especial para ThinkPad T440p con un CBFS de 4 MB. Esta imagen está pensada para facilitar tareas de recuperación, ya que permite reprogramar únicamente el segundo chip de 4 MB sin necesidad de tocar el primero; eso sí, si se quiere desactivar o “neutered” Intel ME por completo, sigue siendo necesario flashear el conjunto completo.

Funciones y soportes aplazados para futuras versiones

No todo lo que estaba en la hoja de ruta ha llegado a tiempo para Libreboot 26.01. Varias características se han dejado intencionadamente fuera de esta versión estable, para evitar confusiones y no exponer a los usuarios a configuraciones poco probadas. Entre lo pospuesto destacan tres líneas de trabajo:

• Integración amplia de Chromebooks Intel/AMD x86-64 a partir de las configuraciones de coreboot mantenidas por MrChromebox.
• Migración de algunas placas AMD (como ASUS KCMA-D8 y KGPE-D16) a la bifurcación de coreboot 15h.org.
• Soporte para placas Intel Alder Lake adicionales más allá de las ya integradas (como el Topton X2E N150).

Parte de este trabajo existe ya en ramas privadas y scripts experimentales, incluida una herramienta de integración de Chromebooks que adapta automáticamente configuraciones de MrChromebox al sistema de build de Libreboot. Sin embargo, faltan por resolver detalles como la descarga e integración automática de imágenes Intel ME para Alder Lake (procesadas con me_cleaner) y la realización de pruebas físicas sobre la mayoría de Chromebooks.

En un primer momento se planteó incluir estas placas en 26.01 pero marcadas como release="n" (sin ROMs precompiladas, solo build manual). Finalmente se optó por no introducirlas para no crear expectativas ni confundir al usuario final. La intención del proyecto es ir incorporando estos cambios en las ramas de pruebas y posibles versiones candidatas, comenzando previsiblemente por Libreboot 26.06 RC1 alrededor de abril de 2026.

Base técnica actualizada: coreboot y GNU GRUB al día

Uno de los pilares de esta versión es la actualización de la base de código de coreboot que Libreboot utiliza. En 26.01 se ha sincronizado el árbol principal con una instantánea de mediados de enero de 2026, lo que sitúa a Libreboot prácticamente al día respecto al proyecto upstream. A lo largo del ciclo de desarrollo también se fueron adoptando revisiones intermedias (abril, junio y julio de 2025) para ir integrando mejoras paulatinas y correcciones.

En paralelo, la carga útil principal basada en GNU GRUB se ha actualizado a la versión estable 2.14. Durante el camino se trabajó sobre la 2.14-rc1, pero finalmente la release 26.01 incorpora la versión estable con numerosos parches. Uno de los cambios más relevantes es que GRUB pasa a usar una versión más moderna de libgcrypt integrada como submódulo, lo que permite, por ejemplo, eliminar implementaciones internas de Argon2 y dar soporte nativo a un mayor abanico de algoritmos y cifrados.

Gracias a esta modernización, la compatibilidad con LUKS2 y esquemas de cifrado modernos en GRUB mejora sensiblemente. Se añaden más ciphers, se facilita el uso de configuraciones tipo BLS (Boot Loader Specification) y UKI (Unified Kernel Image), que aunque no han sido exhautivamente testeadas en esta versión, no deberían presentar problemas teóricos con la pila actual.

Además de GRUB, otras piezas como SeaBIOS, PCSX-Redux Open BIOS, flashprog y deguard han sido actualizadas a revisiones más recientes, incorporando correcciones de bugs, mejoras de compatibilidad y pequeños cambios de mantenimiento. Incluso detalles aparentemente menores, como actualizar fechas de copyright en PCSX-Redux, se han cuidado para reflejar con precisión el estado de los parches importados en 2025.

Refuerzo de la criptografía y soporte de arranques cifrados

Uno de los beneficios prácticos de la actualización a GRUB 2.14 y la nueva libgcrypt es un incremento real de las capacidades criptográficas disponibles directamente desde el firmware. En Libreboot 26.01 se activan módulos adicionales de GRUB que habilitan ciphers modernos (por ejemplo, basados en BLAKE, Argon2 mejor integrado, etc.), lo que se traduce en una mejor compatibilidad con volúmenes cifrados LUKS2.

Este refuerzo es especialmente relevante para quienes utilizan discos totalmente cifrados desde el arranque, ya que reduce fricciones entre el bootloader y las configuraciones criptográficas recientes de distribuciones GNU/Linux. De este modo, resulta más sencillo tener un sistema donde, desde el primer byte leído en el disco, todo pase por rutas libres y auditablemente seguras.

Gran limpieza en lbmk: menos eval, mejor manejo de TMPDIR y más robustez

Buena parte del trabajo de Libreboot 26.01 no se ve a simple vista, pero tiene un impacto enorme en la seguridad y estabilidad del build system lbmk, que es la herramienta encargada de coordinar descargas de código, aplicación de parches y compilación de ROMs.

Uno de los cambios más notables es la reducción drástica del uso de eval en scripts POSIX sh. Aunque no se han identificado vulnerabilidades reales, el equipo de Libreboot considera que eval debe usarse solo en casos muy justificados, ya que abre potencialmente la puerta a inyecciones de código si se cometen errores en el futuro. Se han reescrito numerosas funciones, eliminado shorthands como setcfg y se ha optado por técnicas más seguras basadas en . (source) y macros simples.

Otro frente importante ha sido la gestión de directorios temporales y de caché. Antes, muchos ficheros “temporales” terminaban en cache/, que en realidad está pensado para almacenar elementos persistentes. En 26.01 se reorganiza el sistema para situar TMPDIR dentro del propio directorio de trabajo de lbmk, abandonando la dependencia de /tmp (que puede ser un tmpfs limitado en memoria). Esto permite simplificar toda la lógica de ficheros temporales y eliminar mecanismos alternativos como la antigua variable xbloc.

Relacionado con esto, se ha rediseñado el mecanismo de lock files y detección de instancias padre/hijo. Ahora se escribe información clave en el propio lock (incluyendo el valor de TMPDIR), se endurecen los permisos (para evitar borrados accidentales) y se clarifica el flujo por el cual lbmk decide si se está ejecutando en una instancia principal o una secundaria. Con ello se reducen significativamente las condiciones de carrera y se evita que dos procesos de construcción pisen el mismo árbol de código.

También se ha puesto mucho cuidado en el manejo de errores y salida temprana de funciones. Utilidades internas como x_, fx_ y dx_ se han reforzado para comprobar argumentos y estados de retorno, y comandos sensibles que antes se encadenaban con pipes sin control (por ejemplo, ciertas llamadas a cat) ahora se envuelven con control de errores explícito. Se trata de una mejora importante de cara a que, si algo falla, lbmk lo detecte y pare, en lugar de continuar con artefactos corruptos.

Descargas más fiables: Git, hashes, cachés y dependencia de herramientas externas

La forma en que Libreboot descarga y cachea código fuente de coreboot, GRUB, U-Boot y demás proyectos también se ha modernizado considerablemente en 26.01. Se ha implementado un sistema de caché de Git donde cada remoto (incluidos mirrors de respaldo) se clona en un repositorio separado, evitando mezclar varios orígenes en un mismo clone.

Las funciones de obtención de código (get.sh, tree.sh) aprovechan ahora comandos como git show en lugar de git whatchanged (ya deprecado), y controlan más cuidadosamente qué revisiones están ya cacheadas para no descargar en vano. Se introducen flags como -f y -F para controlar si se debe forzar o no una actualización, con macros como forcepull que facilitan la lectura del código.

En paralelo, se ha reforzado el sistema de hashes y eliminación de artefactos antiguos. Ahora, cuando cambia el árbol de un proyecto, se recalculan hashes y se eliminan ficheros obsoletos en el orden correcto (primero borrar, luego actualizar el hash) para evitar estados inconsistentes. Se ha unificado la lógica de gestión de hashes para builds de árbol completo y builds de target, y se ha reorganizado la estructura de directorios (por ejemplo, colocando las construcciones de targets bajo tree/target/) para hacer más sencilla la limpieza selectiva.

Otro paso clave ha sido la decisión de no depender de utilidades arbitrarias del sistema anfitrión cuando pueden variar entre distribuciones. En 26.01 Libreboot integra y compila su propia copia de proyectos como sbase (de suckless) y libarchive para proporcionar comandos como sha512sum, bsdtar, bsdunzip o bsdcpio con comportamiento predecible en cualquier distro. De este modo se dejan atrás herramientas como unar, unrar o unzip en la mayoría de casos, reduciendo discrepancias entre entornos.

Se han refinado igualmente mensajes de error y diagnósticos, haciendo que lbmk sea más verboso cuando algo falla, pero sin abrumar al usuario con falsos positivos (por ejemplo, se evita ahora informar de hashes “incorrectos” en extracciones intermedias que, en realidad, son parte de un proceso donde solo el último archivo importa).

Mejoras específicas en Intel ME, FSP y utilidades relacionadas

En lo referente a blobs inevitables como Intel Management Engine y FSP, Libreboot 26.01 da pasos intermedios para manejarlos de la forma más limpia posible sin enredar demasiado el diseño del build system. Se ha introducido una opción -p en me_cleaner (incluida en versiones antiguas) para que, cuando se marque MEclean="y" en la configuración de una placa, se pueda extraer ME sin modificar la imagen original si así se requiere.

En placas como el Topton X2E N150 se aprovecha esta flexibilidad para simplemente fijar el bit HAP y dejar el binario ME intacto, evitando errores relacionados con comprobaciones FPTR y reduciendo la complejidad de tratamiento de imágenes recientes de Intel. En el caso del HP Pro 3500, en cambio, se opta por un ME truncado que libera más espacio en la región BIOS, aumentando el CBFS disponible para payloads adicionales.

Respecto a FSP, se han aplicado varias correcciones y ajustes: no comprimir el FSP de Alder Lake-N en el Topton, permitir el uso de imágenes FSP de Alder Lake en releases sin exigir repos específicos, y renombrar configuraciones como el modo fspgop para dejar claro cómo se inicializa la parte gráfica (integrándolo en la nomenclatura de imágenes sin que el usuario tenga que preocuparse).

Otras correcciones y pequeñas mejoras esparcidas por el código

A lo largo del ciclo entre Libreboot 25.06 y 26.01 se ha integrado un volumen considerable de pequeños parches que, sumados, mejoran la experiencia global. Entre ellos se encuentran:

• Activar SMBIOS type 16/17 para la inicialización de RAM nativa Haswell, facilitando una descripción más precisa de la memoria al sistema operativo.
• Ajustar el comportamiento de libgfxinit para sondear EDID dos veces en adaptadores problemáticos, imitando la estrategia del kernel Linux.
• Configurar el menú de U-Boot en Chromebooks GRU (bob/kevin) con un timeout más razonable de 8 segundos en lugar de 30, acelerando reinicios no supervisados.
• Introducir nuevos layouts de teclado (por ejemplo, para Noruega) en GRUB.
• Ajustar la configuración por defecto de coreboot en placas Kabylake para no fijar a fuego el parámetro power_on_after_fail, delegándolo en el backend CBFS.
• Pequeños retoques estéticos como devolver el logo arcoíris a U-Boot en las builds específicas de Libreboot.

También se han actualizado los scripts de instalación de dependencias para nuevas versiones de distribuciones como Fedora 42/43 y se han adaptado las dependencias de Arch Linux a la división del paquete unifont, garantizando que las builds funcionen correctamente en sistemas modernos.

Disponibilidad, claves GPG y espejos de descarga

Libreboot 26.01 está disponible en el directorio stable/26.01/ del servidor oficial rsync.libreboot.org, así como en una amplia red de mirrors HTTP/HTTPS repartidos por distintos países (Princeton, MIT, University of Kent, koddos.net, cicku, etc.), además de espejos “ocultos” accesibles por Tor e i2p. El proyecto recomienda encarecidamente que los mirrors oficiales repliquen desde el servidor rsync central y que los usuarios finales utilicen preferentemente los mirrors HTTPS.

Las releases se firman siempre con GPG. Para esta versión se utiliza una clave con huella completa 8BB1 F7D2 8CF7 696D BF4F 7192 5C65 4067 D383 B1FF, válida para lanzamientos posteriores a 26/01/2024 y hasta finales de 2028 salvo revocación. Claves anteriores (como la de huella 98CC DDF8 E560 47F4 75C0 44BD D0C6 2464 FA8B 4856, ya expirada) siguen publicadas para verificar releases antiguas, incluidos los paquetes con ejecutables estáticos más viejos.

El procedimiento recomendado consiste en descargar la clave, verificar el fichero de sumas SHA512 y su firma GPG, y solo entonces proceder a instalar. Esta práctica es aún más importante si se utilizan mirrors sin cifrado (HTTP/FTP), donde la integridad del canal no está garantizada; en esas circunstancias, la comprobación de firmas es absolutamente esencial.

A partir de cierto punto histórico, Libreboot dejó de ofrecer binarios estáticos en las releases recientes, centrándose en distribuir código fuente y ROMs precompiladas. Las utilidades necesarias (como flashprog) se construyen a partir de las fuentes, siguiendo la documentación oficial. Para quienes necesiten las ISOs de código fuente obligatorias por GPLv2 de versiones antiguas, siguen estando disponibles en el directorio ccsource de los mirrors de rsync.

Foco en libertad, derecho a reparar y usabilidad para no expertos

Más allá de los detalles técnicos de esta versión, el mensaje que subyace en Libreboot 26.01 es claro: el firmware libre es una herramienta para recuperar soberanía sobre el hardware. El proyecto se opone abiertamente a mecanismos como Intel Boot Guard que solo ejecutan firmware firmado por el fabricante, porque impiden al usuario modificar sus propias máquinas y cierran la puerta a soluciones libres como coreboot.

La visión del equipo es que la libertad de estudiar, compartir y modificar el software debe considerarse un derecho básico. Asociado a ello va el derecho a reparar y a alargar la vida de los dispositivos: la existencia de Libreboot permite seguir actualizando y utilizando hardware que los fabricantes dan por “obsoleto”, con firmwares propietarios que raramente reciben parches de seguridad pasado un tiempo.

A nivel práctico, Libreboot busca que todo esto no sea un lujo reservado a desarrolladores. La combinación de lbmk como sistema de compilación automatizado, ROMs precompiladas y documentación paso a paso convierte a Libreboot en un “coreboot empaquetado” para usuarios finales. Si alguien quiere compilar desde cero y ajustar cada detalle, puede hacerlo; pero quien solo desee un firmware libre que funcione “sin pelearse” encuentra en Libreboot una alternativa lista para usar.

Con Libreboot 26.01 “Magnanimous Max”, el proyecto consolida su posición como referente en firmware libre basado en coreboot, emparejando una base técnica muy actualizada con una batería considerable de correcciones, mejoras de seguridad y nuevas placas soportadas. Para quien tenga un HP Pro 3500, un Dell Latitude E7240, un ThinkPad T580 o un appliance como el Topton X2E N150, esta versión abre la puerta a deshacerse del BIOS propietario; para el resto de usuarios y colaboradores, supone un paso más en la maduración de un ecosistema que apuesta, sin ambigüedades, por la libertad del usuario sobre su propio hardware.