SoftwareLibre
Photo
MuyLinux
KDE Plasma: esquinas redondeadas y sombras en aplicaciones rebeldes
https://www.muylinux.com/wp-content/uploads/2026/10/plasma.jpg
Hace un par de semanas que se lanzó KDE Plasma 6.8 y, de todas las novedades que trajo, hay una de especial interés para los amantes de la personalización: nuevas reglas para añadir «sombras, contornos y esquinas redondeadas a aquellas aplicaciones con decoraciones del lado del cliente que no proporcionan estos efectos por sí mismas». Que dicho así puede sonar un poco confuso, pero es sencillo y, sobre todo, agradecido.
Lo que permite esta configuración, más que función, es una mejor integración visual de aquellas aplicaciones que usan su propio sistema para dibujar la ventana, forzando esquinas redondeadas y sombras para acercarlas al estilo predeterminado del escritorio. Basta con abrir cualquier aplicación con la barra de ventanas de Plasma —con la decoración de KWin— y otra que no la use para ver la diferencia.
Esta novedad, además, vino con un ejemplo práctico: Steam, cuya regla se incluye de manera predeterminada, facilitando su replicación en otras aplicaciones. Para hacerlo, hay que entrar en: «Preferencias del sistema > Gestión de ventanas > Reglas de las ventanas«, duplicar la regla de «Windows settings for steam» y editarla. El único ajuste imprescindible es la detección de propiedades de la ventana.
https://www.muylinux.com/wp-content/uploads/2026/10/wr1.jpg
«Detectar propiedades de la ventana» es simple: se pulsa el botón y se marca con el cursor la ventana que se desee configurar, procurando apuntar al borde de la ventana. Aparecerá entonces un diálogo con opciones para determinar la clase de la ventana: este es el único campo que puede resultar confuso, porque no todas las aplicaciones responden al mismo nombre. Aplicando el cambio se comprueba si funciona.
https://www.muylinux.com/wp-content/uploads/2026/10/wr2.jpg
Todo es cuestión de probar: si con «Clase de la ventana (aplicación)» no aplica el cambio, «Clase completa de ventanas» lo hará. Solo hay que tener en cuenta una cosa: mientras que al activar una regla esta se aplicará inmediatamente, al desactivarla no sucede así, y hay que reiniciar la aplicación para ver los cambios.
https://www.muylinux.com/wp-content/uploads/2026/10/wr3.jpg
Y como solo con imágenes puede resultar confuso cómo se hace esto, he grabado un pequeño vídeo para verlo tal cual.
La entrada KDE Plasma: esquinas redondeadas y sombras en aplicaciones rebeldes es original de MuyLinux
KDE Plasma: esquinas redondeadas y sombras en aplicaciones rebeldes
https://www.muylinux.com/wp-content/uploads/2026/10/plasma.jpg
Hace un par de semanas que se lanzó KDE Plasma 6.8 y, de todas las novedades que trajo, hay una de especial interés para los amantes de la personalización: nuevas reglas para añadir «sombras, contornos y esquinas redondeadas a aquellas aplicaciones con decoraciones del lado del cliente que no proporcionan estos efectos por sí mismas». Que dicho así puede sonar un poco confuso, pero es sencillo y, sobre todo, agradecido.
Lo que permite esta configuración, más que función, es una mejor integración visual de aquellas aplicaciones que usan su propio sistema para dibujar la ventana, forzando esquinas redondeadas y sombras para acercarlas al estilo predeterminado del escritorio. Basta con abrir cualquier aplicación con la barra de ventanas de Plasma —con la decoración de KWin— y otra que no la use para ver la diferencia.
Esta novedad, además, vino con un ejemplo práctico: Steam, cuya regla se incluye de manera predeterminada, facilitando su replicación en otras aplicaciones. Para hacerlo, hay que entrar en: «Preferencias del sistema > Gestión de ventanas > Reglas de las ventanas«, duplicar la regla de «Windows settings for steam» y editarla. El único ajuste imprescindible es la detección de propiedades de la ventana.
https://www.muylinux.com/wp-content/uploads/2026/10/wr1.jpg
«Detectar propiedades de la ventana» es simple: se pulsa el botón y se marca con el cursor la ventana que se desee configurar, procurando apuntar al borde de la ventana. Aparecerá entonces un diálogo con opciones para determinar la clase de la ventana: este es el único campo que puede resultar confuso, porque no todas las aplicaciones responden al mismo nombre. Aplicando el cambio se comprueba si funciona.
https://www.muylinux.com/wp-content/uploads/2026/10/wr2.jpg
Todo es cuestión de probar: si con «Clase de la ventana (aplicación)» no aplica el cambio, «Clase completa de ventanas» lo hará. Solo hay que tener en cuenta una cosa: mientras que al activar una regla esta se aplicará inmediatamente, al desactivarla no sucede así, y hay que reiniciar la aplicación para ver los cambios.
https://www.muylinux.com/wp-content/uploads/2026/10/wr3.jpg
Y como solo con imágenes puede resultar confuso cómo se hace esto, he grabado un pequeño vídeo para verlo tal cual.
La entrada KDE Plasma: esquinas redondeadas y sombras en aplicaciones rebeldes es original de MuyLinux
SoftwareLibre
Photo
Desde Linux SteamOS 3.9.5: Linux 7.2, KDE Plasma 6.7, mejoras en Wi-Fi, hibernación preliminar y mas
https://blog.desdelinux.net/wp-content/uploads/2025/06/steam-os.png
Valve dio a conocer hace pocos días el lanzamiento de la nueva version de «SteamOS 3.9.5», siendo la primera versión estable de la rama 3.9 del sistema operativo utilizado en Steam Deck y Steam Machines.
Esta actualización se destaca por la modernización de sus componentes base, comenzando con la sincronización con la base de datos de paquetes más reciente de Arch Linux. Además de ello el cambio más importante es el salto al kernel de Linux 7.2 (abandonando la versión 6.16), lo que habilita los controladores gráficos más recientes y mejora significativamente la compatibilidad con nuevo hardware, incluyendo tecnologías como USB4Stream. Principales novedades de SteamOS 3.9.5
Esta nueva version de SteamOS 3.9.5 presenta mejoras para los usuarios que utilizan sus dispositivos como ordenadores convencionales, el Modo Escritorio ha recibido una actualización mayor, pasando de KDE Plasma 6.4.3 a la versión KDE Plasma 6.7.3, incorporando de golpe todas las mejoras de las ramas 6.5 y 6.6. En este modo, ahora es posible activar el protector y la pantalla de bloqueo desde la configuración, y se habilita el inicio de sesión para usuarios mediante RDP (Protocolo de Escritorio Remoto).
Otra de las novedades que presenta la nueva version, es en la conectividad WiFi la cual para las nuevas instalaciones, el gestor wpa_supplicant vuelve a ser el backend predeterminado para el Wi-Fi, reemplazando a iwd (aunque este último sigue disponible en sistemas ya instalados). Valve ha optimizado wpa_supplicant para garantizar una reconexión casi instantánea al despertar el dispositivo del modo de suspensión y ha corregido un error que impedía la conexión al primer intento con redes Wi-Fi ocultas. Novedades en hibernación y rendimiento
El sistema incluye soporte preliminar para la hibernación, una función que permite guardar el contenido de la RAM en el disco para ahorrar batería. Sin embargo, Valve aclara que esta función aún no es visible en la interfaz del Modo Juego y permanece desactivada por defecto en la Steam Deck debido a un error pendiente en los controladores. A pesar de esto, se ha logrado reducir el consumo energético de la consola cuando se encuentra en reposo y sin reproducir audio.
A nivel de rendimiento gráfico y de juegos, SteamOS 3.9.5 incluye múltiples correcciones, entre las cuales se destacan las siguientes:
* El limitador de fotogramas ahora se aplica correctamente al utilizar pantallas externas y no genera errores de FPS al activar VRR (Frecuencia de Actualización Variable).
* Se solucionan problemas de suspensión/reanudación en equipos equipados con tarjetas gráficas AMD RDNA1 y RDNA2.
* Se corrigió un error por el que cambiar la zona horaria podía impedir cambiar al modo Escritorio hasta que se reiniciaba el sistema.
* Se realizaron actualizaciones de seguridad y estabilidad.
* Se revocaron los certificados comprometidos emitidos por eMudhra.
* Juegos como Elden Ring y Dark Souls III ya pueden ejecutarse correctamente en las nuevas CPU Intel Panther Lake.
* Se corrige la corrupción gráfica de la pantalla de arranque en dispositivos con procesadores Intel PTL+. Expansión a de soporte a otros dispositivos y novedades internas
Reflejando la intención de Valve de expandir SteamOS más allá de su propio hardware, la actualización mejora la compatibilidad del gestor de arranque (bootloader) con diversas placas base y optimiza el rendimiento del sistema al ejecutarse como invitado en máquinas virtuales con aceleración gráfica (utilizando virtio-gpu y venus).
Otros dispositivos también reciben soporte directo: se ha añadido soporte preliminar para el control de brillo[...]
https://blog.desdelinux.net/wp-content/uploads/2025/06/steam-os.png
Valve dio a conocer hace pocos días el lanzamiento de la nueva version de «SteamOS 3.9.5», siendo la primera versión estable de la rama 3.9 del sistema operativo utilizado en Steam Deck y Steam Machines.
Esta actualización se destaca por la modernización de sus componentes base, comenzando con la sincronización con la base de datos de paquetes más reciente de Arch Linux. Además de ello el cambio más importante es el salto al kernel de Linux 7.2 (abandonando la versión 6.16), lo que habilita los controladores gráficos más recientes y mejora significativamente la compatibilidad con nuevo hardware, incluyendo tecnologías como USB4Stream. Principales novedades de SteamOS 3.9.5
Esta nueva version de SteamOS 3.9.5 presenta mejoras para los usuarios que utilizan sus dispositivos como ordenadores convencionales, el Modo Escritorio ha recibido una actualización mayor, pasando de KDE Plasma 6.4.3 a la versión KDE Plasma 6.7.3, incorporando de golpe todas las mejoras de las ramas 6.5 y 6.6. En este modo, ahora es posible activar el protector y la pantalla de bloqueo desde la configuración, y se habilita el inicio de sesión para usuarios mediante RDP (Protocolo de Escritorio Remoto).
Otra de las novedades que presenta la nueva version, es en la conectividad WiFi la cual para las nuevas instalaciones, el gestor wpa_supplicant vuelve a ser el backend predeterminado para el Wi-Fi, reemplazando a iwd (aunque este último sigue disponible en sistemas ya instalados). Valve ha optimizado wpa_supplicant para garantizar una reconexión casi instantánea al despertar el dispositivo del modo de suspensión y ha corregido un error que impedía la conexión al primer intento con redes Wi-Fi ocultas. Novedades en hibernación y rendimiento
El sistema incluye soporte preliminar para la hibernación, una función que permite guardar el contenido de la RAM en el disco para ahorrar batería. Sin embargo, Valve aclara que esta función aún no es visible en la interfaz del Modo Juego y permanece desactivada por defecto en la Steam Deck debido a un error pendiente en los controladores. A pesar de esto, se ha logrado reducir el consumo energético de la consola cuando se encuentra en reposo y sin reproducir audio.
A nivel de rendimiento gráfico y de juegos, SteamOS 3.9.5 incluye múltiples correcciones, entre las cuales se destacan las siguientes:
* El limitador de fotogramas ahora se aplica correctamente al utilizar pantallas externas y no genera errores de FPS al activar VRR (Frecuencia de Actualización Variable).
* Se solucionan problemas de suspensión/reanudación en equipos equipados con tarjetas gráficas AMD RDNA1 y RDNA2.
* Se corrigió un error por el que cambiar la zona horaria podía impedir cambiar al modo Escritorio hasta que se reiniciaba el sistema.
* Se realizaron actualizaciones de seguridad y estabilidad.
* Se revocaron los certificados comprometidos emitidos por eMudhra.
* Juegos como Elden Ring y Dark Souls III ya pueden ejecutarse correctamente en las nuevas CPU Intel Panther Lake.
* Se corrige la corrupción gráfica de la pantalla de arranque en dispositivos con procesadores Intel PTL+. Expansión a de soporte a otros dispositivos y novedades internas
Reflejando la intención de Valve de expandir SteamOS más allá de su propio hardware, la actualización mejora la compatibilidad del gestor de arranque (bootloader) con diversas placas base y optimiza el rendimiento del sistema al ejecutarse como invitado en máquinas virtuales con aceleración gráfica (utilizando virtio-gpu y venus).
Otros dispositivos también reciben soporte directo: se ha añadido soporte preliminar para el control de brillo[...]
SoftwareLibre
Desde Linux SteamOS 3.9.5: Linux 7.2, KDE Plasma 6.7, mejoras en Wi-Fi, hibernación preliminar y mas https://blog.desdelinux.net/wp-content/uploads/2025/06/steam-os.png Valve dio a conocer hace pocos días el lanzamiento de la nueva version de «SteamOS 3.9.5»…
y corregido un bloqueo en Forza Horizon 6 para la consola Legion Go 2, se ha solucionado un fallo de velocidad excesiva del ventilador en equipos ASUS, y se mejora la compatibilidad con el adaptador inalámbrico Steam Frame (incluyendo correcciones en la transmisión de títulos VR). Adicionalmente, Steam Remote Play ahora funciona en una Steam Machine incluso si esta arranca sin un monitor conectado.
Finalmente, a nivel de desarrollo, se ha restablecido la compatibilidad con el sistema de comunicación Android Binder IPC, se actualizó la versión de RenderDoc, y varios scripts internos y paquetes han cambiado su nomenclatura del prefijo «steamos-» al prefijo «holo-«.
Si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.
Finalmente, a nivel de desarrollo, se ha restablecido la compatibilidad con el sistema de comunicación Android Binder IPC, se actualizó la versión de RenderDoc, y varios scripts internos y paquetes han cambiado su nomenclatura del prefijo «steamos-» al prefijo «holo-«.
Si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.
SoftwareLibre
Photo
MuyLinux
Canonical retoma Ubuntu Core Desktop como apuesta de futuro para el escritorio
https://www.muylinux.com/wp-content/uploads/2026/10/UbuntuCoreDesktop.jpg
Canonical ha retomado el desarrollo de Ubuntu Core Desktop, su propuesta de escritorio inmutable basada íntegramente en Snap, con un equipo dedicado y una ambición que va más allá de ofrecer una alternativa: la apuesta pasa, una vez hayan pulido el producto, por convertirlo en la experiencia predeterminada de Ubuntu Desktop. Pero que nadie se estrese, porque la aparición de uno no significará la desaparición del otro, al menos en el medio plazo.
En todo caso, la noticia es importante, porque la última vez que hablamos de este tema fue para contar que Ubuntu Core Desktop se retrasaba de manera indefinida. Se esperaba que la distribución debutase junto a Ubuntu 24.04 LTS, pero fue que no. Ahora, Canonical reconoce que el desarrollo había quedado en barbecho y anuncia su reactivación con tres focos en mente: equipos centrados en el navegador, estaciones de desarrollo y dispositivos para jugar. Un escritorio construido con Snap Explica la compañía que Ubuntu Core lleva casi una década utilizándose en productos comerciales del ámbito del Internet de las Cosas, los sistemas embebidos y la robótica, pero llevar esa base al escritorio supone un cambio considerable, con ventajas esperadas en seguridad, recuperación y mantenimiento, pero también con dificultades pendientes. Al fin y al cabo, se trata de trasladar la experiencia de distribuciones inmutables ya asentadas, pero con la paquetería Snap en el centro.
De hecho, la propuesta de Canonical es más atrevida si cabe, ya que en Ubuntu Core todo se distribuye como paquetes Snap, desde el gestor de arranque y el kernel hasta el escritorio, los servicios y las aplicaciones. La intención es ofrecer un sistema más difícil de romper, más sencillo de recuperar y con mayor control sobre los recursos a los que accede cada aplicación. El problema es que la versión preliminar de 2023 reunía buena parte del escritorio en un único paquete base alternativo.
Así, una de las prioridades será separar el sistema en componentes con interfaces bien definidas que permitan una actualización independiente, sin regenerar la imagen completa del sistema con cada cambio. Para esta nueva intentona Canonical vuelve a colaborar con los responsables de KDE neon Core, proyecto derivado que mantiene la actividad, pero que no se dirige al usuario de a pie. Todo lo contrario de Ubuntu Core Desktop, cuya base sí se espera que sirva para facilitar distintos escritorios y experiencias, en consonancia con lo que hoy representan los sabores de Ubuntu. Navegación, desarrollo y juegos
Retomando los distintos casos de uso previstos, el primero es el más sencillo: un equipo en el que casi todo se hace desde el navegador, al más puro estilo de ChromeOS, pero con más margen de actuación: o sea, con el catálogo de la Snap Store, que no es pequeño e incluye software de servidor. Con Firefox y Chromium como ejes de la propuesta y con ambos ya disponibles como Snap, se entiende que buena parte del trabajo estaba resuelto en la versión preliminar.
Para los desarrolladores, la apuesta pasa por Canonical Workshop, herramienta basado en LXD para crear entornos aislados. El propósito principal es separar las herramientas y dependencias del sistema anfitrión; el secundario, aislar los agentes de programación con IA de archivos y credenciales personales. Sin embargo, Workshop y su editor predeterminado (VSCode) usan todavía un confinamiento «classic», incompatible con la ejecución directa en Ubuntu Core, por lo que hay trabajo por delante.
Por último, los juegos. En particular, en consolas portátiles, apunta Canonical. La compañía reconoce que su Snap de Steam ha recibido menos atención de la deseada por falta de recursos —hasta Valve se llegó a quejar de ello[...]
Canonical retoma Ubuntu Core Desktop como apuesta de futuro para el escritorio
https://www.muylinux.com/wp-content/uploads/2026/10/UbuntuCoreDesktop.jpg
Canonical ha retomado el desarrollo de Ubuntu Core Desktop, su propuesta de escritorio inmutable basada íntegramente en Snap, con un equipo dedicado y una ambición que va más allá de ofrecer una alternativa: la apuesta pasa, una vez hayan pulido el producto, por convertirlo en la experiencia predeterminada de Ubuntu Desktop. Pero que nadie se estrese, porque la aparición de uno no significará la desaparición del otro, al menos en el medio plazo.
En todo caso, la noticia es importante, porque la última vez que hablamos de este tema fue para contar que Ubuntu Core Desktop se retrasaba de manera indefinida. Se esperaba que la distribución debutase junto a Ubuntu 24.04 LTS, pero fue que no. Ahora, Canonical reconoce que el desarrollo había quedado en barbecho y anuncia su reactivación con tres focos en mente: equipos centrados en el navegador, estaciones de desarrollo y dispositivos para jugar. Un escritorio construido con Snap Explica la compañía que Ubuntu Core lleva casi una década utilizándose en productos comerciales del ámbito del Internet de las Cosas, los sistemas embebidos y la robótica, pero llevar esa base al escritorio supone un cambio considerable, con ventajas esperadas en seguridad, recuperación y mantenimiento, pero también con dificultades pendientes. Al fin y al cabo, se trata de trasladar la experiencia de distribuciones inmutables ya asentadas, pero con la paquetería Snap en el centro.
De hecho, la propuesta de Canonical es más atrevida si cabe, ya que en Ubuntu Core todo se distribuye como paquetes Snap, desde el gestor de arranque y el kernel hasta el escritorio, los servicios y las aplicaciones. La intención es ofrecer un sistema más difícil de romper, más sencillo de recuperar y con mayor control sobre los recursos a los que accede cada aplicación. El problema es que la versión preliminar de 2023 reunía buena parte del escritorio en un único paquete base alternativo.
Así, una de las prioridades será separar el sistema en componentes con interfaces bien definidas que permitan una actualización independiente, sin regenerar la imagen completa del sistema con cada cambio. Para esta nueva intentona Canonical vuelve a colaborar con los responsables de KDE neon Core, proyecto derivado que mantiene la actividad, pero que no se dirige al usuario de a pie. Todo lo contrario de Ubuntu Core Desktop, cuya base sí se espera que sirva para facilitar distintos escritorios y experiencias, en consonancia con lo que hoy representan los sabores de Ubuntu. Navegación, desarrollo y juegos
Retomando los distintos casos de uso previstos, el primero es el más sencillo: un equipo en el que casi todo se hace desde el navegador, al más puro estilo de ChromeOS, pero con más margen de actuación: o sea, con el catálogo de la Snap Store, que no es pequeño e incluye software de servidor. Con Firefox y Chromium como ejes de la propuesta y con ambos ya disponibles como Snap, se entiende que buena parte del trabajo estaba resuelto en la versión preliminar.
Para los desarrolladores, la apuesta pasa por Canonical Workshop, herramienta basado en LXD para crear entornos aislados. El propósito principal es separar las herramientas y dependencias del sistema anfitrión; el secundario, aislar los agentes de programación con IA de archivos y credenciales personales. Sin embargo, Workshop y su editor predeterminado (VSCode) usan todavía un confinamiento «classic», incompatible con la ejecución directa en Ubuntu Core, por lo que hay trabajo por delante.
Por último, los juegos. En particular, en consolas portátiles, apunta Canonical. La compañía reconoce que su Snap de Steam ha recibido menos atención de la deseada por falta de recursos —hasta Valve se llegó a quejar de ello[...]
SoftwareLibre
MuyLinux Canonical retoma Ubuntu Core Desktop como apuesta de futuro para el escritorio https://www.muylinux.com/wp-content/uploads/2026/10/UbuntuCoreDesktop.jpg Canonical ha retomado el desarrollo de Ubuntu Core Desktop, su propuesta de escritorio inmutable…
— y quiere aprovechar la modularidad para, como en el caso mencionado, actualizar independientemente los componentes necesarios para jugar, como Proton, Mesa o los controladores gráficos, sin afectar al resto del sistema. También se plantea la posibilidad de explorar modos de uso adaptados a estos dispositivos. Aplicaciones, permisos y lo que viene
¿Para cuándo podemos esperar algo concreto? El camino será largo, parece. Hay cosas por pulir, comenzando por la disponibilidad de software, y es que pese a que la Snap Store cuenta con un catálogo de más de 11.000 paquetes según Canonical (muchas sin mantenimiento alguno, pero ese es otro tema) y la mayoría son compatibles con Ubuntu Core, el sistema exige que utilicen confinamiento estricto y no todas cumplen con este requisito.
Hay más: todo lo que queda fuera del ecosistema de Snap y de lo que los usuarios también querrán sacar provecho: APT, Nix, Flatpak… Para resolverlo, Canonical recurrirá a contenedores y máquinas virtuales con integraciones que faciliten su uso en el escritorio. Es decir, harán lo mismo que hacen otras distros inmutables con herramientas como Distrobox y similares.
Por otro lado están los permisos, elemento clave para que el aislamiento de las aplicaciones resulte práctico. Para ello, Canonical ha desarrollado un sistema que coordina el kernel, AppArmor y snapd para dar al usuario el control sobre los accesos de cada aplicación sin tener que modificarla, y que por ahora permite gestionar el acceso a la cámara, el micrófono y el directorio personal, aunque se prevé ampliar su alcance.
Mientras tanto, se trabaja en la adaptación del prototipo a core26 y se prepara la infraestructura de pruebas continuas y compilaciones diarias habitual de Ubuntu, la cual debería estar disponible en las próximas semanas. Sea como fuere, cabe repetir que esto va para largo… pero con pretensiones de cambio como no se habían anticipado hasta el momento.
La entrada Canonical retoma Ubuntu Core Desktop como apuesta de futuro para el escritorio es original de MuyLinux
¿Para cuándo podemos esperar algo concreto? El camino será largo, parece. Hay cosas por pulir, comenzando por la disponibilidad de software, y es que pese a que la Snap Store cuenta con un catálogo de más de 11.000 paquetes según Canonical (muchas sin mantenimiento alguno, pero ese es otro tema) y la mayoría son compatibles con Ubuntu Core, el sistema exige que utilicen confinamiento estricto y no todas cumplen con este requisito.
Hay más: todo lo que queda fuera del ecosistema de Snap y de lo que los usuarios también querrán sacar provecho: APT, Nix, Flatpak… Para resolverlo, Canonical recurrirá a contenedores y máquinas virtuales con integraciones que faciliten su uso en el escritorio. Es decir, harán lo mismo que hacen otras distros inmutables con herramientas como Distrobox y similares.
Por otro lado están los permisos, elemento clave para que el aislamiento de las aplicaciones resulte práctico. Para ello, Canonical ha desarrollado un sistema que coordina el kernel, AppArmor y snapd para dar al usuario el control sobre los accesos de cada aplicación sin tener que modificarla, y que por ahora permite gestionar el acceso a la cámara, el micrófono y el directorio personal, aunque se prevé ampliar su alcance.
Mientras tanto, se trabaja en la adaptación del prototipo a core26 y se prepara la infraestructura de pruebas continuas y compilaciones diarias habitual de Ubuntu, la cual debería estar disponible en las próximas semanas. Sea como fuere, cabe repetir que esto va para largo… pero con pretensiones de cambio como no se habían anticipado hasta el momento.
La entrada Canonical retoma Ubuntu Core Desktop como apuesta de futuro para el escritorio es original de MuyLinux
SoftwareLibre
Photo
MuyLinux
Tor Browser 16 salta a Firefox ESR 153, estrena soporte para ARM64 y retira el de 32 bits
https://www.muylinux.com/wp-content/uploads/2025/10/TorBrowser.png Tor Browser 16 es la nueva versión del navegador privado por excelencia, un lanzamiento que llega con una renovación de sus ajustes, nuevas opciones y cambios importantes en el soporte para Linux. La actualización anual del navegador del Proyecto Tor se presenta en tiempo y forma, como siempre, con base en Firefox ESR.
Como sucede en cada salto de versión mayor, buena parte del trabajo de los desarrolladores de Tor viene de adaptar las novedades acumuladas por Firefox durante el último año. En este caso, la base es Firefox ESR 153, disponible desde julio, cuya adopción ha supuesto revisar más de 270 incidencias de Mozilla para identificar y tratar cambios que pudieran perjudicar la privacidad y la seguridad de los usuarios.
La novedad más destacada de esta versión, que no la única, es el rediseño de los ajustes, también heredado de Firefox: desaparece el apartado «General» y sus opciones se reparten entre secciones como «Apariencia», «Descargas», «Pestañas y navegación», «Accesibilidad» e «Idiomas». A esto se suman otras novedades acumuladas desde Firefox 140, publicado en junio de 2025.
Tor Browser también retoca sus propias páginas, como las de conexión y nivel de seguridad, recreadas con los nuevos componentes para mantener la coherencia del conjunto. La reorganización conserva las preferencias existentes, pero no todo se muestra de la misma manera, ya que algunas opciones que pueden comprometer la privacidad o facilitar la identificación del navegador mediante fingerprinting se han ocultado o incluyen advertencias más claras.
Otra incorporación interesante de Tor Browser 16 es la posibilidad de utilizar títulos de ventana genéricos. Es decir, en lugar del nombre de la página abierta, todas las ventanas pueden mostrar simplemente «Tor Browser», evitando que otras aplicaciones o el propio sistema obtengan esa información al leer sus títulos. La función viene desactivada por defecto, según explican, debido a que todavía necesitan evaluar sus posibles efectos sobre herramientas de accesibilidad.
Además, el navegador renueva también el manual de usuario integrado, que pasa a utilizar los contenidos del nuevo portal de soporte de Tor y Tails. Lo que no cambia es su disponibilidad incluso aunque no se tenga conexión.
https://www.muylinux.com/wp-content/uploads/2026/10/tor_browser16.jpg
En cuanto a plataformas, tras un año de pruebas Tor Browser 16 incorpora soporte nativo estable para Linux ARM64, incluyendo dispositivos como Raspberry Pi y Mac con Apple Silicon que ejecuten Linux. Y algo más, de todo ese conjunto heredado de Firefox al que hacíamos referencia: esta versión ya no ofrece soporte para Linux x86 de 32 bits, una retirada que ya se había anticipado con la versión anterior.
Más allá de Linux, pero no mucho, léase Android, el navegador recibe una renovación parcial de la interfaz basada en Jetpack Compose y Material Design 3, que continuará en próximas versiones.
Todos los detalles están en el anuncio oficial de Tor Browser 16.
¿Te interesa probarlo? Lo más interesante de Tor Browser es que no necesitas ser un experto para usarlo: descarga el ejecutable y ya puedes echar millas con más privacidad de la que te puede ofrecer cualquier VPN… pero sin tanta velocidad. Eso sí, la potencia sin control no sirve de nada. O lo que es lo mismo: la privacidad absoluta en Internet no existe, así que cuidado con lo que haces.
La entrada Tor Browser 16 salta a Firefox ESR 153, estrena soporte para ARM64 y retira el de 32 bits es original de MuyLinux
Tor Browser 16 salta a Firefox ESR 153, estrena soporte para ARM64 y retira el de 32 bits
https://www.muylinux.com/wp-content/uploads/2025/10/TorBrowser.png Tor Browser 16 es la nueva versión del navegador privado por excelencia, un lanzamiento que llega con una renovación de sus ajustes, nuevas opciones y cambios importantes en el soporte para Linux. La actualización anual del navegador del Proyecto Tor se presenta en tiempo y forma, como siempre, con base en Firefox ESR.
Como sucede en cada salto de versión mayor, buena parte del trabajo de los desarrolladores de Tor viene de adaptar las novedades acumuladas por Firefox durante el último año. En este caso, la base es Firefox ESR 153, disponible desde julio, cuya adopción ha supuesto revisar más de 270 incidencias de Mozilla para identificar y tratar cambios que pudieran perjudicar la privacidad y la seguridad de los usuarios.
La novedad más destacada de esta versión, que no la única, es el rediseño de los ajustes, también heredado de Firefox: desaparece el apartado «General» y sus opciones se reparten entre secciones como «Apariencia», «Descargas», «Pestañas y navegación», «Accesibilidad» e «Idiomas». A esto se suman otras novedades acumuladas desde Firefox 140, publicado en junio de 2025.
Tor Browser también retoca sus propias páginas, como las de conexión y nivel de seguridad, recreadas con los nuevos componentes para mantener la coherencia del conjunto. La reorganización conserva las preferencias existentes, pero no todo se muestra de la misma manera, ya que algunas opciones que pueden comprometer la privacidad o facilitar la identificación del navegador mediante fingerprinting se han ocultado o incluyen advertencias más claras.
Otra incorporación interesante de Tor Browser 16 es la posibilidad de utilizar títulos de ventana genéricos. Es decir, en lugar del nombre de la página abierta, todas las ventanas pueden mostrar simplemente «Tor Browser», evitando que otras aplicaciones o el propio sistema obtengan esa información al leer sus títulos. La función viene desactivada por defecto, según explican, debido a que todavía necesitan evaluar sus posibles efectos sobre herramientas de accesibilidad.
Además, el navegador renueva también el manual de usuario integrado, que pasa a utilizar los contenidos del nuevo portal de soporte de Tor y Tails. Lo que no cambia es su disponibilidad incluso aunque no se tenga conexión.
https://www.muylinux.com/wp-content/uploads/2026/10/tor_browser16.jpg
En cuanto a plataformas, tras un año de pruebas Tor Browser 16 incorpora soporte nativo estable para Linux ARM64, incluyendo dispositivos como Raspberry Pi y Mac con Apple Silicon que ejecuten Linux. Y algo más, de todo ese conjunto heredado de Firefox al que hacíamos referencia: esta versión ya no ofrece soporte para Linux x86 de 32 bits, una retirada que ya se había anticipado con la versión anterior.
Más allá de Linux, pero no mucho, léase Android, el navegador recibe una renovación parcial de la interfaz basada en Jetpack Compose y Material Design 3, que continuará en próximas versiones.
Todos los detalles están en el anuncio oficial de Tor Browser 16.
¿Te interesa probarlo? Lo más interesante de Tor Browser es que no necesitas ser un experto para usarlo: descarga el ejecutable y ya puedes echar millas con más privacidad de la que te puede ofrecer cualquier VPN… pero sin tanta velocidad. Eso sí, la potencia sin control no sirve de nada. O lo que es lo mismo: la privacidad absoluta en Internet no existe, así que cuidado con lo que haces.
La entrada Tor Browser 16 salta a Firefox ESR 153, estrena soporte para ARM64 y retira el de 32 bits es original de MuyLinux
SoftwareLibre
Photo
Desde Linux
KeePassXC 2.8.0 llega autocompletado en Wayland, migración a Qt6 y ARM64
https://blog.desdelinux.net/wp-content/uploads/2022/04/KeePassXC.png
Recientemente, se dio a conocer el lanzamiento de la nueva version de «KeePassXC 2.8.0», una version que marca el inicio de una nueva serie que introduce características largamente esperadas y parches de seguridad críticos. Tras un mes en fase beta, esta versión llega con optimizaciones tanto para usuarios de escritorio tradicionales como para entornos corporativos.
Para aquellos que desconocen de KeePassXC, deben saber que este es un gestor de contraseñas gratuito y de código abierto licenciado bajo la licencia publica de GNU. Esta aplicación comenzó como un fork de la comunidad de KeePassX (en sí misma un port de KeePass) debido a lo que se consideró que era muy lento el desarrollo de KeePassX, y la falta de respuesta de su mantenedor. Principales novedades de KeePassXC 2.8.0
El cambio más importante de esta versión es la transición completa de la interfaz gráfica de Qt5 a Qt6, lo que garantiza un mejor rendimiento y compatibilidad con sistemas operativos modernos. Para los usuarios de Linux, una de las novedades más esperadas es el soporte nativo para el autocompletado de contraseñas (Auto-Type) en Wayland, logrado a través de la integración con los portales XDG (XDG Desktop Portals).
Otra de las novedades que presenta la nueva version es la posibilidad personalizar libremente los atajos de teclado del gestor, también se ha implementado el modo de desbloqueo rápido mediante Polkit en distribuciones Linux (añadiendo un UUID a los metadatos públicos de la base de datos) y mediante la contraseña del dispositivo en macOS para situaciones donde Touch ID no esté disponible. Además, se añade la capacidad de sincronizar bases de datos de forma remota utilizando herramientas externas directamente integradas en el flujo de trabajo. Soporte ARM64, agente SSH y cambios
KeePassXC amplía su compatibilidad distribuyendo por primera vez compilaciones nativas para arquitecturas ARM64 en Windows y versiones experimentales AArch64 en formato AppImage para Linux (con mejoras significativas en la gestión de TLS y la integración con el escritorio).
De los demás cambios que presenta la nueva version, se destacan las siguientes mejoras:
* Agente SSH: Se añade soporte nativo para generar claves criptográficas RSA, ECDSA y Ed25519 directamente desde la aplicación.
* Archivos de estado (Linux): La aplicación ahora guarda sus archivos de estado en el directorio ~/.local/state/ (XDG_STATE_HOME) en lugar de contaminar el directorio de caché (~/.cache).
* Importación desde Proton Pass: El importador se ha actualizado para soportar la migración de contraseñas Wi-Fi, claves SSH y registros de tipos desconocidos.
* Gestión corporativa (Windows): Se habilita el soporte para que los administradores de TI fuercen configuraciones específicas mediante anulaciones de Políticas de Grupo (GPO).
* Estadísticas: La interfaz ahora muestra el conteo total de claves de acceso (passkeys) y códigos TOTP dentro de la base de datos. Correcciones de seguridad
Finalmente, cabe mencionar que esta aborda cinco vulnerabilidades de seguridad que afectaban a la serie 2.7.x y anteriores. Los desarrolladores señalaron que, si bien ningún código vulnerable fue introducido por IA, herramientas de inteligencia artificial fueron clave para descubrir estos fallos:
* CVE-2026-69150: Corrige un error de acceso a memoria liberada (use-after-free) que podía ser explotado al importar archivos de bases de datos KDB especialmente diseñados.
* Extensión del navegador (CVE pendiente): Previene la inyección de referencias de entradas al crear o actualizar registros a través de la ex[...]
KeePassXC 2.8.0 llega autocompletado en Wayland, migración a Qt6 y ARM64
https://blog.desdelinux.net/wp-content/uploads/2022/04/KeePassXC.png
Recientemente, se dio a conocer el lanzamiento de la nueva version de «KeePassXC 2.8.0», una version que marca el inicio de una nueva serie que introduce características largamente esperadas y parches de seguridad críticos. Tras un mes en fase beta, esta versión llega con optimizaciones tanto para usuarios de escritorio tradicionales como para entornos corporativos.
Para aquellos que desconocen de KeePassXC, deben saber que este es un gestor de contraseñas gratuito y de código abierto licenciado bajo la licencia publica de GNU. Esta aplicación comenzó como un fork de la comunidad de KeePassX (en sí misma un port de KeePass) debido a lo que se consideró que era muy lento el desarrollo de KeePassX, y la falta de respuesta de su mantenedor. Principales novedades de KeePassXC 2.8.0
El cambio más importante de esta versión es la transición completa de la interfaz gráfica de Qt5 a Qt6, lo que garantiza un mejor rendimiento y compatibilidad con sistemas operativos modernos. Para los usuarios de Linux, una de las novedades más esperadas es el soporte nativo para el autocompletado de contraseñas (Auto-Type) en Wayland, logrado a través de la integración con los portales XDG (XDG Desktop Portals).
Otra de las novedades que presenta la nueva version es la posibilidad personalizar libremente los atajos de teclado del gestor, también se ha implementado el modo de desbloqueo rápido mediante Polkit en distribuciones Linux (añadiendo un UUID a los metadatos públicos de la base de datos) y mediante la contraseña del dispositivo en macOS para situaciones donde Touch ID no esté disponible. Además, se añade la capacidad de sincronizar bases de datos de forma remota utilizando herramientas externas directamente integradas en el flujo de trabajo. Soporte ARM64, agente SSH y cambios
KeePassXC amplía su compatibilidad distribuyendo por primera vez compilaciones nativas para arquitecturas ARM64 en Windows y versiones experimentales AArch64 en formato AppImage para Linux (con mejoras significativas en la gestión de TLS y la integración con el escritorio).
De los demás cambios que presenta la nueva version, se destacan las siguientes mejoras:
* Agente SSH: Se añade soporte nativo para generar claves criptográficas RSA, ECDSA y Ed25519 directamente desde la aplicación.
* Archivos de estado (Linux): La aplicación ahora guarda sus archivos de estado en el directorio ~/.local/state/ (XDG_STATE_HOME) en lugar de contaminar el directorio de caché (~/.cache).
* Importación desde Proton Pass: El importador se ha actualizado para soportar la migración de contraseñas Wi-Fi, claves SSH y registros de tipos desconocidos.
* Gestión corporativa (Windows): Se habilita el soporte para que los administradores de TI fuercen configuraciones específicas mediante anulaciones de Políticas de Grupo (GPO).
* Estadísticas: La interfaz ahora muestra el conteo total de claves de acceso (passkeys) y códigos TOTP dentro de la base de datos. Correcciones de seguridad
Finalmente, cabe mencionar que esta aborda cinco vulnerabilidades de seguridad que afectaban a la serie 2.7.x y anteriores. Los desarrolladores señalaron que, si bien ningún código vulnerable fue introducido por IA, herramientas de inteligencia artificial fueron clave para descubrir estos fallos:
* CVE-2026-69150: Corrige un error de acceso a memoria liberada (use-after-free) que podía ser explotado al importar archivos de bases de datos KDB especialmente diseñados.
* Extensión del navegador (CVE pendiente): Previene la inyección de referencias de entradas al crear o actualizar registros a través de la ex[...]
SoftwareLibre
Desde Linux KeePassXC 2.8.0 llega autocompletado en Wayland, migración a Qt6 y ARM64 https://blog.desdelinux.net/wp-content/uploads/2022/04/KeePassXC.png Recientemente, se dio a conocer el lanzamiento de la nueva version de «KeePassXC 2.8.0», una version…
tensión.
* Mensajería nativa (CVE pendiente): Soluciona escrituras fuera de límites (out-of-bounds) al cifrar y descifrar mensajes de comunicación nativa en el navegador.
* Agente SSH en Windows (CVE pendiente): Aleatoriza los nombres de mapeo de memoria compartida al enviar claves SSH a Pageant para evitar intercepciones.
* Importador KDB heredado (CVE pendiente): Parchea un desbordamiento de enteros y lecturas fuera de límites detectadas por el Centro de Ciberseguridad de la OTAN. ¿Como instalar KeePassXC en Linux?
Para aquellos que estén interesados en poder instalar este gestor de contraseñas en tu sistema, puedes hacerlo siguiendo las instrucciones que compartimos a continuación.
Si eres usuario de Ubuntu o cualquier derivado de este, puedes realizar la instalación añadiendo el siguiente repositorio. Para ello debes abrir una terminal y en ella vas a teclear:
Si prefieres la instalacion por medio de los paquetes de Flatpak, basta con que cuentes con el repositorio de Flathub configurado en tu distribución y desde una terminal debes teclear:
Para iniciar la aplicación desde la terminal, basta con teclear:
Otro de los metodos disponibles es con los paquetes .AppImage los cuales puedes descargar desde la página oficial de KeePassXC. Una vez descargado debes otorgar los permisos de ejecución al archivo descargado:
Inicia la aplicación haciendo doble clic sobre el archivo o ejecutando en la terminal:
Finalmente, para quienes prefieran el uso de Snap, pueden instalar la aplicación ejecutando:
* Mensajería nativa (CVE pendiente): Soluciona escrituras fuera de límites (out-of-bounds) al cifrar y descifrar mensajes de comunicación nativa en el navegador.
* Agente SSH en Windows (CVE pendiente): Aleatoriza los nombres de mapeo de memoria compartida al enviar claves SSH a Pageant para evitar intercepciones.
* Importador KDB heredado (CVE pendiente): Parchea un desbordamiento de enteros y lecturas fuera de límites detectadas por el Centro de Ciberseguridad de la OTAN. ¿Como instalar KeePassXC en Linux?
Para aquellos que estén interesados en poder instalar este gestor de contraseñas en tu sistema, puedes hacerlo siguiendo las instrucciones que compartimos a continuación.
Si eres usuario de Ubuntu o cualquier derivado de este, puedes realizar la instalación añadiendo el siguiente repositorio. Para ello debes abrir una terminal y en ella vas a teclear:
sudo add-apt-repository ppa:phoerious/keepassxc
sudo apt-get update
sudo apt-get install keepassxc FlatpakSi prefieres la instalacion por medio de los paquetes de Flatpak, basta con que cuentes con el repositorio de Flathub configurado en tu distribución y desde una terminal debes teclear:
flatpak install flathub org.keepassxc.KeePassXCPara iniciar la aplicación desde la terminal, basta con teclear:
flatpak run org.keepassxc.KeePassXC AppImageOtro de los metodos disponibles es con los paquetes .AppImage los cuales puedes descargar desde la página oficial de KeePassXC. Una vez descargado debes otorgar los permisos de ejecución al archivo descargado:
sudo chmod +x KeePassXC-*.AppImageInicia la aplicación haciendo doble clic sobre el archivo o ejecutando en la terminal:
./KeePassXC-*.AppImage SnapFinalmente, para quienes prefieran el uso de Snap, pueden instalar la aplicación ejecutando:
sudo snap install keepassxc
SoftwareLibre
Photo
Desde Linux
Un fallo en el arranque PXE permite eludir Secure Boot y ejecutar malware con privilegios totales desde la BIOS
https://blog.desdelinux.net/wp-content/uploads/2026/10/CVE-2026-97631.jpg
Hace pocos días se dio a conocer información sobre una vulnerabilidad crítica (catalogada como CVE-2026-97631, con una severidad CVSS v4 de 9.5) en TianoCore EDK II, la implementación de referencia UEFI de código abierto desarrollada originalmente por Intel.
Este fallo compromete a millones de equipos a nivel mundial, incluyendo servidores de centros de datos, computadoras de escritorio y portátiles de proveedores que utilizan masivamente este código, como AMI, Insyde, Phoenix y la plataforma Project Mu de Microsoft. Un fallo que ha estado presente mas de 16 años
La falla reside en el controlador PXE-Base Code (UefiPxeBcDxe), responsable del entorno de pre-ejecución de arranque por red (PXE) a través de IPv4 o IPv6. El problema se origina en un desbordamiento de búfer que ha permanecido oculto en el código durante 16 años. Sin autenticación, antes del arranque, a través de la red, mientras una máquina está arrancando PXE a través de IPv4 o IPv6. El atacante solo necesita enviar un mensaje de error ICMP unicast dirigido a la IP del cliente, desde cualquier distancia de la red; la ventana de exposición es la duración del arranque PXE.
Durante el proceso de arranque por red, el controlador mantiene un oyente (listener) abierto para recibir mensajes de error ICMP y los almacena en un búfer de tamaño fijo de 504 bytes. Sin embargo, debido a una mala implementación en la comprobación de los límites, si el mensaje supera los 504 bytes, el sistema continúa copiando los datos, desbordando el búfer y sobrescribiendo la memoria adyacente del sistema. Un atacante (que cuente con acceso de bajo nivel a la red local o desde la red global) solo necesita conocer la dirección IP del objetivo y enviar un simple paquete unicast ICMP malicioso justo durante la ventana de arranque PXE. El ataque no requiere autenticación ni interacción del usuario. El daño se manifiesta en dos niveles:
* Denegación de servicio (DoS): Un paquete mal formado provoca una excepción en la CPU dentro del núcleo DXE, bloqueando indefinidamente el proceso de arranque.
* Ejecución de código de alto privilegio: Si el atacante conoce la estructura de memoria de la compilación de firmware específica del servidor, puede inyectar y ejecutar código malicioso directamente en el Entorno de Ejecución de Controladores (DXE), el nivel más privilegiado del procesador (Anillo 0 o Ring 0). La gravedad de esta ejecución recae en que ocurre antes de que el sistema operativo se inicie, lo que permite al atacante eludir mecanismos de defensa como el Secure Boot y el Arranque Medido (Measured Boot), alterando la cadena de confianza que protege componentes sensibles como el Módulo de Plataforma Confiable (TPM). Aunque el exploit no logra persistencia inmediata (el código inyectado corre una sola vez), esa única ejecución es suficiente para instalar otros programas maliciosos de forma permanente que se activarán en cada arranque. Solución y mitigación del problema
Inicialmente, la divulgación coordinada del fallo estaba programada para enero de 2027, sin embargo, un ingeniero del proveedor AMI rompió accidentalmente la planeación al publicar una solicitud de extracción (pull request) pública en GitHub con la solución. Esta filtración forzó al proyecto TianoCore a publicar un aviso de seguridad prematuro el 22 de octubre de 2026.
La solución técnica (PR 13302), ya integrada en el código fuente de EDK II, añade comprobaciones de límites adecuadas, corrige la aritmética de punteros para truncar los mensajes excesivos, limpia el búfer antes de cada copia e incorpora pruebas unitarias. A pesar de esto,[...]
Un fallo en el arranque PXE permite eludir Secure Boot y ejecutar malware con privilegios totales desde la BIOS
https://blog.desdelinux.net/wp-content/uploads/2026/10/CVE-2026-97631.jpg
Hace pocos días se dio a conocer información sobre una vulnerabilidad crítica (catalogada como CVE-2026-97631, con una severidad CVSS v4 de 9.5) en TianoCore EDK II, la implementación de referencia UEFI de código abierto desarrollada originalmente por Intel.
Este fallo compromete a millones de equipos a nivel mundial, incluyendo servidores de centros de datos, computadoras de escritorio y portátiles de proveedores que utilizan masivamente este código, como AMI, Insyde, Phoenix y la plataforma Project Mu de Microsoft. Un fallo que ha estado presente mas de 16 años
La falla reside en el controlador PXE-Base Code (UefiPxeBcDxe), responsable del entorno de pre-ejecución de arranque por red (PXE) a través de IPv4 o IPv6. El problema se origina en un desbordamiento de búfer que ha permanecido oculto en el código durante 16 años. Sin autenticación, antes del arranque, a través de la red, mientras una máquina está arrancando PXE a través de IPv4 o IPv6. El atacante solo necesita enviar un mensaje de error ICMP unicast dirigido a la IP del cliente, desde cualquier distancia de la red; la ventana de exposición es la duración del arranque PXE.
Durante el proceso de arranque por red, el controlador mantiene un oyente (listener) abierto para recibir mensajes de error ICMP y los almacena en un búfer de tamaño fijo de 504 bytes. Sin embargo, debido a una mala implementación en la comprobación de los límites, si el mensaje supera los 504 bytes, el sistema continúa copiando los datos, desbordando el búfer y sobrescribiendo la memoria adyacente del sistema. Un atacante (que cuente con acceso de bajo nivel a la red local o desde la red global) solo necesita conocer la dirección IP del objetivo y enviar un simple paquete unicast ICMP malicioso justo durante la ventana de arranque PXE. El ataque no requiere autenticación ni interacción del usuario. El daño se manifiesta en dos niveles:
* Denegación de servicio (DoS): Un paquete mal formado provoca una excepción en la CPU dentro del núcleo DXE, bloqueando indefinidamente el proceso de arranque.
* Ejecución de código de alto privilegio: Si el atacante conoce la estructura de memoria de la compilación de firmware específica del servidor, puede inyectar y ejecutar código malicioso directamente en el Entorno de Ejecución de Controladores (DXE), el nivel más privilegiado del procesador (Anillo 0 o Ring 0). La gravedad de esta ejecución recae en que ocurre antes de que el sistema operativo se inicie, lo que permite al atacante eludir mecanismos de defensa como el Secure Boot y el Arranque Medido (Measured Boot), alterando la cadena de confianza que protege componentes sensibles como el Módulo de Plataforma Confiable (TPM). Aunque el exploit no logra persistencia inmediata (el código inyectado corre una sola vez), esa única ejecución es suficiente para instalar otros programas maliciosos de forma permanente que se activarán en cada arranque. Solución y mitigación del problema
Inicialmente, la divulgación coordinada del fallo estaba programada para enero de 2027, sin embargo, un ingeniero del proveedor AMI rompió accidentalmente la planeación al publicar una solicitud de extracción (pull request) pública en GitHub con la solución. Esta filtración forzó al proyecto TianoCore a publicar un aviso de seguridad prematuro el 22 de octubre de 2026.
La solución técnica (PR 13302), ya integrada en el código fuente de EDK II, añade comprobaciones de límites adecuadas, corrige la aritmética de punteros para truncar los mensajes excesivos, limpia el búfer antes de cada copia e incorpora pruebas unitarias. A pesar de esto,[...]
SoftwareLibre
Desde Linux Un fallo en el arranque PXE permite eludir Secure Boot y ejecutar malware con privilegios totales desde la BIOS https://blog.desdelinux.net/wp-content/uploads/2026/10/CVE-2026-97631.jpg Hace pocos días se dio a conocer información sobre una vulnerabilidad…
el peligro inminente radica en que los desarrolladores maliciosos ya pueden analizar el parche público para crear exploits funcionales. El proceso para que los fabricantes (proveedores de BIOS y servidores) integren este código en sus propias actualizaciones de firmware, y para que los clientes las apliquen, suele ser lento y complejo.
Mientras los parches no estén implementados, los expertos recomiendan aislar el tráfico de arranque PXE en redes de aprovisionamiento desconectadas del exterior, bloquear mensajes de error ICMP dirigidos a máquinas en fase de inicio y desactivar PXE en aquellos servidores que no lo requieran para su funcionamiento habitual.
Finalmente, si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.
Mientras los parches no estén implementados, los expertos recomiendan aislar el tráfico de arranque PXE en redes de aprovisionamiento desconectadas del exterior, bloquear mensajes de error ICMP dirigidos a máquinas en fase de inicio y desactivar PXE en aquellos servidores que no lo requieran para su funcionamiento habitual.
Finalmente, si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.
SoftwareLibre
Photo
MuyLinux
Gentoo renuncia a mantener Chromium: ¿Ubuntu tenía razón?
https://www.muylinux.com/wp-content/uploads/2026/10/chromium.jpg Gentoo ha anunciado la retirada de Chromium de sus repositorios y el motivo no es otro que las dificultades para mantener el navegador actualizado. Se trata de una decisión muy particular en principio, habida cuenta de la naturaleza de la distribución y de cómo gestiona el paquete en cuestión… Pero nada más lejos de la realidad. O esa es la impresión atendiendo al histórico de este asunto.
En el caso de Gentoo, los responsables del paquete han terminado por darlo por perdido tras años de desgaste y una discusión con usuarios cansados de recibir actualizaciones a destiempo, incluyendo aquellas que contienen parches de seguridad. El anuncio fijó el 24 de octubre como fecha de eliminación, aunque la ficha oficial todavía muestra el paquete bloqueado y pendiente de retirada, quizás con la esperanza de que alguien se haga cargo de la tarea.
¿Pero acaso en Gentoo no se compila cada uno sus propias aplicaciones? Sí… y no. Lo cierto es que una cosa es compilar una aplicación y otra mantener las instrucciones que permiten hacerlo, los llamados ebuilds. Alguien tiene que adaptar esas instrucciones a cada nueva versión, resolver problemas con las dependencias y comprobar que funcionan las distintas opciones de configuración para que el usuario haga el resto. Pero eso no elimina el trabajo previo de los mantenedores.
Así, el problema es algo más complejo que un simple «tarda mucho», que también: compilaciones largas, dependencias complejas, cambios frecuentes en las herramientas de desarrollo y un ritmo de publicaciones difícil de seguir. A ello se le suma la idiosincrasia propia del proyecto, como es compilar desde el código fuente con opciones de personalización que hay que probar y conservar entre versiones para que funcione lo mejor posible para la mayor cantidad de usuarios.
Mantener Chromium al día puede llevarles el equivalente a una jornada de trabajo semanal, explican, y no compensa lidiar con esa presión cuando, al fin y al cabo, su trabajo es voluntario. ¿Y ahora? Se plantea mantener el paquete en un repositorio externo, siempre que haya alguien dispuesto a hacerlo, e incluso retomarlo en los repositorios oficiales, si aparece un equipo comprometido con un plan sostenible para ello.
En resumen, las quejas han agotado la paciencia de los actuales mantenedores de Chromium en Gentoo, pero lo arduo de la tarea viene de lejos. De hecho, viene de muy lejos, y es que no es la primera distribución que hace algo así, o la primera vez que hablamos del tema en estas páginas. La pionera, se podría decir, fue Ubuntu, cuando decidió sustituir el paquete Deb de Chromium por un Snap y justificó el cambio en el esfuerzo de mantener el navegador para varias versiones y arquitecturas.
El problema no era únicamente abandonar el paquete Deb, sino que instalar Chromium mediante APT terminaba instalando el Snap. Cabe recordar que aquello generó una considerable polémica con Linux Mint, que finalmente optó por mantener Chromium en sus repositorios, eso sí, automatizando el proceso y dedicando un servidor con un Ryzen 9 y 128 GB de RAM para reducir compilaciones que podían superar las seis horas a poco más de una. Es solo un ejemplo, pero tal vez resulte hoy más significativo de lo que fue en su momento.
Claro que tampoco es comparable del todo la situación, pues no dispone de los mismos recursos una empresa como Canonical, un proyecto como Linux Mint… y el mantenedor de un paquete de Gentoo, por más popular que pueda ser este. Dicho lo cual… ¿alguien compila su propio Chromium? En Gentoo o en cualquier otra distro.
La entrada Gentoo renuncia a mantener Chromium: ¿Ubuntu tenía razón? es original de MuyLinux
Gentoo renuncia a mantener Chromium: ¿Ubuntu tenía razón?
https://www.muylinux.com/wp-content/uploads/2026/10/chromium.jpg Gentoo ha anunciado la retirada de Chromium de sus repositorios y el motivo no es otro que las dificultades para mantener el navegador actualizado. Se trata de una decisión muy particular en principio, habida cuenta de la naturaleza de la distribución y de cómo gestiona el paquete en cuestión… Pero nada más lejos de la realidad. O esa es la impresión atendiendo al histórico de este asunto.
En el caso de Gentoo, los responsables del paquete han terminado por darlo por perdido tras años de desgaste y una discusión con usuarios cansados de recibir actualizaciones a destiempo, incluyendo aquellas que contienen parches de seguridad. El anuncio fijó el 24 de octubre como fecha de eliminación, aunque la ficha oficial todavía muestra el paquete bloqueado y pendiente de retirada, quizás con la esperanza de que alguien se haga cargo de la tarea.
¿Pero acaso en Gentoo no se compila cada uno sus propias aplicaciones? Sí… y no. Lo cierto es que una cosa es compilar una aplicación y otra mantener las instrucciones que permiten hacerlo, los llamados ebuilds. Alguien tiene que adaptar esas instrucciones a cada nueva versión, resolver problemas con las dependencias y comprobar que funcionan las distintas opciones de configuración para que el usuario haga el resto. Pero eso no elimina el trabajo previo de los mantenedores.
Así, el problema es algo más complejo que un simple «tarda mucho», que también: compilaciones largas, dependencias complejas, cambios frecuentes en las herramientas de desarrollo y un ritmo de publicaciones difícil de seguir. A ello se le suma la idiosincrasia propia del proyecto, como es compilar desde el código fuente con opciones de personalización que hay que probar y conservar entre versiones para que funcione lo mejor posible para la mayor cantidad de usuarios.
Mantener Chromium al día puede llevarles el equivalente a una jornada de trabajo semanal, explican, y no compensa lidiar con esa presión cuando, al fin y al cabo, su trabajo es voluntario. ¿Y ahora? Se plantea mantener el paquete en un repositorio externo, siempre que haya alguien dispuesto a hacerlo, e incluso retomarlo en los repositorios oficiales, si aparece un equipo comprometido con un plan sostenible para ello.
En resumen, las quejas han agotado la paciencia de los actuales mantenedores de Chromium en Gentoo, pero lo arduo de la tarea viene de lejos. De hecho, viene de muy lejos, y es que no es la primera distribución que hace algo así, o la primera vez que hablamos del tema en estas páginas. La pionera, se podría decir, fue Ubuntu, cuando decidió sustituir el paquete Deb de Chromium por un Snap y justificó el cambio en el esfuerzo de mantener el navegador para varias versiones y arquitecturas.
El problema no era únicamente abandonar el paquete Deb, sino que instalar Chromium mediante APT terminaba instalando el Snap. Cabe recordar que aquello generó una considerable polémica con Linux Mint, que finalmente optó por mantener Chromium en sus repositorios, eso sí, automatizando el proceso y dedicando un servidor con un Ryzen 9 y 128 GB de RAM para reducir compilaciones que podían superar las seis horas a poco más de una. Es solo un ejemplo, pero tal vez resulte hoy más significativo de lo que fue en su momento.
Claro que tampoco es comparable del todo la situación, pues no dispone de los mismos recursos una empresa como Canonical, un proyecto como Linux Mint… y el mantenedor de un paquete de Gentoo, por más popular que pueda ser este. Dicho lo cual… ¿alguien compila su propio Chromium? En Gentoo o en cualquier otra distro.
La entrada Gentoo renuncia a mantener Chromium: ¿Ubuntu tenía razón? es original de MuyLinux
SoftwareLibre
Photo
MuyLinux
Flatpak ha ganado la partida
https://www.muylinux.com/wp-content/uploads/2026/10/flatpak.jpg Flatpak ha ganado la partida. Por partida doble, además: lo ha hecho en el escritorio Linux en general, y en el mío en singular. Todo en términos generales, claro: lo de mi escritorio es cosa mía, como mía es la opinión que aquí os dejo, la cual no puedo sustentar con datos, porque no los hay. Al menos, no como para realizar una comparación consistente. Pero creo que basta con observar a la mayoría de distribuciones para hacerse una idea de por dónde van los tiros.
La partida, sobra decirlo, es la que juegan desde hace tiempo los dos grandes formatos de paquetes universales del escritorio Linux. Me refiero al ya viejo Flatpak vs Snap, y es que hace cerca de una década que venimos hablando del tema. ¡Una década! Para tomar algo de perspectiva, si bien cada uno nació con un objetivo diferente, tanto Snap como Flatpak se anunciaron oficialmente a mediados de 2016, aunque no nacían de la nada. No vamos a repasar su trayectoria ahora, pero sí podemos estar de acuerdo en que se han asentado en el escritorio Linux como recursos ampliamente utilizados.
En el caso de Snap, comenzó su andadura con una significativa relevancia entre las desarrolladoras comerciales, una tracción que parece continuar, como se puede comprobar echando un vistazo por la tienda: las compañías que confiaban en Canonical siguen haciéndolo, y otras tantas se han sumado a la iniciativa. Todo ello pese a la casi exclusiva presencia del formato en el entorno de Ubuntu. Las cosas como son: el desinterés por la propuesta de Canonical —cuando no rechazo explícito— por parte de las grandes distribuciones Linux ha sido manifiesto y, por consiguiente, un lastre para su extensión. Justo lo contrario que ha pasado con Flatpak.
No es algo que me invente: mientras que la mayoría de distribuciones ofrecen soporte de Flatpak —y en muchos casos Flathub— por defecto —por no mencionar aquellas cuyo modelo se basa de manera consustancial en este particular combo, léase prácticamente todo lo que lleve la etiqueta de inmutable—, solo Ubuntu hace lo propio con Snap. Es más, Canonical llegó a vetar la preinstalación de Flatpak en todas sus ediciones oficiales por motivos obvios… que nada tienen que ver con la tontería que dijo Mark Shuttleworth en su momento.
En este punto es preciso subrayar el eje de la discordia: el modelo centralizado de Snap, frente al descentralizado de Flatpak, aun cuando cabe preguntarse qué habría sido de este último sin Flathub. Sin embargo, rehúso la discusión en estos términos porque si bien Flathub actúa como vía de distribución centralizada de facto, no invalida la naturaleza de Flatpak. Un ejemplo un poco loco, pero válido, lo tenemos en la aplicación de GeForce Now para Linux. Y hay muchos más. Flatpak y Snap han llegado para quedarse. Eso lo dije en un artículo en 2019, en el que hablaba de cómo ambos formatos se estaban posicionando como la referencia para distribuir aplicaciones en el escritorio Linux. Si era verdad entonces, imaginaos ahora. A AppImage lo dejé —y dejo— fuera de la ecuación porque juega en otra liga. La cuestión de fondo es que lo que arrancó como una vía de facilitar la vida a desarrolladores y usuarios, ha cumplido con lo prometido: los «formatos universales» funcionan.
Hace un rato publicaba una entrada que ilustra bien la problemática que resuelven estos formatos, aunque sea un caso muy concreto y un tanto extremo: el de Chromium. No menciono alternativas, pero podría haberlo hecho, ya que los usuarios de Gentoo también pueden hacer uso de ellas. ¿Para qué gastar esfuerzos manteniendo un paquete tan engorroso, cuando un Snap o un Flatpak lo solucionan de un plumazo (entendiendo por plumazo hacer el trabajo una sola vez y que sirva para todos)?
Una de las críticas habituales que se hace a este tipo de formatos es la de reinventar la rueda… hasta[...]
Flatpak ha ganado la partida
https://www.muylinux.com/wp-content/uploads/2026/10/flatpak.jpg Flatpak ha ganado la partida. Por partida doble, además: lo ha hecho en el escritorio Linux en general, y en el mío en singular. Todo en términos generales, claro: lo de mi escritorio es cosa mía, como mía es la opinión que aquí os dejo, la cual no puedo sustentar con datos, porque no los hay. Al menos, no como para realizar una comparación consistente. Pero creo que basta con observar a la mayoría de distribuciones para hacerse una idea de por dónde van los tiros.
La partida, sobra decirlo, es la que juegan desde hace tiempo los dos grandes formatos de paquetes universales del escritorio Linux. Me refiero al ya viejo Flatpak vs Snap, y es que hace cerca de una década que venimos hablando del tema. ¡Una década! Para tomar algo de perspectiva, si bien cada uno nació con un objetivo diferente, tanto Snap como Flatpak se anunciaron oficialmente a mediados de 2016, aunque no nacían de la nada. No vamos a repasar su trayectoria ahora, pero sí podemos estar de acuerdo en que se han asentado en el escritorio Linux como recursos ampliamente utilizados.
En el caso de Snap, comenzó su andadura con una significativa relevancia entre las desarrolladoras comerciales, una tracción que parece continuar, como se puede comprobar echando un vistazo por la tienda: las compañías que confiaban en Canonical siguen haciéndolo, y otras tantas se han sumado a la iniciativa. Todo ello pese a la casi exclusiva presencia del formato en el entorno de Ubuntu. Las cosas como son: el desinterés por la propuesta de Canonical —cuando no rechazo explícito— por parte de las grandes distribuciones Linux ha sido manifiesto y, por consiguiente, un lastre para su extensión. Justo lo contrario que ha pasado con Flatpak.
No es algo que me invente: mientras que la mayoría de distribuciones ofrecen soporte de Flatpak —y en muchos casos Flathub— por defecto —por no mencionar aquellas cuyo modelo se basa de manera consustancial en este particular combo, léase prácticamente todo lo que lleve la etiqueta de inmutable—, solo Ubuntu hace lo propio con Snap. Es más, Canonical llegó a vetar la preinstalación de Flatpak en todas sus ediciones oficiales por motivos obvios… que nada tienen que ver con la tontería que dijo Mark Shuttleworth en su momento.
En este punto es preciso subrayar el eje de la discordia: el modelo centralizado de Snap, frente al descentralizado de Flatpak, aun cuando cabe preguntarse qué habría sido de este último sin Flathub. Sin embargo, rehúso la discusión en estos términos porque si bien Flathub actúa como vía de distribución centralizada de facto, no invalida la naturaleza de Flatpak. Un ejemplo un poco loco, pero válido, lo tenemos en la aplicación de GeForce Now para Linux. Y hay muchos más. Flatpak y Snap han llegado para quedarse. Eso lo dije en un artículo en 2019, en el que hablaba de cómo ambos formatos se estaban posicionando como la referencia para distribuir aplicaciones en el escritorio Linux. Si era verdad entonces, imaginaos ahora. A AppImage lo dejé —y dejo— fuera de la ecuación porque juega en otra liga. La cuestión de fondo es que lo que arrancó como una vía de facilitar la vida a desarrolladores y usuarios, ha cumplido con lo prometido: los «formatos universales» funcionan.
Hace un rato publicaba una entrada que ilustra bien la problemática que resuelven estos formatos, aunque sea un caso muy concreto y un tanto extremo: el de Chromium. No menciono alternativas, pero podría haberlo hecho, ya que los usuarios de Gentoo también pueden hacer uso de ellas. ¿Para qué gastar esfuerzos manteniendo un paquete tan engorroso, cuando un Snap o un Flatpak lo solucionan de un plumazo (entendiendo por plumazo hacer el trabajo una sola vez y que sirva para todos)?
Una de las críticas habituales que se hace a este tipo de formatos es la de reinventar la rueda… hasta[...]
SoftwareLibre
MuyLinux Flatpak ha ganado la partida https://www.muylinux.com/wp-content/uploads/2026/10/flatpak.jpg Flatpak ha ganado la partida. Por partida doble, además: lo ha hecho en el escritorio Linux en general, y en el mío en singular. Todo en términos generales…
que llegue otro que crea poder hacerlo mejor y vuelta a empezar. Lo cierto, no obstante, es que ya están asentados, han servido de catalizador para que muchos desarrolladores y empresas traigan sus aplicaciones a Linux —no a una o dos distribuciones, sino al ecosistema— y para que aún más usuarios disfruten de ellas sin complicaciones. ¿Qué hay de malo en ello?
En mi opinión, varias cosas. Algunas han cambiado, otras no. Siempre me quejé de uno de los males del modelo, como es el excesivo espacio en disco que gastan las aplicaciones instaladas debido a la cantidad de dependencias repetidas, un coste que Flatpak mitiga compartiendo entornos de ejecución y evitando duplicaciones de archivos. Todavía no ha alcanzado la eficiencia del modelo tradicional, pero se ha avanzado lo suficiente como para que no duela. A todo esto, no es imprescindible, pero tampoco está de más perder un par de minutos de vez en cuando con el mantenimiento de Flatpak.
La integración con el escritorio fue también uno de los aspectos que menos me atrajo, pero también se ha avanzado bastante con ello, de nuevo, sin tocar techo. Las integraciones profundas se siguen resistiendo y no tengo mejor ejemplo que el de KeePassXC y los navegadores: si alguien lo ha conseguido, que me lo diga (me refiero a la integración del gestor de contraseñas y el navegador, ambos en formato Flatpak o Snap… y sin hacer cosas raras).
¿Otros problemas que haya detectado con los años? La compatibilidad con el hardware se puede resentir en casos determinados. Entre las posibles causas está el aislamiento, una de las ventajas de seguridad de Flatpak y Snap frente a los paquetes tradicionales, que puede ocasionar problemas con el reconocimiento o aprovechamiento de recursos. Me ha pasado con lanzadores de juegos, software de edición multimedia… Y me ha pasado lo contrario también: encontrar mejor soporte predeterminado que el «nativo» en aplicaciones como navegadores web.
Tampoco voy a entrar en detalles técnicos, eso lo dejo para otro día. Hoy me conformo con soltar lo de que Flatpak ha ganado la partida, algo que, creo, se deduce a simple vista a poco que se esté al día. Y no reniego de Snap, ¿eh? En Ubuntu lo sigo usando, aunque sea para no perderle la pista. Pero incluso en Ubuntu necesito instalar Flatpak y, claro, Flathub, para no quedarme sin alguna de mis aplicaciones habituales: las hay que están y, además, bien mantenidas; las hay que están abandonadas y las hay que… Que no las hay, vaya.
Para que nadie me diga nada, varios ejemplos de aplicaciones populares: Heroic Games Launcher, Inkscape, OBS Studio, qBittorrent, Stremio, Upscayl, Zen Browser… La tarea de mirar cuáles están en uno u otro sitio y con qué nivel de mantenimiento, os la dejo a vosotros. ¿Hay ejemplos a la inversa? Dejádmelos en los comentarios.
Voy más allá: si antes aplicaba y recomendaba la máxima de «primero, los repositorios de la distribución», hace ya bastante que lo hago justo al revés: salvo que hablemos de aplicaciones intrínsecas del entorno de escritorio, o de aquellas que me pueden dar problemas como los ya comentados, priorizo Flatpak. Para casi todo. Y como sistema principal llevo un tiempo usando Tumbleweed, por lo que la ventaja de estar siempre actualizado ni la tengo en cuenta.
La ventaja de instalarlo todo como usuario, y no como administrador, sí la tengo muy en cuenta. O la posibilidad de configurar los permisos de una aplicación. También el aislamiento, que no está presente en todas las aplicaciones, pero es un punto a favor, por más que tenga sus aristas. En ocasiones, encontrar compilaciones más completas o más pulidas es un extra, qué duda cabe. Pero si tuviera que destacar un beneficio, sería el de poder disfrutar de la misma experiencia sin importar la distribución. What else?
La entrada Flatpak ha ganado la partida es original de MuyLinux
En mi opinión, varias cosas. Algunas han cambiado, otras no. Siempre me quejé de uno de los males del modelo, como es el excesivo espacio en disco que gastan las aplicaciones instaladas debido a la cantidad de dependencias repetidas, un coste que Flatpak mitiga compartiendo entornos de ejecución y evitando duplicaciones de archivos. Todavía no ha alcanzado la eficiencia del modelo tradicional, pero se ha avanzado lo suficiente como para que no duela. A todo esto, no es imprescindible, pero tampoco está de más perder un par de minutos de vez en cuando con el mantenimiento de Flatpak.
La integración con el escritorio fue también uno de los aspectos que menos me atrajo, pero también se ha avanzado bastante con ello, de nuevo, sin tocar techo. Las integraciones profundas se siguen resistiendo y no tengo mejor ejemplo que el de KeePassXC y los navegadores: si alguien lo ha conseguido, que me lo diga (me refiero a la integración del gestor de contraseñas y el navegador, ambos en formato Flatpak o Snap… y sin hacer cosas raras).
¿Otros problemas que haya detectado con los años? La compatibilidad con el hardware se puede resentir en casos determinados. Entre las posibles causas está el aislamiento, una de las ventajas de seguridad de Flatpak y Snap frente a los paquetes tradicionales, que puede ocasionar problemas con el reconocimiento o aprovechamiento de recursos. Me ha pasado con lanzadores de juegos, software de edición multimedia… Y me ha pasado lo contrario también: encontrar mejor soporte predeterminado que el «nativo» en aplicaciones como navegadores web.
Tampoco voy a entrar en detalles técnicos, eso lo dejo para otro día. Hoy me conformo con soltar lo de que Flatpak ha ganado la partida, algo que, creo, se deduce a simple vista a poco que se esté al día. Y no reniego de Snap, ¿eh? En Ubuntu lo sigo usando, aunque sea para no perderle la pista. Pero incluso en Ubuntu necesito instalar Flatpak y, claro, Flathub, para no quedarme sin alguna de mis aplicaciones habituales: las hay que están y, además, bien mantenidas; las hay que están abandonadas y las hay que… Que no las hay, vaya.
Para que nadie me diga nada, varios ejemplos de aplicaciones populares: Heroic Games Launcher, Inkscape, OBS Studio, qBittorrent, Stremio, Upscayl, Zen Browser… La tarea de mirar cuáles están en uno u otro sitio y con qué nivel de mantenimiento, os la dejo a vosotros. ¿Hay ejemplos a la inversa? Dejádmelos en los comentarios.
Voy más allá: si antes aplicaba y recomendaba la máxima de «primero, los repositorios de la distribución», hace ya bastante que lo hago justo al revés: salvo que hablemos de aplicaciones intrínsecas del entorno de escritorio, o de aquellas que me pueden dar problemas como los ya comentados, priorizo Flatpak. Para casi todo. Y como sistema principal llevo un tiempo usando Tumbleweed, por lo que la ventaja de estar siempre actualizado ni la tengo en cuenta.
La ventaja de instalarlo todo como usuario, y no como administrador, sí la tengo muy en cuenta. O la posibilidad de configurar los permisos de una aplicación. También el aislamiento, que no está presente en todas las aplicaciones, pero es un punto a favor, por más que tenga sus aristas. En ocasiones, encontrar compilaciones más completas o más pulidas es un extra, qué duda cabe. Pero si tuviera que destacar un beneficio, sería el de poder disfrutar de la misma experiencia sin importar la distribución. What else?
La entrada Flatpak ha ganado la partida es original de MuyLinux