Cuando empiezas a trastear con Linux, uno de los conceptos que más confusión genera es la famosa variable de entorno PATH. Todo el mundo te dice eso de “añádelo al PATH”, “comprueba tu PATH” o “no te funciona porque no está en el PATH”, pero rara vez se explica con calma qué es exactamente, para qué sirve y cómo gestionarla sin liarla parda en el sistema.

En este artículo vamos a ver con todo detalle qué son las variables de entorno en Linux, qué papel juega PATH, cómo consultarla, modificarla de forma temporal o permanente, qué archivos intervienen, qué problemas típicos genera y cómo solucionarlos. La idea es que, cuando termines de leer, tengas claro qué estás tocando y por qué, sin necesidad de tragar jerga incomprensible.

Qué es una variable de entorno en Linux

Cuando hablamos de informática, una variable no es más que un nombre asociado a un valor que se guarda en memoria y que puede cambiar con el tiempo. En el contexto del sistema operativo, las variables de entorno son valores nombrados que viven en el entorno de ejecución de la shell y de los procesos, y que se usan para almacenar configuraciones, rutas, credenciales y preferencias que los programas necesitan para funcionar.

En Linux (y otros sistemas tipo Unix) estas variables forman una especie de diccionario global con pares NOMBRE=VALOR, que se pasan automáticamente a los procesos hijos cuando se ejecutan comandos o scripts desde la shell. Así, un programa puede consultar valores como el directorio personal del usuario, el idioma del sistema, la shell que se está usando o, como veremos enseguida, los directorios donde buscar ejecutables.

Las variables de entorno pueden ser locales o globales. Una variable local solo existe en la shell en la que la defines, mientras que una variable exportada se hereda a todos los subprocesos (scripts, programas, etc.) que lances desde esa shell. Además, pueden estar definidas solo para un usuario o a nivel de todo el sistema, afectando a todos los usuarios que inicien sesión.

Variables de entorno más habituales en Linux

El sistema define de serie un buen puñado de variables que conviene conocer porque se usan constantemente. Algunas de las más habituales son HOME, USER, SHELL, LANG, PWD y PATH, entre otras muchas. Todas ellas se suelen escribir en mayúsculas para distinguirlas de otras variables normales en scripts o en la shell.

Por ejemplo, la variable HOME apunta al directorio personal del usuario actual (algo como /home/juan), USER contiene el nombre del usuario que ha iniciado sesión, SHELL indica la ruta de la shell por defecto (como /bin/bash o /bin/zsh) y PWD guarda el directorio de trabajo actual, el mismo que te muestra el comando pwd.

También son importantes las variables relacionadas con el idioma y la configuración regional, como LANG o las que empiezan por LC_, que definen el conjunto de caracteres, el formato de fechas, de moneda, etc. Otro clásico es EDITOR o VISUAL, que muchas herramientas utilizan para saber qué editor de texto abrir cuando necesitas editar algo, como ocurre con crontab -e.

Qué es exactamente la variable de entorno PATH

La estrella de este artículo es la variable de entorno PATH. Esta variable contiene una lista ordenada de directorios separados por dos puntos (:) en los que el sistema buscará archivos ejecutables cuando escribes un comando en la terminal sin indicar una ruta completa. Es, literalmente, el “camino” que sigue tu shell para localizar programas.

Cuando tecleas un comando como ls o tree, en realidad estás pidiendo al sistema que ejecute un binario que vive en alguna ruta de tu disco. Gracias a la variable PATH, la shell recorre, en orden, cada directorio de esa lista hasta encontrar un archivo ejecutable con el mismo nombre que el comando que has escrito. Si lo encuentra, lo ejecuta; si no, te devuelve el clásico mensaje de command not found.

Lo habitual en muchas distribuciones es que PATH incluya rutas del estilo /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin. Cada ruta que aparece ahí es un directorio donde residen ejecutables que puedes invocar sin indicar la ruta absoluta, lo que hace la vida mucho más cómoda a la hora de trabajar en la terminal.

El orden de los directorios en PATH es crucial, porque determina la precedencia. Si existe un ejecutable con el mismo nombre en dos rutas distintas, se usará el que aparezca antes en la lista. Esto permite tener, por ejemplo, una versión alternativa de un programa en /usr/local/bin que sobrescriba la versión del sistema en /usr/bin simplemente cambiando el orden de las rutas.

Cómo ver las variables de entorno y el valor actual de PATH

Para inspeccionar las variables de entorno activas en tu sesión de shell tienes varios comandos disponibles. Uno de los más directos es env, que muestra todas las variables definidas con su formato NOMBRE=VALOR. Si ejecutas env verás una ristra de líneas entre las que aparecerán HOME, USER, SHELL, PATH, etc.

Otro comando muy usado es printenv, que también lista las variables de entorno pero resulta especialmente útil para consultar una sola variable concreta. Si escribes printenv PATH, la salida será únicamente el valor actual de la variable PATH, lo que te permite ver de un vistazo qué directorios contiene y en qué orden están colocados.

Además, puedes recurrir al comando echo junto al signo de dólar para mostrar el contenido de cualquier variable. Por ejemplo, echo $USER mostrará tu nombre de usuario, y echo $PATH te enseñará la lista completa de directorios por los que el sistema irá buscando ejecutables separados por dos puntos. Esta sintaxis con $NOMBRE es la que se usa habitualmente también en scripts.

Cómo saber dónde está un comando en el sistema

Saber que un comando está en el PATH está muy bien, pero a veces necesitas averiguar su ruta exacta en el sistema de archivos. Para eso tienes comandos como which y whereis, que te indican dónde se encuentra físicamente el binario que se ejecuta cuando llamas a un comando.

Si ejecutas, por ejemplo, which tree, la salida típica será algo como /usr/bin/tree, lo que te indica que el ejecutable reside en ese directorio, que a su vez está incluido en tu variable PATH. Por su parte, el comando whereis es un poco más completo y puede mostrar la ruta al binario y también la ubicación de sus páginas de manual y otros archivos relacionados.

Esta información es muy útil cuando sospechas que se está ejecutando una versión de un programa distinta a la que creías o cuando estás depurando problemas relacionados con rutas y precedencia en PATH. Ver exactamente qué binario se está llamando evita más de un quebradero de cabeza.

Cómo ejecutar scripts shell y relación con PATH

Los scripts de shell suelen guardar su código en archivos con extensión .sh, aunque no es obligatorio. Para ejecutarlos puedes hacerlo de dos formas: indicando la ruta explícita o confiando en que el script esté en un directorio incluido en PATH. Si el script está en tu directorio actual, una forma clásica es usar ./mishcript.sh.

Si quieres llamar al script sin poner la ruta completa, lo ideal es guardarlo en un directorio que esté dentro del PATH, como ~/bin (si lo añades), /usr/local/bin u otro directorio de binarios. También puedes crear archivos .desktop para lanzar aplicaciones sin tocar el PATH. De esta forma bastará con teclear el nombre del script, siempre que tenga permisos de ejecución y el intérprete correcto indicado en la primera línea (la famosa shebang, tipo #!/bin/bash).

Algo importante es la diferencia entre ejecutar un script con ./script.sh y con source script.sh. En el primer caso se crea un subproceso que hereda tus variables de entorno pero que no devuelve los cambios que haga sobre ellas; en el segundo, el script se ejecuta en tu shell actual, por lo que puede modificar directamente variables como PATH y esos cambios se quedarán activos en tu sesión.

Cómo crear y modificar variables de entorno en Linux

La forma básica de crear o ajustar una variable de entorno en Bash es usar el comando export. La sintaxis típica es export NOMBRE="valor", donde defines el valor y lo marcas como exportable a los procesos hijos. Por ejemplo, podrías hacer export MI_VARIABLE="HolaMundo" y luego comprobarlo con echo $MI_VARIABLE.

Si defines una variable sin export (por ejemplo, MI_VAR=algo), esta existirá en tu shell pero no se propagará a los programas o scripts que ejecutes. En cambio, usando export garantizas que cualquier proceso hijo pueda leer esa variable, lo que es clave cuando quieres que tus aplicaciones accedan a configuraciones como credenciales, rutas de proyecto o parámetros de zona horaria.

Para revertir o eliminar una variable de entorno, se usa el comando unset. Con unset VAR eliminas la variable VAR del entorno actual, lo que implica que dejará de estar disponible para nuevos subprocesos. Por ejemplo, si haces unset TZ después de haber tocado la variable TZ, el sistema volverá a su comportamiento de zona horaria por defecto al consultar de nuevo la hora con date.

Cómo modificar la variable PATH (cambios temporales)

Modificar la variable PATH de forma temporal, es decir, solo para la sesión de terminal actual, es tan sencillo como construir un nuevo valor a partir del existente. Una práctica común es añadir un nuevo directorio al final o al principio de la lista de rutas, según la prioridad que quieras darle a esos ejecutables.

Para añadir una ruta al final de PATH podrías hacer algo como export PATH="$PATH:/home/usuario/scripts". De este modo no pierdes el contenido existente, simplemente encadenas tu nuevo directorio al final de la lista. A partir de ese momento podrás ejecutar cualquier script o binario que haya en /home/usuario/scripts sin escribir la ruta completa.

Si, por el contrario, quieres que esa nueva ruta tenga prioridad sobre las demás, puedes insertarla al principio haciendo export PATH="/home/usuario/scripts:$PATH". Así, si existe un ejecutable con el mismo nombre en tu carpeta de scripts y en /usr/bin, se utilizará el de tu carpeta personal al estar su ruta por delante.

También es posible reemplazar por completo el valor de PATH definiéndolo desde cero, por ejemplo, export PATH="/usr/local/bin:/usr/bin:/bin". Esto es delicado, porque si dejas fuera rutas críticas puedes hacer que el sistema no encuentre comandos básicos. Además, todos estos cambios hechos en la terminal son temporales: en cuanto cierres la sesión de shell, se perderán y al volver a abrir una terminal se cargará la configuración estándar.

Cómo configurar PATH y otras variables de entorno de forma permanente

Si quieres que un cambio en PATH (o en cualquier otra variable de entorno) se mantenga cada vez que abras una terminal, debes definirlo en los archivos de inicio de la shell. En Bash, lo más habitual es usar ~/.bashrc para shells interactivas, y ~/.bash_profile o ~/.profile para shells de login. En Zsh, el equivalente más común es ~/.zshrc.

La idea típica es editar tu archivo de configuración con un editor de texto y añadir una línea en la que ajustes la variable. Por ejemplo, podrías abrir tu ~/.bashrc con nano o vim y añadir al final algo como export PATH="$PATH:/opt/tacata". Guardas el archivo, ejecutas source ~/.bashrc para recargar la configuración y, desde ese momento, el directorio /opt/tacata quedará incluido siempre en tu PATH.

Además de los archivos personales, existen ficheros de configuración globales que afectan a todos los usuarios del sistema. Entre los más comunes están /etc/profile, el directorio /etc/profile.d/, /etc/bashrc o /etc/bash.bashrc, y en algunos casos el archivo /etc/environment. Modificar estos archivos requiere permisos de administrador y hay que hacerlo con cuidado, porque un error puede dejar a todos los usuarios con un entorno roto.

Es importante entender también el orden en que se cargan estos archivos. Dependiendo de si se trata de una shell de login o no, Bash puede leer primero los archivos globales, luego ~/.bash_profile o ~/.profile, y finalmente ~/.bashrc. Si pones una exportación en un archivo que tu sesión actual no carga, el cambio no surtirá efecto. Por eso es habitual definir las personalizaciones de PATH en ~/.bashrc en entornos de escritorio.

Variables locales, globales y herencia a subprocesos

Al trabajar con la shell conviene distinguir entre variables locales y de entorno. Una variable local es aquella que defines en la shell sin exportarla, por ejemplo local_var=edward. Esta variable es visible solo dentro de esa instancia de shell y no se pasa a los procesos que ejecutes.

Cuando usas export, conviertes la variable en una variable de entorno global dentro de tu sesión. Por ejemplo, si haces export GLOBAL_VAR="Hola" y luego ejecutas echo $GLOBAL_VAR, verás el valor, y cualquier script o programa lanzado desde esa shell también tendrá acceso a GLOBAL_VAR. Es esta herencia la que hace que la configuración del entorno se propague a tus aplicaciones.

La herencia, sin embargo, es unidireccional: un subproceso recibe una copia del entorno de su padre, pero los cambios que haga en sus variables no vuelven al proceso de origen. Por eso, si quieres que un script modifique tu PATH de forma persistente en tu sesión, debes ejecutarlo con source (o .) en lugar de lanzarlo como un comando independiente.

Uso de archivos .env y configuración por entorno

En muchos proyectos de desarrollo, sobre todo en aplicaciones web y microservicios, se recurre a archivos .env para centralizar la configuración. Estos archivos suelen contener líneas con el formato NOMBRE=VALOR, por ejemplo DB_HOST=localhost o API_KEY=xxxxxxxx, y luego alguna herramienta o librería se encarga de cargarlos en las variables de entorno de la aplicación.

Este enfoque permite separar claramente el código fuente de la configuración sensible, como credenciales de bases de datos o claves de API, evitando que acaben en repositorios públicos. Cada entorno (desarrollo, pruebas, producción) puede tener su propio archivo .env con valores distintos, lo que da mucha flexibilidad a la hora de desplegar la misma aplicación en contextos diferentes.

Es fundamental, eso sí, controlar los permisos y la ubicación de estos archivos, ya que contienen información delicada. Lo habitual es añadirlos al .gitignore para que no se suban nunca al control de versiones, y restringir su lectura en el servidor para que solo el usuario que ejecuta la aplicación pueda acceder a ellos.

Buenas prácticas al manejar PATH y otras variables de entorno

El manejo de variables de entorno parece trivial, pero una mala gestión puede traer problemas difíciles de depurar. Una buena costumbre es utilizar nombres descriptivos cuando creas variables propias, como DB_USER, REDIS_PORT o PROJECT_ROOT, evitando siglas crípticas o nombres genéricos que nadie recuerda al cabo de un tiempo.

Con PATH en particular, es fácil caer en el vicio de ir añadiendo rutas sin control hasta que la variable se convierte en una cadena interminable. Esto no solo la hace más difícil de leer, también puede causar conflictos si hay ejecutables duplicados en distintas rutas. Mantener un PATH razonablemente corto y bien organizado reduce errores y simplifica el diagnóstico cuando algo falla.

Otra recomendación clave es documentar qué variables de entorno utiliza un proyecto y qué significado tiene cada una. Incluir en el repositorio un archivo de ejemplo (como .env.example) o una sección en el README con la lista de variables esperadas ayuda a que otros desarrolladores (o tú mismo en el futuro) entiendan rápidamente cómo configurar el entorno correcto.

Problemas habituales relacionados con PATH y cómo depurarlos

Uno de los fallos más comunes en Linux es el típico “command not found” cuando intentas ejecutar un programa que sabes que está instalado. En muchos casos, el problema es que el directorio donde se encuentra el ejecutable no está incluido en PATH, o lo está con un valor antiguo, o directo y llanamente has sobrescrito la variable por error.

Para depurar este tipo de situaciones puedes empezar con echo $PATH para comprobar qué rutas se están usando. A continuación, usar whereis comando o which comando te indicará si el ejecutable existe y dónde está. Si la ruta devuelta por estos comandos no aparece en tu PATH, ya tienes identificado el problema: tendrás que añadir ese directorio a la variable, ya sea de forma temporal con export o de forma permanente en tus archivos de configuración.

Otro clásico son los errores tipográficos al modificar la variable. Escribir PAT en lugar de PATH o dejarte un dos puntos entre rutas puede hacer que el sistema deje de encontrar comandos básicos. Siempre que toques PATH conviene volver a mostrárselo con echo $PATH y revisar que no falta nada y que las rutas aparecen separadas correctamente.

Por último, hay que mencionar los conflictos que pueden surgir al editar archivos como /etc/environment o /etc/profile. Si sobrescribes PATH a nivel de sistema sin tener en cuenta lo que definen paquetes y servicios, puedes romper el entorno de todos los usuarios. Hacer una copia de seguridad de esos archivos antes de modificarlos es casi obligatorio para poder deshacer cambios si algo sale mal.

Variables de entorno y seguridad

Las variables de entorno se usan a menudo para guardar credenciales y datos sensibles, precisamente para evitar que aparezcan directamente en el código. Sin embargo, esto no significa que sean un lugar completamente seguro: cualquier usuario o proceso con acceso al entorno puede verlas usando comandos como env o printenv, o mediante herramientas de depuración.

Para reducir riesgos, conviene limitar los permisos de lectura sobre los archivos donde se definen estas variables, como .bashrc o los archivos .env, de modo que solo el usuario adecuado pueda consultarlos. Comandos como chmod 600 archivo ayudan a garantizar que terceros no autorizados no puedan leer configuraciones delicadas.

También hay que tener cuidado con que las aplicaciones no vuelquen su entorno en los logs cuando se produce un error. Si un servicio imprime todo su entorno al fallar, podría dejar claves de API o contraseñas expuestas en los registros del sistema. Revisar el comportamiento por defecto de tus herramientas y filtrar información antes de loguearla es una buena capa extra de protección.

El papel de PATH y las variables de entorno en CI/CD y contenedores

En entornos modernos de integración continua (CI) y despliegue continuo (CD), así como en sistemas basados en contenedores, casi toda la configuración se hace a través de variables de entorno. Es habitual que, al lanzar un contenedor, se pasen valores como la URL de la base de datos, usuarios, contraseñas o modos de ejecución mediante opciones de la herramienta de contenedores.

En estos escenarios, la variable PATH también es clave para que dentro del contenedor se puedan ejecutar sin problemas las herramientas y binarios necesarios. Las imágenes suelen definir su propio PATH interno, y en algunos casos es necesario ajustarlo cuando instalas componentes adicionales que deben ser accesibles desde cualquier punto.

Las plataformas de CI/CD, además, permiten definir variables de entorno por proyecto, por job o por entorno (staging, producción, etc.). Esto encaja perfectamente con la filosofía de separar código y configuración, y facilita reutilizar el mismo artefacto de compilación cambiando solo las variables que se inyectan en tiempo de ejecución.

Dominar el manejo de PATH y del resto de variables de entorno en Linux te permite entender qué está pasando realmente cuando ejecutas un comando, cómo se configura tu entorno de trabajo, dónde se definen las preferencias del sistema y cómo hacer que tus scripts y aplicaciones sean más portables, seguras y fáciles de mantener; a partir de ahí, ajustar rutas, añadir ejecutables o diagnosticar por qué algo “no se encuentra” deja de ser magia negra y pasa a ser una cuestión de revisar qué hay definido en tu entorno y de qué forma se está heredando.

En un mercado de móviles cada vez más homogéneo, la llegada del nuevo Jolla Phone supone un giro curioso para quienes buscan algo distinto a los clásicos Android o iPhone. Este dispositivo, impulsado por la finlandesa Jolla, recupera la idea de un smartphone europeo con sistema propio y apuesta fuerte por la privacidad, el control del usuario y la posibilidad de reparar y mantener el terminal durante más tiempo.

La compañía, con raíces en el antiguo proyecto MeeGo de Nokia, ha pasado años centrada en el software, pero ahora vuelve al hardware con un teléfono que se ha diseñado prácticamente de la mano de su comunidad. El nuevo Jolla Phone combina Sailfish OS 5 basado en Linux, un hardware de gama media-alta y funciones muy poco habituales hoy en día, como la batería extraíble o un interruptor físico para desactivar cámara y micrófono.

Un smartphone europeo que quiere ir por libre

Jolla presenta este terminal como la única opción europea construida sobre su propio sistema operativo, Sailfish OS 5, sin depender de Android ni iOS. La idea es ofrecer una alternativa independiente a las grandes plataformas de Apple, Google y Huawei, de forma que los datos de los usuarios no pasen sistemáticamente por sus servidores ni se sometan a sus políticas de seguimiento y analítica.

La firma remarca que Sailfish OS 5 es un «Linux real» y no una variante de Android, con un enfoque claro en evitar el envío de información en segundo plano. Según la compañía, el sistema no incorpora rastreos ni estadísticas ocultas y no exige disponer de cuenta de Google para usar las funciones principales del teléfono, algo poco habitual en la mayoría de dispositivos actuales.

Sailfish OS 5: privacidad primero, pero con apps de Android

El corazón del nuevo móvil es Sailfish OS 5, la última versión del sistema operativo de Jolla. La plataforma combina componentes de código abierto y partes propietarias, con la promesa de respetar al máximo la privacidad del usuario. El objetivo es que el teléfono pueda utilizarse en el día a día sin que haya envíos de datos invisibles a terceros ni analíticas forzadas.

Al mismo tiempo, Jolla es consciente de que el ecosistema de aplicaciones es clave. Por eso, el sistema incluye la tecnología AppSupport, que permite ejecutar aplicaciones de Android en el Jolla Phone. De esta forma, apps bancarias, servicios de mensajería o herramientas de uso cotidiano pueden funcionar sin necesidad de integrar los servicios de Google ni Google Play, recurriendo a tiendas de terceros o repositorios alternativos.

Lo interesante es que esta compatibilidad es totalmente opcional y se puede desactivar. El usuario puede elegir un uso «desgooglificado», prescindir por completo del subsistema Android o activar y desactivar esa capa cuando la necesite, algo que encaja con el enfoque de control total sobre el dispositivo.

Diseño sobrio, modular y pensado para durar

El nuevo Jolla Phone apuesta por un diseño de líneas rectas, con esquinas marcadas y una pantalla con notch tipo «ceja» que recuerda a los primeros iPhone con este recorte y, en cierto modo, a los antiguos Lumia de Nokia. No busca un aspecto extravagante, sino una estética sencilla y funcional, reforzada con Gorilla Glass para proteger el frontal.

Uno de los detalles más llamativos es la carcasa trasera reemplazable. El teléfono permite cambiar la tapa posterior de forma sencilla, tanto por motivos estéticos como de mantenimiento. Jolla ofrecerá cubiertas en varios colores, entre ellos Kaamos Black (negro), Snow White (blanco) y The Orange (naranja), de manera que el usuario pueda personalizar el aspecto del dispositivo sin necesidad de fundas voluminosas.

La modularidad no se queda en la tapa. El terminal incorpora una batería extraíble por el usuario, algo que prácticamente ha desaparecido del mercado de gama media y alta. Esta decisión encaja con la idea de alargar la vida útil del teléfono: cuando la batería se degrade, bastará con sustituirla, sin pasar por un servicio técnico ni cambiar de móvil antes de tiempo.

Pantalla AMOLED y hardware de gama media-alta

En el apartado técnico, el Jolla Phone monta una pantalla AMOLED de 6,36 pulgadas con resolución Full HD+ y formato 20:9. La densidad ronda los 390 píxeles por pulgada, suficientes para ofrecer una buena nitidez en textos e imágenes. La pantalla está protegida por cristal Gorilla Glass, aunque la marca no ha detallado la tasa de refresco, por lo que todo apunta a una configuración estándar más que a paneles de alta frecuencia pensados para juegos.

El procesador elegido es un chip MediaTek con conectividad 5G, cuya referencia exacta aún no se ha hecho pública. Se trata de un SoC de alto rendimiento dentro de la gama media, acompañado por 12 GB de memoria RAM y 256 GB de almacenamiento interno. Este espacio se puede ampliar mediante tarjetas microSDXC, llegando hasta capacidades de hasta 2 TB según algunas especificaciones adelantadas por la compañía.

En cuanto a comunicaciones, el nuevo Jolla Phone incluye 5G y 4G LTE con soporte de roaming global, además de WiFi 6, Bluetooth 5.4 y NFC. El móvil también ofrece doble ranura nano SIM, permitiendo usar dos líneas telefónicas de forma simultánea, algo práctico para combinar número personal y profesional o alternar entre operadores.

Cámaras y enfoque fotográfico

El sistema de cámaras está formado por un módulo trasero doble y una lente frontal para selfies. En la parte posterior se encuentra un sensor principal de 50 megapíxeles, acompañado por un ultra gran angular de 13 megapíxeles para capturar escenas más amplias, paisajes o interiores. El fabricante no ha especificado todos los detalles de apertura o estabilización, pero la configuración apunta a un rendimiento sólido dentro de la gama media.

En el frontal, alojada en el notch superior, hay una cámara gran angular pensada para videollamadas y selfies. Aunque Jolla no ha concretado la resolución, sí subraya que la lente ofrece un campo de visión más amplio de lo habitual, de modo que pueda encuadrar a varias personas sin necesidad de estirar el brazo al máximo.

Batería extraíble y apuesta por la reparabilidad

Uno de los puntos más diferenciadores del Jolla Phone es su batería de gran capacidad, en torno a los 5.500 mAh, diseñada para ofrecer una autonomía generosa. Dependiendo de la fuente, la cifra publicada oscila ligeramente entre 5.400 y 5.500 mAh, pero todas coinciden en que se trata de una batería notablemente amplia para un terminal de este segmento.

Además de la capacidad, lo relevante es que la batería es reemplazable por el usuario sin herramientas complejas. Esto permite cambiarla cuando pierda rendimiento, llevar una segunda unidad para jornadas muy largas sin acceso a cargador, o prolongar la vida del teléfono varios años más, un punto que Jolla vincula a la sostenibilidad y a su política de soporte prolongado de Sailfish OS, que se plantea en ciclos de alrededor de cinco años.

Interruptor físico de privacidad y seguridad avanzada

El elemento estrella del hardware es el interruptor de privacidad físico situado en el lateral del chasis. A diferencia de simples accesos directos por software, este control está pensado para desactivar de manera inmediata componentes sensibles como el micrófono, las cámaras o el Bluetooth, reduciendo al mínimo la posibilidad de que el dispositivo «escuche» o «mire» cuando el usuario no quiere.

Jolla explica que este interruptor es configurable, de forma que cada persona decide qué funciones se apagan al accionarlo. Entre las opciones se incluyen micrófonos, cámara, conectividad Bluetooth e incluso la compatibilidad con apps de Android. En algunos documentos de la compañía se matiza que, aunque el mecanismo se opera mediante un botón físico, parte de la desactivación se gestiona por software, manteniendo un cierto equilibrio entre seguridad y flexibilidad de uso.

El terminal también integra un sensor de huellas dactilares en el botón de encendido lateral, lo que facilita el desbloqueo rápido con una sola mano. A ello se suma un LED RGB de notificaciones, cada vez menos habitual en móviles modernos, que permite ver de un vistazo si hay mensajes o avisos pendientes sin encender la pantalla.

Fabricación en Finlandia y enfoque europeo

Jolla subraya que el ensamblaje final del Jolla Phone, la instalación del software y el control de calidad se realizan en Salo (Finlandia). Con ello, la compañía quiere reforzar el mensaje de que Europa todavía puede producir su propia tecnología bajo sus propias reglas, sin depender por completo de la cadena de suministro asiática para todas las fases del producto.

El presidente del consejo de Jolla Group Oy, Antti Saarnio, ha señalado que este móvil responde a la necesidad de que Europa desarrolle y mantenga su propio ecosistema tecnológico. La empresa anima a otras firmas europeas a sumarse a esta iniciativa para construir un entramado digital menos dependiente de plataformas externas, tanto en software como en hardware.

Reservas, precio y disponibilidad en Europa

El lanzamiento del nuevo Jolla Phone se está gestionando mediante una campaña de reservas que funciona casi como un crowdfunding parcial. Para que el dispositivo entre en producción en serie, la compañía fijó un mínimo de 2.000 depósitos de 99 euros antes del 4 de enero de 2026. Esa cifra ya se ha superado, con más de 2.000 unidades reservadas en pocos días, lo que ha animado a Jolla a abrir un segundo lote de preventa limitado.

Quienes reserven el teléfono deben abonar 99 euros como depósito y 399 euros adicionales antes del envío, lo que deja el precio anticipado en 499 euros. Este importe es inferior al precio de venta al público previsto, que la compañía sitúa en una horquilla aproximada de entre 599 y 699 euros una vez que el dispositivo llegue al canal normal.

En cuanto a la distribución, el Jolla Phone se dirigirá en primer lugar a países de la Unión Europea, Reino Unido, Noruega y Suiza, con un calendario de entregas estimado para la primera mitad de 2026. Jolla deja la puerta abierta a ampliar la disponibilidad a otros mercados, incluidos Estados Unidos, si la demanda y el interés lo justifican.

Un móvil de nicho para quienes quieren control y privacidad

El nuevo Jolla Phone no pretende competir con los grandes superventas Android en precio ni en cifras brutas de rendimiento, sino ofrecer un dispositivo de nicho para usuarios que priorizan privacidad, control y reparabilidad. Combina un hardware competente de gama media-alta, un sistema operativo europeo independiente y una serie de elementos poco frecuentes hoy en día, como la batería extraíble o el interruptor físico de privacidad.

Para quienes viven en España o en el resto de Europa y buscan escapar del binomio Android-iOS sin renunciar a las aplicaciones esenciales, este terminal se perfila como una opción particular: más cara que otros móviles con especificaciones similares, pero con un valor añadido en forma de soberanía de datos, soporte prolongado y diseño pensado para durar varios años sin quedar obsoleto a las primeras de cambio.

ShaniOS se ha colado en la conversación sobre distros inmutables casi sin hacer ruido, pero con argumentos muy sólidos: seguridad elevada, actualizaciones atómicas y una experiencia bastante pulida tanto en GNOME como en KDE Plasma. Si vienes de Windows o de una distro Linux clásica, puede sonar a ciencia ficción eso de que “el sistema no se rompe”, pero aquí la idea va precisamente por ahí.

Lo interesante es que ShaniOS combina una base Arch Linux con un planteamiento moderno: sistema de doble raíz azul/verde sobre Btrfs, raíz de solo lectura con capas escribibles, actualizaciones gestionadas por un comando propio y aplicaciones aisladas mediante Flatpak. Todo ello envuelto en un instalador en vivo agradable (con Sway) y un sistema final pensado tanto para uso doméstico como para equipos OEM.

Qué es ShaniOS y por qué se habla de un sistema inmutable

En pocas palabras, ShaniOS es una distribución basada en Arch Linux diseñada como sistema inmutable. Eso significa que la parte “gorda” del sistema (la raíz con el sistema operativo) no se toca mientras lo usas. No puedes ir instalando y desinstalando paquetes del sistema a lo loco con pacman, y esto no es una limitación gratuita: es la base de su estabilidad.

Un sistema inmutable como ShaniOS ofrece más estabilidad, menos sorpresas y una superficie de ataque más reducida. Al no permitir cambios arbitrarios en la raíz durante la ejecución, se evitan muchas roturas típicas de “he actualizado algo y ahora no arranca” o “he tocado un paquete crítico y lo he dejado KO”.

La pregunta que mucha gente se hace es si lo inmutable es “el futuro” o una moda pasajera. Distribuciones como Fedora Silverblue o variantes atómicas llevan tiempo empujando este concepto, y ShaniOS se suma a esa corriente, pero con su propia personalidad basada en Arch, Btrfs y Flatpak.

Arquitectura azul/verde con subvolúmenes Btrfs

Una de las piezas clave de ShaniOS es su estrategia azul/verde apoyada en subvolúmenes Btrfs. En vez de tener un único sistema raíz, mantiene dos raíces completas: una azul y otra verde. En cada momento arrancas desde una de ellas, mientras la otra queda en reserva para las actualizaciones.

Cuando arrancas, por ejemplo, en la raíz azul, el sistema marca la ranura azul como activa y la verde como inactiva. Al ejecutar el comando de actualización, la nueva versión del sistema se despliega en la ranura inactiva (verde). De esta forma, todo el proceso se hace “por detrás” sin tocar el sistema con el que estás trabajando.

Tras completar la actualización, se actualizan las entradas de arranque para que el siguiente reinicio lo hagas desde la ranura recién actualizada. Si todo va bien, empiezas a utilizar el nuevo sistema; si algo sale mal o no te convence, puedes volver a la raíz anterior de forma prácticamente instantánea gracias a esa doble estructura.

Este enfoque se apoya de manera intensa en las capacidades de Btrfs: subvolúmenes, instantáneas y copy-on-write. La distro organiza la raíz azul y verde como subvolúmenes separados, permitiendo mantener dos estados completos, eficientes en espacio y fáciles de gestionar para reversión y recuperación.

ShaniOS es un sistema de solo lectura y capas escribibles

Para conseguir que el sistema sea realmente inmutable, ShaniOS utiliza una imagen base de Arch Linux generada con pacstrap en modo solo lectura. Esa capa contiene el corazón del sistema: kernel, librerías principales y utilidades base.

Encima de esa base, la distribución monta varias capas escribibles con overlays y tmpfs. Destaca el overlay sobre /etc, que permite que puedas modificar configuraciones del sistema (red, servicios, preferencias de sistema, etc.) sin alterar nunca la imagen base. Esas modificaciones se guardan de forma persistente, pero separadas de la raíz inmutable.

Por otra parte, /var se gestiona como tmpfs a través de systemd.volatile, lo que mantiene los datos de tiempo de ejecución en memoria y evita que ensucien la raíz del sistema. Además, se hace un uso intensivo de subvolúmenes e instantáneas Btrfs para facilitar restauraciones y mantener la integridad del sistema con el mínimo esfuerzo.

Seguridad y diseño de un sistema inmutable

Más allá de la arquitectura de almacenamiento, ShaniOS integra un conjunto de medidas de seguridad pensadas para minimizar riesgos. Aunque el detalle fino de cada perfil no siempre se destaca en las reseñas, se menciona el uso de AppArmor y una configuración de firewalld que viene lista para proteger el sistema desde el primer arranque.

La inmutabilidad en sí misma funciona como un escudo adicional: al no poder modificar la raíz en ejecución, se complica mucho que un atacante cambie binarios del sistema, añada servicios persistentes o manipule componentes críticos. Esta filosofía se complementa con el soporte de cifrado completo de disco, de forma que no solo el sistema es difícil de romper, sino que tus datos están a salvo si pierdes el equipo.

En el arranque, ShaniOS apuesta por systemd-boot y entorno UEFI nativo. Esta combinación favorece una experiencia moderna, con tiempos de arranque rápidos y una gestión más sencilla de las entradas de arranque, especialmente importante cuando se manejan dos raíces y múltiples imágenes de kernel.

Requisitos de ShaniOS y compatibilidad de hardware

Instalar ShaniOS no requiere una máquina de gama alta, pero sí hay unos mínimos razonables para disfrutarlo con soltura. En general, se recomienda disponer de al menos 4 GB de RAM y 64 GB de espacio libre en disco, sobre todo porque la filosofía de doble sistema ocupa más que una instalación tradicional.

En cuanto al procesador, cualquier equipo de 64 bits relativamente moderno suele ser compatible. Lo mismo ocurre con la tarjeta gráfica: la experiencia en vivo y el sistema instalado están pensados para funcionar en prácticamente cualquier GPU de la última década, incluyendo soporte optimizado para controladores NVIDIA-Open preinstalados, lo que es un guiño directo a quienes usan hardware NVIDIA.

Eso sí, conviene tener en cuenta que ShaniOS está pensado para funcionar mejor en hardware físico. Se puede usar en máquinas virtuales, pero la experiencia de sistema inmutable, con su cifrado y su despliegue azul/verde, brilla más cuando se instala en un equipo real. En el mundo UEFI, además, se enfatiza el uso de systemd-boot como gestor, maximizando compatibilidad con placas actuales.

Preparación previa: BIOS/UEFI y medio de instalación

Antes de ponerte a instalar, es importante preparar bien el equipo. ShaniOS recomienda desactivar opciones como Fast Boot y Secure Boot en la BIOS o UEFI de tu ordenador. Estas funciones, aunque prácticas en otros contextos, pueden interferir con el arranque desde el USB o con el despliegue del sistema.

También es aconsejable activar el modo AHCI para el controlador SATA y forzar el arranque en modo UEFI puro si tu firmware lo permite. Este tipo de ajustes suelen mejorar tanto el rendimiento de los discos como la compatibilidad general con el esquema de particionado y el arranque que utiliza ShaniOS.

Respecto al medio de instalación, la documentación es bastante clara: hay que crear el USB con herramientas como Balena Etcher, Rufus o usando dd directamente. Se especifica que no se use Ventoy, porque la ISO de ShaniOS no termina de llevarse bien con ese método y puede que simplemente no arranque. En resumen, un USB de 8 GB o más y una herramienta clásica de grabación son la apuesta segura.

Acceso al sistema en vivo e instalador de ShaniOS

Cuando arrancas desde el USB, ShaniOS ofrece un entorno en vivo con Sway como interfaz principal. Esta elección da una sensación moderna y ligera, permitiendo probar parte de la experiencia antes de comprometer el disco duro. Desde ahí se lanza el instalador gráfico, que guía las decisiones principales (discos, cifrado, escritorio, etc.).

Si necesitas iniciar sesión en ese entorno en vivo, se proporciona un usuario y contraseña muy sencillos. Ambos suelen ser “shani” tanto para el nombre de usuario como para la contraseña, lo que te permite entrar sin complicaciones y empezar a explorar o lanzar el instalador.

El instalador se ha diseñado para que funcione en un amplio abanico de hardware sin necesidad de trucos. La idea es que, en unos 20 minutos aproximadamente, puedas pasar del USB al sistema instalado y operativo, con la doble raíz ya preparada y el escritorio que hayas elegido listo para la configuración inicial.

Instalación del sistema y escritorios disponibles

Una vez dentro del entorno en vivo, el flujo de instalación es relativamente directo. La herramienta prepara el disco, crea los subvolúmenes Btrfs necesarios y despliega la imagen base. El tiempo de instalación puede rondar los 15-20 minutos, aunque hay experiencias de usuarios que reportan cifras cercanas a los 7-8 minutos cuando el equipo y el disco son rápidos.

Tras esa fase, ShaniOS se presenta con dos opciones de entorno de escritorio principales: GNOME y KDE Plasma. La edición GNOME está muy orientada al uso OEM, incorporando gnome-initial-setup preconfigurado para que el primer arranque permita personalizar idioma, cuenta de usuario y opciones básicas con un estilo muy fluido.

Por su parte, la edición KDE Plasma no se limita al tema por defecto. Los desarrolladores han retocado la apariencia para darle una identidad propia, moviendo por ejemplo el menú principal a la esquina superior izquierda y afinando detalles estéticos. Visualmente recuerda a una mezcla entre Windows y macOS, con una barra atractiva y ventanas modernas.

Gestión de software en ShaniOS: Flatpak como pilar principal

Una de las decisiones más polémicas, pero coherentes con el modelo inmutable, es que ShaniOS delega la instalación de aplicaciones de usuario casi por completo en Flatpak. El sistema base se mantiene congelado y las apps se distribuyen de forma aislada, cada una con sus dependencias dentro de un contenedor.

Esta aproximación tiene ventajas claras: las actualizaciones de aplicaciones son independientes del sistema, no rompes nada de la raíz, puedes tener varias versiones y, en general, el sistema sigue estable aunque una app falle. Además, la integración con GNOME Software o KDE Discover hace que instalar programas gráficos sea cuestión de unos clics.

No todo el mundo es fan de Flatpak. Hay quienes se quejan de que muchos Flatpaks no respetan del todo el tema visual del sistema o se ven “diferentes” en 2025, y a algunos usuarios les molesta depender solo de este sistema para instalar aplicaciones. Sin embargo, en el contexto de una distro inmutable como ShaniOS, este sacrificio tiene sentido: se prioriza integridad y reversibilidad frente a la flexibilidad absoluta de un gestor de paquetes clásico.

Entre las aplicaciones que vienen de serie destacan Vivaldi como navegador predeterminado (con VPN y bloqueador de anuncios integrados), OnlyOffice como alternativa a Microsoft Office, Warehouse para la gestión de Flatpaks, KolourPaint para ediciones sencillas de imagen y Pods para manejar contenedores. Desde Discover puedes completar el catálogo con prácticamente cualquier software que necesites.

Actualizaciones atómicas con shani-deploy

El componente estrella para mantener el sistema al día es el comando shani-deploy, la herramienta oficial de actualizaciones del sistema. Es fundamental interiorizar que aquí no se usa pacman directamente para tocar la base; las actualizaciones del sistema se hacen siempre con este comando, que gestiona el despliegue azul/verde de forma segura.

Cuando ejecutas sudo shani-deploy, la herramienta arranca una serie de pasos bien definidos. Primero comprueba que se está ejecutando como root y que hay conexión a internet. Después activa mecanismos para evitar suspensiones o apagados durante la actualización, y valida que el arranque actual corresponde al subvolumen esperado.

A continuación, consulta el canal de actualizaciones configurado para obtener información de la versión más reciente, descarga la imagen correspondiente, verifica su integridad y la despliega en el subvolumen inactivo (por ejemplo, el verde si estás en el azul). El proceso también genera y firma una nueva Unified Kernel Image (UKI), actualiza las entradas del bootloader y migra configuraciones persistentes necesarias (como el overlay de /etc).

Antes de dar la actualización por buena, se realizan validaciones de integridad en el nuevo subvolumen. Al terminar, se te suele informar de que conviene probar las aplicaciones tras el reinicio, asegurarse de que todo responde como toca y, si es el caso, volver a ejecutar la herramienta para completar el ciclo entre azul y verde.

Algunos usuarios han comentado experiencias prácticas en las que, tras actualizar desde el entorno azul, reinician en verde, crean archivos en Documentos y al volver a lanzar shani-deploy reciben avisos sobre desajustes de arranque. En estos casos, seguir las recomendaciones (probar apps, reiniciar, dejar que el sistema sincronice de nuevo azul y verde) suele resolver la situación sin mayor drama.

Rendimiento y experiencia en el día a día con ShaniOS

Quienes han probado ShaniOS destacan que el rendimiento es uno de sus puntos fuertes. A pesar de la complejidad interna de doble raíz, overlays y capas, el sistema se siente ágil y fluido. En comparación con otras distros inmutables, hay opiniones que señalan que ShaniOS se comporta mejor y con menos fricción en el uso cotidiano.

En entornos como KDE Plasma, la personalización visual y la disposición de la interfaz consiguen una experiencia amigable incluso para usuarios que vienen de Windows. La barra estilo dock y las ventanas modernas proporcionan una transición más suave para quien busca algo distinto pero reconocible.

Al tratarse de una distro basada en Arch, el soporte de hardware moderno suele ser muy bueno. Ejemplos de equipos con CPUs recientes de Intel, GPUs NVIDIA de última generación y almacenamiento NVMe rápido funcionan sin problemas en ShaniOS, siempre que la instalación se realice sobre un disco adecuado y no sobre unidades que el instalador aún no maneje bien (como ciertos SSD USB externos donde algunos usuarios han reportado dificultades).

Limitaciones, dual boot y pequeños escollos

No todo son ventajas y conviene conocer las advertencias oficiales. La propia documentación de ShaniOS desaconseja el dual boot. El motivo es sencillo: otros sistemas operativos pueden sobreescribir el gestor de arranque o modificar la configuración UEFI, rompiendo el esquema azul/verde y complicando el arranque de ShaniOS.

Tampoco es oro todo lo que reluce con el instalador: hay usuarios que han intentado instalar la distro en unidades USB M.2 externas y se han topado con errores al formatear o seleccionar particiones, incluso después de reformatear en Btrfs o dejar el disco completamente vacío. Son casos concretos, pero reflejan que todavía hay margen de mejora en el soporte a ciertos tipos de almacenamiento.

En el terreno del software, la dependencia casi total de Flatpak para las aplicaciones también genera división de opiniones. Hay quien lo acepta como precio a pagar por la inmutabilidad y quien preferiría un modelo mixto con algo similar al AUR o repositorios clásicos. El debate está servido y probablemente el proyecto siga ajustando este equilibrio con el tiempo.

Por qué ShaniOS es una opción interesante frente a Windows y a otras distros Linux

Si vienes de Windows y estás cansado de actualizaciones problemáticas, bloqueos aleatorios o vulnerabilidades constantes, una distro inmutable como ShaniOS puede ser una alternativa muy atractiva. La promesa de que el sistema “no se rompe” fácilmente, unida a la posibilidad de revertir en un clic, ofrece una tranquilidad que muchas instalaciones tradicionales no dan.

Frente a distribuciones Linux más populares como Ubuntu, Linux Mint, Fedora o Zorin OS, ShaniOS destaca por su enfoque radical en estabilidad y seguridad. Mantener dos copias del sistema (azul y verde), usar raíz de solo lectura, apoyarse en Btrfs para snapshots y subvolúmenes y aislar las apps con Flatpak forma un conjunto coherente para quien prioriza robustez sobre experimentación constante.

Al mismo tiempo, no sacrifica demasiado la usabilidad ni la estética. La interfaz recuerda en parte a Windows y macOS, con escritorios GNOME o KDE bien integrados, un navegador moderno con VPN y adblock de serie, y herramientas ofimáticas listas para sustituir a Office. Se mantiene ligero y con buen rendimiento, sin dar la sensación de distro “experimental” que te obliga a pelearte con todo.

ShaniOS se posiciona como una propuesta seria dentro del ecosistema de distros inmutables: combina tecnología actual (Btrfs, systemd-boot, cifrado, Flatpak) con una base Arch y una experiencia pensada para que el usuario se olvide de que debajo hay un sistema complejo de dos raíces y despliegues atómicos. No es perfecto, pero si buscas un Linux que aguante el día a día sin dramas, merece claramente un hueco en tu lista de candidatos.

Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía, frente a las restricciones y abusos a los usuarios por parte del software privativo.

Por cierto este mes se cumplen 40 años de la creación de la FSF.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2025/december
• Y traducido en español (cuando el equipo de traducción lo tengamos disponible) en este enlace: https://www.fsf.org/free-software-supporter/2025/diciembre

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

¿Te gustaría aportar tu ayuda en la traducción y colaborar con la FSF? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de diciembre de 2025.

Sólo el software libre permite la soberanía digital

Del 24 de noviembre por la FSFE

El “Germany Stack” es un proyecto central de política digital del gobierno federal alemán. La FSFE pide que Stack se planifique en estrecha coordinación con los socios europeos y se implemente íntegramente como software libre, ya que sólo las cuatro libertades permiten la soberanía digital. Continúe leyendo para obtener más información sobre los detalles de esta solicitud del gobierno federal alemán, incluidos los principios en los que debería basarse el Stack.

• https://fsfe.org/news/2025/news-20251124-01.en.html

El ejército estadounidense quiere arreglar su propio equipo. Los contratistas de defensa están intentando derribarlo.

Del 26 de noviembre por Boone Ashworth

Es probable que las disposiciones sobre el derecho a reparar en la Ley de Autorización de Defensa Nacional, que asegurarían la financiación para el ejército estadounidense en 2026, sean eliminadas del texto final del proyecto de ley a pesar de disfrutar de un amplio apoyo bipartidista, dijeron a WIRED fuentes familiarizadas con las negociaciones en curso.

Dicen que es probable que las disposiciones de la ley que permiten a los militares reparar sus propios equipos se eliminen por completo y se reemplacen con un plan de suscripción de datos como servicio que beneficie a los contratistas de defensa.

• https://www.wired.com/story/subscription-us-military-right-to-repair/

Cloudflare caído: la interrupción global afectó a gran parte de Internet

Del 18 de noviembre por Kate O’Flaherty

Aparentemente, la mitad de la red mundial estuvo caída a mediados de noviembre debido a una interrupción de Cloudflare, lo que demuestra que el software privativo no es tan estable y seguro como les gusta afirmar a sus proveedores.

Tantos sitios web que dependen de un único proveedor para servicios de red y seguridad conllevan grandes peligros, tanto para su libertad como para su capacidad de utilizar un programa en el que puede confiar para trabajar. El software libre ciertamente también puede sufrir interrupciones, pero hay muchas más soluciones cuando se utiliza software libre que con software privativo.

Si actualmente utiliza un programa que se vio afectado por la interrupción de Cloudflare (o su lugar de trabajo lo hace), ahora podría ser un buen momento para hablar sobre cambiar a un programa comparable que respete la libertad.

• https://www.forbes.com/sites/kateoflahertyuk/2025/11/18/cloudflare-down-global-outage-impacting-large-parts-of-the-internet/
• https://directory.fsf.org/

Estas son solo algunas de las noticias recogidas este mes, ¡¡pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2025/diciembre

Y todos los números del «supporter» o boletín de noticias de 2025 en español, francés, portugués e inglés aquí:

• https://www.fsf.org/free-software-supporter/2025

Si eres de los que miman hasta el último detalle de su sistema y te preocupa que todo el software que se ejecuta en tu máquina sea realmente libre, la llegada de GNU Linux-libre 6.18 te va a interesar, y mucho. Esta nueva edición del conocido kernel “desblobado” se basa en Linux 6.18, pero sometido a una limpieza a fondo para eliminar cualquier rastro de firmware o microcódigo propietario.

En las siguientes líneas vamos a desgranar todas las novedades de GNU Linux-libre 6.18: qué cambios introduce respecto al kernel oficial, qué drivers se han visto afectados, cómo se distribuye, qué proyectos lo empaquetan y qué filosofía hay detrás de este trabajo. También comentaremos el papel de su simpático pingüino Freedo, la relación con la FSF y por qué este kernel se ha convertido en una referencia para las distribuciones 100 % libres.

Novedades clave de GNU Linux-libre 6.18 frente a Linux 6.18

La nueva versión GNU Linux-libre 6.18-gnu parte del kernel Linux 6.18, la misma rama que Linus Torvalds acaba de declarar estable y que, según todo apunta, será el próximo kernel LTS de referencia en el ecosistema Linux. Eso significa que hereda todas las mejoras generales: rendimiento afinado, nuevas funcionalidades internas, ampliación de soporte de hardware y las habituales correcciones de bugs.

Sin embargo, el equipo de GNU Linux-libre se encarga de aplicar un conjunto de scripts y herramientas de limpieza (“deblobbing”) que rastrean el código fuente en busca de elementos problemáticos: drivers que cargan firmware binario, llamadas en tiempo de ejecución a microcódigo no libre, referencias en la documentación a blobs externos e incluso menciones a binarios en ficheros devicetree de distintas arquitecturas.

Fruto de este proceso, en GNU Linux-libre 6.18 se han identificado y neutralizado o eliminado nuevos controladores y fragmentos de código que en el árbol oficial del kernel dependen de blobs binarios. Este trabajo no sólo afecta a drivers recién añadidos, sino también a otros ya existentes cuyo mecanismo de carga de firmware ha cambiado en esta versión.

Al mismo tiempo, la versión 6.18-gnu incorpora las optimizaciones de Linux 6.18, como el mejor rendimiento general, el trabajo continuo en Apple Silicon (M2 Pro / Max / Ultra), el soporte en curso de la plataforma Intel Wildcat Lake, la integración del nuevo código “Sheaves”, la activación por defecto del fsck online para XFS o la mejora del soporte háptico para touchpads, entre otras muchas. Todo ello, eso sí, manteniendo siempre la premisa principal del proyecto: cero software propietario.

El corazón del proyecto: un kernel libre de blobs

La razón de ser de GNU Linux-libre es ofrecer un kernel compatible con Linux pero completamente libre, diseñado para poder formar parte de sistemas que siguen las Directrices para Distribuciones de Software Libre (FSDG) de la FSF. Esto implica retirar cualquier componente que no se distribuya en forma de código fuente modificable o que esté sujeto a licencias restrictivas.

En la práctica, esto se traduce en eliminar o desactivar drivers, firmwares, blobs empaquetados como datos, scripts que requieren archivos binarios externos y llamadas a firmware propietario en tiempo de ejecución. También se limpian comentarios y documentación que actúan como “gancho” para que el usuario descargue componentes no libres, evitando el llamado “baiting” hacia software privativo.

El enfoque del proyecto es de cambios mínimos: se borran o neutralizan las partes problemáticas, pero no se intenta reescribirlas ni proporcionar sustitutos libres que mantengan la misma funcionalidad. El objetivo es garantizar la libertad del sistema, aunque eso suponga que cierto hardware quede inoperante si no dispone de alternativas libres.

Este esfuerzo continuo comenzó en su día dentro de la distribución gNewSense, fue impulsado y bautizado por Jeff Moe, en 2008 pasó a estar mantenido por la FSF Latinoamérica y, desde 2012, forma parte oficialmente del Proyecto GNU. Hoy se ha consolidado como la base de numerosos sistemas operativos 100 % libres certificados por la FSF.

Drivers nuevos limpiados en GNU Linux-libre 6.18

Una de las partes más visibles del trabajo en GNU Linux-libre 6.18 es la limpieza de controladores recién incorporados al kernel Linux 6.18 que intentan cargar blobs de firmware. Si se dejaran tal cual, comprometerían la pureza del sistema al requerir binarios no libres.

En esta versión, el equipo ha identificado y “capado” varios drivers nuevos que, en el árbol oficial, recurren a firmware propietario para funcionar correctamente:

• Controladores FourSemi: se limpian el controlador de amplificador de audio digital FourSemi y la biblioteca asociada (incluyendo los modelos FS2104/5S), que en Linux estándar intentan cargar blobs para gestionar ciertos modos y características.
• Driver TI TAS2783: el controlador para el amplificador de altavoz Texas Instruments TAS2783, también nuevo en esta rama, incluye lógica de carga de firmware que ha sido neutralizada para evitar que solicite binarios no libres.
• Qualcomm GENI Serial Engine: el motor serie GENI de Qualcomm, responsable de gestionar interfaces de comunicación en plataformas de esta marca, también habría intentado cargar blobs si no se hubiese intervenido, por lo que se ha sometido al proceso de deblobbing.

En todos estos casos, el resultado es que el driver deja de reclamar firmware propietario. Dependiendo de cuánto dependiera el controlador de ese microcódigo, la funcionalidad práctica del dispositivo puede quedar muy limitada o directamente inutilizada bajo GNU Linux-libre, pero así se respeta la premisa de no empujar al usuario hacia componentes privativos.

Ajustes en drivers existentes: Nova-Core, Intel Xe y más

Además de los controladores recién llegados, GNU Linux-libre 6.18 revisa el comportamiento de drivers ya presentes en versiones anteriores cuyo mecanismo de gestión del firmware ha cambiado en Linux 6.18. Estos ajustes son necesarios para mantener el kernel libre de blobs a medida que evoluciona el árbol principal.

Entre los casos destacados, encontramos:

• Nova-Core, el driver Rust para NVIDIA: el nuevo controlador de código abierto Nova-Core, escrito en Rust, se apoya completamente en el NVIDIA GPU System Processor (GSP). Sin el firmware del GSP, que es propietario, el driver simplemente no funciona. GNU Linux-libre adapta sus scripts para bloquear la carga de este microcódigo, lo que en la práctica deja Nova-Core inoperativo sin blobs, pero preserva la libertad del sistema.
• Intel Xe de nueva generación: el moderno driver Intel Xe depende del microcontrolador GuC y de su firmware binario para tareas de gestión de colas, programación y otras funciones críticas. En Linux-libre 6.18 se ajusta de nuevo la limpieza para impedir que este firmware se solicite o cargue, algo que también deja el driver sin utilidad práctica si no se dispone de alternativas libres.
• TI PRU Ethernet: el controlador de Ethernet basado en PRU (Programmable Real-time Unit) de Texas Instruments también ha sufrido cambios en su lógica de blobs aguas arriba. GNU Linux-libre actualiza el deblobbing para asegurarse de que no se cargan firmwares propietarios en estos SoC.
• Marvell WiFi-Ex: las modificaciones realizadas en el árbol oficial para la familia WiFi-Ex de Marvell han obligado a revisar la limpieza, bloqueando de nuevo cualquier referencia o intento de cargar firmware binario para esos adaptadores inalámbricos.

Estos ajustes demuestran que el proceso de limpieza es continuo y reactivo: cada vez que cambia el código de un driver que en el pasado dependía de blobs, el equipo de Linux-libre debe revisar de nuevo ese código para que no se “cuele” ningún nuevo mecanismo de carga de firmware propietario.

Drivers y elementos eliminados o reubicados

No todo son nuevas limpiezas o ajustes. En GNU Linux-libre 6.18 también hay casos en los que el propio kernel Linux ha eliminado ciertos componentes, lo que permite simplificar el trabajo de deblobbing.

Un ejemplo claro es el del driver de radio FM TI WL1273. Este controlador, que en versiones anteriores requería una limpieza específica por su dependencia de firmware binario, ha sido eliminado directamente en el árbol oficial de Linux 6.18. Como consecuencia, en GNU Linux-libre 6.18 se puede retirar también toda la lógica de deblobbing asociada a este driver, reduciendo así la complejidad del conjunto de scripts.

Otro caso llamativo es el del driver Lantiq GSWIP, un controlador de switch gigabit para determinadas plataformas. En Linux 6.18 se ha movido de ubicación dentro del árbol de código fuente, lo que obliga a ajustar las rutas y patrones que usa el sistema de limpieza del proyecto para localizar y procesar los fragmentos relevantes.

Estos cambios de ubicación y eliminación reflejan cómo el kernel principal está en constante reorganización, y cómo GNU Linux-libre debe mantenerse al día, no sólo rastreando blobs nuevos, sino también adaptando las herramientas a la estructura cambiante del árbol de código.

Devicetree limpios para Qualcomm, Mediatek y TI en ARM64

La limpieza no se limita al código C de los drivers. En esta versión, una de las tareas más delicadas ha sido revisar los nuevos ficheros devicetree (DT) para plataformas ARM64, que describen el hardware de sistemas basados en Qualcomm, Mediatek y Texas Instruments.

En Linux 6.18, varios de estos devicetree incluyen referencias explícitas a blobs de firmware, rutas de archivos binarios o propiedades que indican la necesidad de microcódigo no libre para ciertos componentes. Si se dejara tal cual, el mero hecho de usar esos DT podría empujar al usuario a buscar y cargar componentes propietarios.

GNU Linux-libre 6.18 se encarga de “sanear” estos ficheros, eliminando o modificando las menciones a binarios de Qualcomm, Mediatek y TI en la arquitectura ARM64. De este modo, se garantiza que el kernel libre no actúe como vector de recomendación de software no libre, respetando así las directrices de la FSF.

Cómo obtener GNU Linux-libre 6.18

El proyecto ofrece varias vías oficiales para descargar y utilizar GNU Linux-libre 6.18-gnu, tanto en forma de código fuente como en paquetes binarios listos para instalar en distribuciones populares.

Por un lado, el código fuente se puede obtener mediante Git desde el repositorio mantenido por el proyecto:

• Repositorio Git de lanzamientos: git://linux-libre.fsfla.org/releases.git con etiquetas bajo scripts, sources y logs para la versión v6.18-gnu.

Además, al poco de anunciarse la versión, se ponen a disposición tarballs ya comprimidos desde la página oficial de la FSFLA:

• https://www.fsfla.org/selibre/linux-libre/download/releases/ (ubicación habitual de los tarballs de cada versión).

Quienes prefieran no compilar el kernel a mano pueden recurrir a paquetes binarios preparados por proyectos asociados:

• Freesh: ofrece paquetes .deb listos para usar en distribuciones basadas en Debian y derivadas, con el kernel GNU Linux-libre ya compilado.
• RPM Freedom: proporciona paquetes .rpm para sistemas basados en Red Hat, Fedora y derivados que quieran adoptar este kernel libre.

De este modo, los usuarios pueden elegir entre compilar su propio kernel directamente desde el código fuente o instalar uno de los paquetes ya preparados, integrándolo junto con o en sustitución del kernel estándar de su distribución.

Distribuciones y ecosistema alrededor de Linux-libre

GNU Linux-libre es el pilar sobre el que se construyen muchas distribuciones completamente libres avaladas por la FSF, como Trisquel o PureOS, entre otras. Estas distros utilizan este kernel para asegurarse de que el sistema entero cumple las directrices de software libre más estrictas.

Muchas de ellas ofrecen imágenes ya preparadas con la versión más reciente de Linux-libre o, al menos, con una rama cercana. En otros casos, permiten seleccionar este kernel desde sus repositorios o mediante repos adicionales, de forma que el usuario pueda reemplazar el kernel genérico por uno libre de blobs sin cambiar de distribución.

Para administradores y entusiastas, GNU Linux-libre 6.18 puede instalarse también en casi cualquier distribución convencional. Basta con compilarlo o instalar los paquetes Freesh/RPM Freedom y ajustar el gestor de arranque para elegir este kernel al iniciar el sistema. Así se logra un entorno mucho más coherente con los principios del software libre, incluso en distros que de serie incluyen componentes no libres.

Qué es exactamente GNU Linux-libre (y qué no es)

Desde el propio proyecto se recalca que GNU Linux-libre es, ante todo, una versión modificada del kernel Linux, orientada a ser usada en sistemas GNU que aspiran a ser completamente libres. El objetivo es que cualquier distribución que quiera cumplir las FSDG de la FSF pueda tomar este kernel y tener la tranquilidad de que no contiene blobs ni referencias que lleven al usuario a instalar código propietario.

En su documentación explican que se eliminan componentes no libres tanto si están disfrazados de código fuente (pero en realidad son blobs embebidos) como si se distribuyen en archivos separados. Además, se desactivan las peticiones en tiempo de ejecución a firmwares propietarios y se purgan manuales o comentarios que apunten a recursos no libres.

El proyecto, sin embargo, no se propone reescribir estos componentes ni ofrecer drivers alternativos libres que sustituyan a los propietarios. El enfoque es minimalista: se retira lo que no es libre, se mantiene el resto casi intacto y se anima a que otras iniciativas desarrollen reemplazos libres cuando sea posible. De hecho, se documentan en sitios como LibrePlanet muchos dispositivos que aún dependen de blobs, con el objetivo de coordinar esfuerzos para liberarlos algún día.

Por último, aunque la mascota sea un pingüino, los desarrolladores insisten en que el papel del proyecto GNU y de la FSF en la construcción del sistema completo es mucho mayor, y que el kernel libre es solo una pieza más dentro del ideal de un sistema totalmente libre.

Al combinar todas las mejoras técnicas heredadas de Linux 6.18 con el trabajo exhaustivo de limpieza de firmware, drivers y devicetree, GNU Linux-libre 6.18 se consolida como una opción muy potente para quienes no quieren hacer concesiones en materia de libertad de software. Desde los nuevos drivers saneados para audio digital y motores serie Qualcomm hasta los ajustes en controladores de GPU como Nova-Core y Intel Xe, pasando por el saneamiento de plataformas ARM64 y la disponibilidad de paquetes para múltiples distribuciones, esta versión demuestra que es posible mantenerse cerca de la vanguardia del kernel sin renunciar al principio de no cargar ningún binario propietario.

Una oferta de empleo de alto nivel ha puesto nombre a un secreto a voces: Google trabaja en “Aluminium OS”, un sistema basado en Android con la inteligencia artificial como núcleo. El movimiento encaja con la ambición de la compañía de simplificar su catálogo, dejar atrás el desarrollo paralelo y construir una plataforma capaz de escalar desde el móvil hasta el escritorio.

Aluminium OS aspira a consolidar lo mejor de Android y la experiencia de ChromeOS para competir de frente con Windows y macOS. La hoja de ruta apunta a un lanzamiento alrededor de 2026 y a una transición ordenada en la que ambos sistemas convivan durante un tiempo.

Qué es Aluminium OS y por qué marca un cambio de etapa

La referencia a “Aluminium OS” aparece en una oferta de trabajo para un perfil Senior de Producto de Android en portátiles y tablets. En ella se explica que se trata de un “nuevo sistema operativo” basado en Android y construido con IA en el centro, previsiblemente con una profunda integración de Gemini y un enfoque de PC tradicional.

El nombre, además, rinde homenaje a la genealogía de Chrome/Chromium con ese sufijo “-ium”, y sugiere una continuidad conceptual con los esfuerzos anteriores de convergencia. Durante la última década, Google ha ido acercando Android y ChromeOS con soporte de apps en Chromebook y mejoras de escritorio en Android, pasos que encajan con este nuevo rumbo.

Dispositivos y gamas en Aluminium OS: del básico al segmento premium

La planificación mencionada en el anuncio señala que Aluminium OS se desplegará en múltiples formatos: portátiles, convertibles, tablets y mini PC o “cajas”. Además, se listan explícitamente tramos como AL Entry, AL Mass Premium y AL Premium, lo que indica una estrategia que va más allá del ámbito educativo o de bajo coste en el que triunfaron muchos Chromebooks.

La idea es que el sistema llegue a equipos con CPU, GPU y NPU capaces de mover modelos de IA en local, apoyándose en la nueva generación de chips ARM para PC (por ejemplo, la familia Snapdragon X). El objetivo es ofrecer una experiencia de escritorio completa, menos dependiente del navegador y más cercana a un portátil profesional tradicional. La reacción del mercado y de competidores será un factor importante en la adopción de este enfoque.

Qué pasa con ChromeOS: convivencia y cambio con continuidad

En el propio texto de la vacante se habla de “llevar a Google de ChromeOS a Aluminium con continuidad de negocio”, lo que deja entrever una transición por fases. ChromeOS y Aluminium OS coexistirán durante un tiempo mientras se construye una cartera de dispositivos comerciales en paralelo.

En foros técnicos y seguimientos de código, se han visto referencias a pruebas con placas basadas en Intel de 12.ª generación y MediaTek Kompanio 520. Eso sugiere que Google está evaluando el soporte en hardware existente, pero sin garantías públicas sobre actualizaciones para modelos ya en el mercado. La prioridad parece ser que el cambio no rompa ecosistemas donde ChromeOS tiene peso, como empresa y educación.

Calendario previsto y ventanas de anuncio

Las pistas apuntan a que Aluminium OS se presentaría en 2026, con la posibilidad de una revelación en un evento para desarrolladores y un despliegue posterior junto a nuevos equipos. En paralelo, se seguirá puliendo el “modo escritorio” de Android y el andamiaje de IA que servirá de base para la experiencia de PC.

Ejecutivos de Google ya han reconocido su intención de combinar lo mejor de Android y ChromeOS, y socios como Qualcomm han hablado de una “base técnica común” para PC. Todo ello apunta a un lanzamiento escalonado y a colaboraciones con fabricantes que aceleren la llegada de equipos listos para IA.

IA en el centro: Gemini y un ecosistema de apps unificado

Más allá del nombre, lo diferencial es el enfoque: Aluminium OS nace con la IA como punto de partida. La integración de Gemini y de modelos generativos debería aparecer en funciones de productividad, asistencia contextual, automatización y creatividad, además de herramientas para desarrolladores alineadas con el stack de Android.

Unificar la plataforma implica facilitar que las apps compartan base de código entre móvil y escritorio. Con ello, Google se ahorra mantener dos sistemas separados y podría atraer a más desarrolladores a publicar versiones de “Android de escritorio” con experiencias adaptadas a teclado, ratón y pantallas grandes.

Impacto: educación, empresa y canal

En el mercado europeo, donde Chromebook ha tenido recorrido especialmente en educación, la convivencia de ambos sistemas será clave. Administraciones y centros que dependen de ChromeOS necesitarán calendarios claros de soporte, mientras los fabricantes (Acer, Lenovo, HP y otros con presencia en España) preparan equipos con perfiles premium y de gama media para empresa y pymes.

También habrá interés en soluciones con NPU para ejecutar IA en local por cuestiones de privacidad y cumplimiento normativo en la UE. Si Google logra una migración ordenada y un catálogo competitivo, Aluminium OS podría ganar tracción en entornos profesionales donde ChromeOS tuvo más dificultades para entrar.

Todo apunta a un movimiento estratégico: un Android de escritorio con IA, orientado a varios segmentos de hardware y con un plan de transición desde ChromeOS. Si el calendario se mantiene y los socios responden con equipos solventes, 2026 podría ser el punto de inflexión en el que Google consolide por fin su apuesta por el PC tradicional.

Convertir un móvil o tablet Android en un entorno Linux completo es posible y, además, no necesitas root. Andronix ofrece justo eso: contenedores Linux listos para usar, con opción de interfaz gráfica ligera o línea de comandos, para trabajos de navegación, programación y tareas poco exigentes. Si te gusta cacharrear, personalizar al milímetro o simplemente quieres un escritorio en el bolsillo, aquí tienes todo lo que debes saber.

Antes de meternos en harina, conviene tener claras las bases: Andronix no sustituye Android ni obliga a hacer multiboot. Instalas una o varias distribuciones dentro de Android, las arrancas cuando las necesitas y las borras cuando terminas. Puedes tener incluso varios sistemas a la vez —hasta una docena— si el almacenamiento te lo permite. Y sí, hay escritorio gráfico con LXDE, LXQt o Xfce, e incluso gestores de ventanas como i3, Awesome u Openbox para los amantes del minimalismo.

Qué es Andronix y qué propone

Andronix es una solución para ejecutar un sistema Linux dentro de Android sin permisos de superusuario. Su objetivo es acercar un entorno Linux funcional a cualquier dispositivo compatible, sin romper nada del sistema original y sin tragar anuncios. La app te guía para desplegar contenedores basados en distintas distribuciones, con scripts listos para instalar y configurar todo lo básico.

El proyecto distingue entre dos tipos de sistemas: Un‑Modded OS (gratuitos) y Modded OS (de pago único, con licencias de por vida e instalaciones ilimitadas en cuantos dispositivos quieras). Los Un‑Modded son distros “vanilla” en formato tar con scripts abiertos; los Modded vienen afinados y con extras. Si quieres apoyar el desarrollo, existe Andronix Premium, que añade ventajas como sincronización online de comandos y web app para acceder desde cualquier equipo.

Un plus importante es que no hay multiboot: no particionas ni alteras el arranque del teléfono. Simplemente despliegas cada contenedor y lo ejecutas según te convenga. Puedes tener Un‑Modded y Modded al mismo tiempo, e incluso los 12 sistemas a la vez si te cabe todo en el almacenamiento interno.

Cómo funciona Andronix: PRoot, Termux y contenedores

La magia se apoya en dos pilares. Primero, PRoot emula un entorno de sistema de archivos y mapea llamadas para que la distribución Linux “crea” que corre con privilegios y rutas propias, aunque en realidad todo sucede en espacio de usuario. Segundo, Termux actúa como terminal y entorno base desde el que se lanza la distro y, si quieres, su escritorio gráfico.

Este enfoque tiene implicaciones. Al no cargar un kernel Linux completo ni cambiar el de Android, hay limitaciones técnicas por la falta de soporte total del kernel, por políticas SELinux de tu versión de Android, por la arquitectura del procesador y por el propio hardware. Por ejemplo, en Kali Linux la mayoría de herramientas avanzadas de pentesting no funcionarán como en un PC, precisamente por esas restricciones del kernel.

Ahora bien, si tu idea es navegar, programar, editar documentos o conectar vía SSH, este modelo funciona más que bien. De hecho, hay usuarios que han logrado “jubilar” portátiles en tareas leves usando Andronix a diario. Evidentemente, no es para cargas pesadas, pero para un escritorio ligero en movilidad va de lujo.

Acceso: CLI, escritorio y gestores de ventanas

Una vez desplegada la distribución, puedes operar de dos maneras. La más rápida es CLI (línea de comandos), como si entraras por SSH en una máquina remota, ideal para administrar, programar y automatizar. La otra es GUI (interfaz gráfica), que puedes montar con LXDE, LXQt o Xfce, tres escritorios conocidos por su ligereza.

Si te va la personalización extrema, los Window Managers compatibles —Awesome, i3 y Openbox— son el terreno perfecto para “hacer rice” y dejar el escritorio a tu gusto. Estos gestores de ventanas consumen pocos recursos, son muy configurables y permiten un flujo de trabajo rápido con atajos de teclado y paneles minimalistas.

Distros disponibles: Un‑Modded y Modded

En el apartado de sistemas soportados, Andronix ofrece 8 Un‑Modded OS y 4 Modded OS en el momento descrito, cubriendo las distros más populares. Entre las Un‑Modded figuran:

• Ubuntu
• Debian
• Manjaro
• Fedora
• Kali (con la nota importante de que muchas herramientas de seguridad no operan por las limitaciones del kernel)
• Void
• Alpine
• Arch (en soporte beta)

Las versiones Modded, por su parte, son de pago único y vitalicio, con instalaciones ilimitadas. Están pensadas para quien quiere algo más afinado sin invertir tiempo en ajustes iniciales. Puedes mezclar ambas familias a la vez, instalando y desinstalando cuando quieras según tus necesidades de almacenamiento.

Requisitos: versión de Android, Termux y arquitectura

Para que todo funcione, necesitas cubrir tres puntos esenciales. Primero, Android 7.0 o superior. Segundo, Termux instalado desde F‑Droid (específicamente esa versión). Tercero, un dispositivo con arquitectura compatible, que puede ser ARMv7, ARM64 o x64. Si cumples con esto, lo normal es que puedas desplegar cualquiera de las distros mencionadas.

Recuerda que, aunque no requiera root, la experiencia dependerá mucho de tu hardware. Más RAM y mejor CPU siempre ayudan, sobre todo si quieres abrir un escritorio completo con múltiples apps en paralelo. En dispositivos modestos, optar por LXDE o un gestor de ventanas marcan la diferencia en fluidez.

Licencias, apertura del código y cómo colaborar

Andronix adopta un enfoque mixto en cuanto a su modelo de desarrollo. Es parcialmente open‑source: los tar de las distros gratuitas y los scripts de instalación están publicados en su repositorio de GitHub. Sin embargo, la app de Android y los recursos de los Modded OS son cerrados por razones comerciales evidentes.

Esto no significa que no apuesten por la comunidad. Al contrario: aman el open‑source y, si mantienes un proyecto abierto como dev o maintainer, puedes solicitar acceso gratuito de por vida a los componentes de pago tras un proceso de verificación. Una manera elegante de apoyar a quienes empujan el ecosistema libre.

Andronix y DeX/ChromeOS: integración vs. separación

Una pregunta recurrente es si Andronix crea un “shell de Linux” como en ChromeOS o si se pueden lanzar apps Android dentro del escritorio Linux. La respuesta corta: Andronix ejecuta Linux en un contenedor separado del entorno Android. Esto significa que el escritorio Linux no es el de Android ni integra sus apps como si fueran nativas del sistema huésped.

En la práctica, tendrás dos mundos conviviendo en el mismo dispositivo: Android con sus apps y, cuando lo inicies, la distro Linux con sus propias aplicaciones. Puedes compartir archivos y moverte entre ambos, pero no vas a instalar apps Android dentro de LXDE/Xfce como si aquello fuera DeX o el contenedor Crostini de ChromeOS. Es un paradigma distinto: aquí todo ocurre en espacio de usuario emulado por PRoot.

¿Qué puedes hacer con Andronix?

Dentro de los límites comentados, el abanico es amplio. Para empezar, navegación web ligera, escritura y edición de documentos, terminal, administración de servidores, programación con tus herramientas favoritas y gestión de repositorios de código. Con escritorios livianos o gestores de ventanas, la experiencia es ágil y agradable incluso en dispositivos veteranos.

Si te gusta el bricolaje digital, puedes personalizar a fondo el entorno, desde temas y atajos de teclado hasta paneles e indicadores. Y si no quieres perder tiempo en la puesta a punto, los Modded OS reducen pasos y te dejan con algo “listo para funcionar” de forma más inmediata.

Limitaciones a tener en cuenta

Conviene subrayar los bordes del mapa para no llevarse decepciones. Por su naturaleza, no hay acceso total al kernel Linux ni a ciertas funciones de bajo nivel. Herramientas que requieren capacidades específicas del kernel, como parte del arsenal de Kali, no operarán como en un PC. También estás sujeto a las políticas SELinux de tu versión de Android, que pueden acotar acciones dentro del contenedor.

En rendimiento, el escritorio gráfico siempre suma consumo de RAM y CPU. Si tu dispositivo es modesto, elige entornos ligeros (LXDE, Openbox, i3) y evita acumular procesos. Para cargas intensivas o aceleración gráfica compleja, este enfoque no es el adecuado. Aun así, para tareas de productividad básicas funciona sorprendentemente bien.

Andronix vs. UserLAnd y otras vías

Entre las alternativas más conocidas aparece UserLAnd. A raíz de comentarios de usuarios, hay quien percibe periodos con menos actividad en Andronix y, por contra, actualizaciones recientes y buenas reseñas en UserLAnd. Si priorizas una interfaz moderna y scripts listos, Andronix es muy cómodo; si valoras más el pulso de actualizaciones en el momento, puede tener sentido probar UserLAnd y ver cuál se adapta mejor a tu uso real.

Más allá de esos dos, existen enfoques similares basados en contenedores apoyados en PRoot o en soluciones de escritorio remoto. Si lo que quieres es “un Linux con ventanas” accesible desde Android, tanto Andronix como propuestas análogas comparten la filosofía: no tocar particiones, no pedir root y ofrecer un entorno usable de trabajo con costes mínimos.

¿Para quién es ideal Andronix?

Si buscas un entorno Linux de bolsillo para estudio, programación ligera, administración y pruebas, Andronix encaja como un guante. Es perfecto para amantes del minimalismo y del “rice” que quieren un WM rápido, y para quienes no desean meterse en multiboots ni procedimientos delicados. La curva de entrada es suave gracias a scripts y documentación.

Para quienes necesitan herramientas de seguridad muy específicas o dependientes de kernel, o para cargas pesadas y aceleración avanzada, lo más prudente es usar un PC o portátil con Linux nativo. Aun así, como entorno de apoyo, tener Linux en el mismo teléfono es un lujo cuando estás con movilidad y necesitas sacar trabajo rápido.

Instalación y gestión: ideas clave

La app guía el proceso, pero la dinámica general es clara: descargas el tar de la distro, lo despliegas vía scripts y, desde Termux, inicias la sesión (CLI o GUI según prefieras). Puedes instalar varias distros y convivir con Un‑Modded y Modded; cuando ya no te haga falta alguna, la desinstalas y listo.

Si optas por escritorio, lo habitual es conectarte vía servidor VNC a la sesión gráfica que se levanta desde el contenedor. Es una solución extendida por su compatibilidad y simplicidad, y encaja con la idea de recursos contenidos que persigue Andronix.

Personalización: de DEs a WMs

Quienes prefieren un escritorio clásico tienen LXDE, LXQt y Xfce. Todas son opciones ligeras, con menús y paneles tradicionales, bien documentadas y amigables. Si te va ajustar cada detalle, los gestores de ventanas como i3, Awesome y Openbox te permiten construir un entorno ultrarrápido con atajos, barras e indicadores a tu medida.

La comunidad de “ricers” disfruta particularmente de i3 y Awesome por su flexibilidad y rendimiento, mientras que Openbox ofrece un equilibrio estupendo entre estética y consumo. Desde temas y colores hasta keybindings, tú decides cómo se comporta y cómo luce tu escritorio.

Modelo económico: gratuito, Modded y Premium

El acceso a las distros Un‑Modded es gratuito y sin anuncios, con uso ilimitado. Si buscas algo más mimado y rápido de arrancar, los Modded OS tienen un coste único razonable que da derecho a uso de por vida en dispositivos ilimitados. Para quienes quieren apoyar al equipo y ganar comodidad, Andronix Premium añade ventajas como la sincronización online de comandos y una web app multi‑dispositivo.

Esta combinación permite empezar sin pagar, evaluar si encaja en tu flujo y, si lo hace, invertir en Modded o Premium. Transparency note: los recursos de pago son cerrados, mientras que los scripts y tars libres están en GitHub, lo cual aporta confianza y revisabilidad.

Queda claro que Andronix es una forma directa de llevar Linux al bolsillo sin root, con distros populares, escritorios ligeros y gestores de ventanas ideales para equipos modestos. No pretende sustituir a un Linux nativo en un PC, pero cubre de sobra navegaciones, terminal, programación y productividad básica; y, además, lo hace sin multiboot, con scripts abiertos y una comunidad activa respaldada por documentación y un sitio moderno con NuxtJS, Tailwind, Cypress, Mocha y GitHub Actions. Si venías con dudas sobre DeX/ChromeOS o comparándolo con UserLAnd, piensa que aquí el contenedor Linux convive con Android sin mezclar apps, y que la elección entre uno u otro depende más de tu preferencia por comodidad, personalización y ritmo de actualizaciones que de una brecha técnica radical.

Disponible en la Google Play.

Si te preocupa tu privacidad y quieres navegar sin dejar rastro, Tails vuelve a la carga con una versión que merece la pena probar de inmediato. En esta entrega, la llegada de Tails 7.2, tras Tails 7.1, refuerza su enfoque tradicional: ejecutar el sistema desde un USB, forzar todo el tráfico a través de Tor y minimizar filtraciones. El resultado es una actualización centrada en seguridad, compatibilidad y usabilidad, justo lo que muchos pedíamos desde hace tiempo.

Lo más llamativo es el salto del navegador integrado y los ajustes finos de privacidad, pero hay más. Tor Browser 15.0.1, el kernel Linux 6.12.57 y Thunderbird 140.4.0 se combinan con cambios que reducen riesgos, como la eliminación de la consola gráfica de root o el bloqueo de telemetría en el correo. En conjunto, Tails 7.2 pule la experiencia sin renunciar al «mínimo privilegio» que caracteriza a este sistema.

Qué es Tails y por qué sigue siendo clave

Tails, siglas de The Amnesic Incognito Live System, es una distribución basada en Debian, como se detalló en Tails 7.0, pensada para ejecutarse como sistema en vivo desde un medio externo, normalmente un USB. Su propuesta es sencilla y contundente: todo el tráfico sale por Tor, nada se escribe en el equipo anfitrión y la persistencia es opcional mediante un almacenamiento cifrado que puedes habilitar en la propia memoria USB.

En la práctica, esto implica que puedes usar Tails en casi cualquier ordenador, dejarlo tal cual estaba al apagar y marcharte sin huellas. Es la opción preferida por quienes necesitan confidencialidad robusta, desde periodistas y activistas hasta usuarios que simplemente desean minimizar el rastreo en la red.

Panorama de Tails 7.2: novedades de calado

La versión 7.2 llega con actualizaciones clave de software y una serie de cambios orientados a la seguridad operativa El foco está en mejorar el rendimiento del navegador Tor, ampliar el soporte de hardware y ajustar mecanismos que podían filtrar metadatos o facilitar acciones de riesgo por parte del usuario.

Como es habitual en el proyecto, también se han resuelto fallos detectados con anterioridad. Estas correcciones ayudan a mantener una superficie de ataque más pequeña y a que la experiencia sea más consistente al iniciar sesión, navegar, usar correo o gestionar la persistencia.

Tor Browser 15.0.1: productividad y antifingerprinting

El cambio visible para casi todos está en el navegador: Tails 7.2 incluye Tor Browser 15.0.1. Además de los parches de seguridad habituales, esta versión incorpora un rediseño de la barra de direcciones y funciones que facilitan trabajar con muchas pestañas.

• Pestañas verticales: perfectas si sueles tener decenas de páginas abiertas o trabajas en pantallas anchas; verás títulos más legibles y más espacio útil.
• Grupos de pestañas: ordena tus sesiones por temáticas para alternar fácilmente entre investigación, noticias, compras o estudios.
• Barra de direcciones más limpia: integración de búsqueda y un diseño más despejado para reducir distracciones y errores.

Por detrás, el equipo de Tor ha reforzado las medidas anti-seguimiento y la protección contra el fingerprinting del navegador. El objetivo es dificultar la identificación única del usuario a través de características del sistema y del navegador, elemento crítico en un entorno como Tails donde el anonimato es la norma.

Kernel Linux 6.12.57: compatibilidad y estabilidad

El salto del kernel a la versión 6.12.57 trae consigo mejoras de compatibilidad y múltiples correcciones. Este avance se nota cuando arrancas Tails en equipos recientes, con chipsets Wi-Fi actuales, gráficas AMD/Intel o unidades NVMe, donde un núcleo moderno hace la diferencia entre funcionar a la primera o estar peleando con el hardware.

Además de abrir la puerta a más dispositivos, un kernel actualizado suele traducirse en mayor estabilidad bajo carga, mejores drivers y mitigaciones de seguridad recientes. Para un sistema en vivo que trabaja desde USB, esos puntos extra de robustez y rendimiento son oro, especialmente si vas a moverte entre varios ordenadores.

Thunderbird 140.4.0: correo con más privacidad

La suite de comunicaciones también sube de nivel con Thunderbird 140.4.0. Aunque es una revisión de mantenimiento, en Tails trae un matiz importante: se han deshabilitado las conexiones automáticas a servicios de telemetría de Mozilla, eliminando un canal de metadatos que sobraba en un sistema tan estricto con la privacidad.

Por supuesto, se mantiene el soporte de cifrado con OpenPGP para correo seguro y las mejoras habituales de fiabilidad. El enfoque aquí es claro: menos ruido en red, menos exposición y una base sólida para comunicaciones sensibles, que es justo lo que se espera al trabajar con Tails.

Cambios de seguridad operativa: adiós a la consola gráfica de root

Uno de los movimientos más discutidos, y a la vez más sensatos, es la eliminación de la aplicación gráfica de consola con privilegios de administrador. Desde ahora, si necesitas elevar privilegios tendrás que hacerlo en la terminal con el comando sudo -i.

Esta decisión alinea el sistema con el principio de mínimo privilegio y reduce el riesgo de acciones accidentales o de abuso por aplicaciones. Menos interfaces que otorgan root implica menos ventanas de oportunidad para errores humanos o software malicioso, especialmente relevante en un entorno comprometido con la seguridad.

Notificaciones más coherentes y reloj sincronizado

Otro ajuste fino que quizá no veas a primera vista: las notificaciones de «No volver a preguntar» se muestran únicamente cuando el reloj del sistema ya está sincronizado. Teniendo en cuenta lo sensible que es la sincronización temporal para la red Tor y ciertos protocolos, es un pequeño gran cambio.

Al evitar que el usuario silencie avisos antes de que la hora sea correcta, Tails reduce inconsistencias en el arranque y en el establecimiento de servicios de red. Una secuencia de inicio más predecible es sinónimo de menos incidencias y mejor seguridad.

Correcciones destacadas

Además de las actualizaciones mayores, Tails 7.2 incluye soluciones puntuales que impactan directamente en la privacidad. La más reseñable es la desactivación de las conexiones a la telemetría de Mozilla por parte de Thunderbird (incidencia de seguimiento #21275), un paso más para cerrar posibles fugas involuntarias

Este tipo de arreglos reafirman la vigilancia continua del proyecto sobre dependencias y componentes que, aunque reputados, no siempre encajan al 100% con el estándar de confidencialidad que marca Tails. Cada conexión innecesaria cuenta, y aquí se ha cortado de raíz.

Cómo actualizar o instalar Tails 7.2

Si ya estás en Tails 7.0 o superior, puedes usar el mecanismo de actualización automática incluido en el sistema. En la mayoría de casos el proceso es directo y conserva tu Almacenamiento Persistente, evitando tener que rehacer tu entorno.

Si la actualización automática no funciona o el sistema no arranca tras el intento, el equipo recomienda acudir al procedimiento manual. Las instrucciones oficiales explican paso a paso cómo recrear el USB con la nueva imagen sin comprometer tus datos si ya los tenías en persistencia (siempre que optes por la ruta de actualización y no por reinstalar desde cero).

Quienes vayan a preparar Tails por primera vez desde Windows lo tienen bastante fácil. Necesitarás un pendrive de al menos 8 GB, Windows 7 o superior, 2 GB de RAM y descargar aproximadamente 1,9 GB para la imagen del sistema. En unos minutos tendrás un USB arrancable listo para usar.

La web del proyecto ofrece la descarga de la ISO y, como es costumbre, la verificación mediante firma PGP para comprobar integridad y autenticidad. Conviene no saltarse este paso, ya que asegura que lo que grabas en el USB es exactamente lo que el equipo de Tails ha publicado.

Casos de uso y recomendaciones prácticas

¿Para quién es Tails 7.2? Para perfiles que priorizan la privacidad frente a la comodidad absoluta, y para quienes necesitan minimizar su huella digital. Periodistas, activistas, investigadores o cualquier usuario que quiera separar tareas sensibles del resto encontrarán aquí un entorno idóneo.

Si vas a usarlo con frecuencia, activa la persistencia y configura lo básico: claves OpenPGP, clientes que uses a diario y preferencias de Tor Browser. Mantén el hábito de actualizar en cuanto haya nuevas versiones y evita añadir software fuera del ecosistema de Tails.

En equipos modernos, el nuevo kernel debería reducir fricciones con Wi-Fi, GPU y almacenamiento. Si notas algún bache en el arranque, prueba otro puerto USB, un pendrive de mayor calidad o recrea el medio desde cero siguiendo la guía oficial.

La nueva entrega encaja con lo que se espera de Tails: software base puesto al día, funciones útiles para trabajar mejor con el navegador, recortes de superficie de ataque y una relación más sana con el hardware reciente. Entre Tor Browser 15.0.1, el kernel 6.12.57, Thunderbird sin telemetría y la retirada de la consola gráfica de root, la versión 7.2 afianza a Tails como una opción fiable para quienes necesitan privacidad real sin complicarse más de la cuenta.

IncusOS es una imagen de sistema inmutable pensada exclusivamente para ejecutar Incus con el máximo nivel de seguridad y fiabilidad. Sobre la base de Debian 13 y aprovechando las herramientas modernas de systemd, propone una experiencia de administración centrada en API y diseñada para centros de datos y despliegues a gran escala. En la práctica, ofrece arranque seguro, cifrado total de disco y actualizaciones atómicas para que tu infraestructura sea fácil de mantener y extremadamente consistente.

Si lo que quieres es simplificar el soporte y reducir variaciones entre servidores, este proyecto te encaja como un guante: todas las máquinas corren exactamente el mismo software, bit a bit, lo que elimina desviaciones de configuración y facilita escalar o reaprovisionar en minutos. Además, no te vas a pelear con shells locales: el sistema se gobierna por API autenticada y punto.

¿Qué es IncusOS y por qué importa?

IncusOS es un sistema operativo inmutable cuyo objetivo único es ejecutar Incus de forma segura y reproducible. Se asienta en Debian 13 minimalista, incorpora compilaciones Zabbly del kernel Linux, de ZFS y del propio Incus, y hace un uso intensivo de herramientas de systemd para construir, instalar aplicaciones y aplicar actualizaciones. La filosofía es clara: cuanto más predecible sea la base, mejor para la fiabilidad operativa.

El proyecto se construye con mkosi para generar las imágenes, sysext para instalar aplicaciones sobre la base inmutable y sysupdate como motor de actualizaciones. En combinación, estas piezas permiten que el sistema aplique cambios de forma atómica y, si algo no sale bien, vuelvas atrás sin dramas gracias a un esquema de particiones A/B.

Seguridad de arranque, cifrado y modelo de acceso de IncusOS

La seguridad es el pilar. IncusOS se apoya de manera activa en UEFI Secure Boot y TPM 2.0 (aunque conviene conocer la vulnerabilidad en shim) para medir y asegurar la cadena de arranque, además de habilitar el cifrado completo de disco. El cifrado se sustenta en TPM tanto para LUKS como para ZFS, asegurando que las claves queden ligadas al hardware.

El sistema está completamente bloqueado: no existe shell local ni acceso remoto por SSH. La administración se hace a través de la API de Incus, con autenticación fuerte mediante certificados de cliente TLS o, si lo prefieres, OIDC externo. Este enfoque reduce superficie de ataque y disminuye el riesgo de cambios no controlados en producción. Algunos proyectos similares de seguridad, como Predator OS, exploran modelos parecidos.

Inmutabilidad y actualizaciones atómicas (A/B)

El diseño A/B que emplea IncusOS mantiene dos particiones del sistema: una activa y otra de reserva. Las actualizaciones se aplican a la partición inactiva para que, al reiniciar, entres en la nueva versión de forma segura y reversible. Si se detecta un problema, puedes volver a la partición anterior sin pérdida de servicio.

Además, todas las particiones del sistema están en solo lectura y firmadas, minimizando el riesgo de corrupción y asegurando la integridad. Con sysupdate y sysext, las nuevas versiones llegan de forma controlada y las aplicaciones se encajan de manera declarativa y limpia sobre la base.

Arquitecturas soportadas y despliegue

IncusOS funciona en equipos modernos de amd64 (x86_64) y arm64, abarcando tanto hardware Intel/AMD como ARM. Esto permite desplegarlo en servidores físicos de última generación y también en múltiples plataformas de virtualización, donde el rendimiento y la coherencia siguen siendo la prioridad.

Si te preocupa la curva de aprendizaje: la documentación oficial muestra desde la instalación en bare metal hasta cómo arrancarlo en distintas plataformas de máquina virtual. Es decir, puedes probarlo en laboratorio en minutos y, cuando te convenzas, llevarlo tal cual a producción.

Instalación y primer arranque de IncusOS: sin instalador tradicional

En IncusOS no hay un instalador al uso. Puedes arrancarlo directamente desde el medio en el que lo escribas o dejar que, en el primer arranque, se instale de forma automática en un disco interno. Es un proceso pensado para simplificar la vida del operador y reducir puntos de fallo.

Como no hay shell, la personalización se realiza con una herramienta de configuración inicial que permite, entre otras cosas, definir qué cliente tendrá permiso para controlar el sistema. A partir de ahí, todo el gobierno del host se realiza por API, con autenticación obligatoria, reforzando el modelo de seguridad.

Características principales del diseño de IncusOS

La propuesta de valor combina arranque seguro, cifrado y bloqueo de la superficie de administración. En conjunto, IncusOS prioriza seguridad, rendimiento y previsibilidad. Entre los pilares del diseño están el uso de UEFI Secure Boot, mediciones con TPM 2.0, particiones A/B, sistema en solo lectura firmado y la administración exclusiva por API.

Almacenamiento: ZFS automático y ecosistema enterprise

De fábrica se crea un pool ZFS local de forma automática, similar a lo que ofrecen sistemas orientados a NAS como ZimaOS para NAS, con soporte para elaborar configuraciones más complejas en discos adicionales. Si necesitas SAN o escenarios avanzados, hay soporte para Fibre Channel y multipath, así como para NVMe over TCP e iSCSI.

Para topologías exigentes, IncusOS admite LVM en clúster sobre esos transportes y se integra con Ceph para almacenamiento definido por software. Está previsto añadir compatibilidad con Linstor próximamente, lo que ampliará aún más las opciones de despliegue.

• Pool ZFS automático y cifrado ZFS respaldado por TPM.
• Fibre Channel, multipath, NVMe/TCP e iSCSI.
• LVM en clúster y soporte Ceph; Linstor en camino.

Red: puentes VLAN, agregación de enlaces y SDN

La red también viene muy cuidada. IncusOS genera bridges con soporte de VLAN, facilitando conectar contenedores o máquinas a cualquier interfaz física que tengas en el host. Para disponibilidad y ancho de banda, hay compatibilidad con agregación de enlaces (tanto pasiva como negociada).

Incluye soporte LLDP para descubrimiento, proxy corporativo con Kerberos, NTP robusto y envío de logs a remoto vía syslog en UDP, TCP o TLS. Para SDN, el sistema integra OVS/OVN, y también cuenta con soporte nativo de Tailscale; Netbird está previsto próximamente. Además, existen soluciones de red y seguridad como IPFire para funciones de red centralizadas.

• Puentes VLAN-aware y bonding de enlaces.
• LLDP, proxy empresarial con Kerberos y NTP robusto.
• Syslog remoto (UDP, TCP, TLS) y SDN con OVS/OVN.
• Integración nativa con Tailscale; Netbird llegará pronto.

Gestión: operaciones centralizadas y actualizaciones flexibles

A nivel de operación, IncusOS puede gestionarse de forma central a través de Operations Center. Además, permite realizar copias de seguridad y restauraciones tanto de la configuración principal del sistema como de los datos de cada aplicación por separado.

Si necesitas volver a un estado conocido, puedes ejecutar un restablecimiento de fábrica del sistema completo o únicamente de ciertas aplicaciones. El mecanismo de actualización también es flexible: puedes ajustar frecuencia, desactivar automáticas o definir ventanas de mantenimiento para aplicar cambios sin sobresaltos.

Ritmo de lanzamientos y canales de actualización de IncusOS

Hay dos canales de actualización: stable y testing. Por defecto, las instalaciones se sitúan en stable, con una cadencia aproximada semanal que incorpora el último kernel estable y parches de seguridad relevantes. Quien busque más frescura puede optar por testing, que suele actualizarse a diario.

Los sistemas comprueban si hay nuevas versiones cada 6 horas. Incus se actualiza automáticamente con un parón de API muy breve, sin afectar a las instancias en ejecución, y cualquier actualización del sistema base se queda preparada para aplicarse en el siguiente reinicio. Si lo necesitas, puedes cambiar esa frecuencia o desactivar completamente las actualizaciones automáticas.

Construcción, CI/CD y publicación de imágenes

El repositorio del proyecto contiene todas las fuentes utilizadas para construir las imágenes de producción de IncusOS. Cuando se empuja una nueva etiqueta (tag) al repositorio, se desencadena una compilación completa de la imagen, que después es descargada y validada por el servidor de publicación. La imagen resultante se expone en el canal testing hasta que un revisor la promueve manualmente a stable.

Puedes consultar los registros de las compilaciones más recientes en GitHub Actions: workflow de build. Las imágenes finales se publican en images.linuxcontainers.org/os/, desde donde puedes descargarlas o integrarlas en tu pipeline.

Para asegurar calidad, se ejecuta también una prueba diaria que ejercita gran parte de los endpoints de la API y otros tests que no sería práctico correr en cada pull request. El desarrollo ocurre a la vista en GitHub: github.com/lxc/incus-os.

Base tecnológica y componentes

Bajo el capó, IncusOS emplea un Debian 13 minimizado con compilaciones Zabbly de kernel, ZFS e Incus, lo que te da acceso a versiones estables y recientes de todos esos componentes. Systemd aporta las herramientas clave: mkosi para generar imágenes, sysext para el despliegue de aplicaciones, sysupdate para actualizaciones y utilidades para el particionado inicial y el cifrado respaldado por TPM.

El proyecto combina archivos de configuración para dirigir mkosi con un conjunto de herramientas y un demonio de gestión del sistema escritos en Go. Todo el código se publica bajo licencia Apache 2.0 y existen pautas detalladas de contribución en la documentación oficial para quien quiera colaborar.

Garantía de consistencia y escalabilidad

Una de las grandes bazas de IncusOS es que todos los servidores ejecutan exactamente el mismo conjunto de bits. No hay variaciones entre hosts, lo que simplifica a rabiar la operación diaria: menos sorpresas, menos “solo pasa en este nodo” y un camino más directo para escalar o reimplantar decenas o cientos de máquinas cuando haga falta.

Al eliminar la capa de shell local y centralizar la gestión en API autenticada, se reduce el riesgo de “drift” de configuración con el paso del tiempo. Esta coherencia operativa, con particiones inmutables en solo lectura y firmas, tiene un impacto directo en la fiabilidad y en la previsibilidad de los cambios.

Operaciones Center y Migration Manager

IncusOS no solo sirve de host para Incus; también se puede usar como sistema base para Operations Center y Migration Manager. Esta combinación abre la puerta a migraciones ordenadas desde entornos como VMware hacia Incus, manteniendo un sistema subyacente fácil de actualizar, seguro y alineado con la filosofía inmutable.

Con backups granulares (configuración principal y datos de aplicación), restablecimientos selectivos y actualizaciones programables, el trinomio Incus + IncusOS + herramientas de gestión permite plantear transiciones controladas sin dolores innecesarios.

Cómo empezar con IncusOS: documentación y descargas

La documentación oficial explica cómo arrancar en físico, cómo probarlo como máquina virtual y cómo sacarle partido a cada componente (almacenamiento, red, gestión y seguridad). El anuncio de lanzamiento y recursos relacionados están disponibles en el foro de Linux Containers: anuncio de IncusOS. También están en GitHub.

Si vas al grano, las imágenes se publican tras superar la validación en: . Antes podrás seguir el estado de construcción en GitHub Actions y, cuando estén listas, descargarlas e implantarlas en tu laboratorio o entorno productivo.

Novedad dentro del ecosistema Incus

IncusOS llega como parte de la evolución natural tras el fork de LXD a Incus. El propio líder del proyecto, Stéphane Graber, presentó IncusOS tras más de un año de desarrollo, describiéndolo como un entorno moderno e inmutable especialmente diseñado para ejecutar Incus, con actualizaciones atómicas A/B y una postura de seguridad robusta basada en Secure Boot y TPM.

El enfoque minimalista de Debian 13, combinado con ZFS (OpenZFS) y un uso intensivo de las herramientas de systemd para compilación, instalación y actualización, remata una plataforma que, por diseño, se opera enteramente vía API con autenticación de certificados TLS o mediante OIDC externo.

Lecciones del mundo inmutable en otros sistemas

En el ecosistema BSD se han debatido ideas similares desde hace años (por ejemplo, en NanoBSD). Hubo propuestas para que el sistema base se actualizara como zfs receive, generando una nueva “boot environment” y activándola en el siguiente arranque. El mayor escollo allí es que fstab debe residir en la raíz, lo que arrastra /etc al filesystem raíz e impide reutilizar exactamente la misma base en cada despliegue.

Apple abordó un problema parecido separando volumen raíz y volumen de usuario, de modo que el primero pueda localizar la configuración local en un lugar bien conocido. En FreeBSD también se planteó homogeneizar configuraciones del sistema base con UCL y permitir inclusiones firmadas, encadenando esa firma a la cadena de arranque segura. El objetivo es el mismo que persigue IncusOS: una base inmutable que solo consuma configuración del volumen mutable si esta está correctamente autenticada.

Transparencia del ciclo de vida y licencia

El proyecto publica todo su trabajo bajo la licencia Apache 2.0, con guías de contribución disponibles en la documentación. Esto permite a operadores y desarrolladores entender cómo se ensamblan las imágenes, revisar el código del demonio de gestión en Go y participar en el flujo de trabajo de etiquetado, compilación y promoción entre canales.

La combinación de CI diaria que estresa la API, la promoción manual de testing a stable y la firma de las particiones de sistema produce un ciclo de vida más predecible. En otras palabras, se reduce el riesgo de regresiones en producción y se gana control sobre cuándo y cómo aplicar cambios.

IncusOS aporta un enfoque moderno y pragmático a los hosts de Incus: seguridad de arranque con TPM y Secure Boot, cifrado total de disco, sistema de solo lectura y actualizaciones A/B reversibles; red y almacenamiento listos para empresa; administración cien por cien por API; y un pipeline de construcción y pruebas transparente. Con dos canales de actualización, comprobaciones cada 6 horas y publicación abierta de imágenes y logs de compilación, el resultado es una plataforma sólida, coherente y muy fácil de operar para cualquiera que busque desplegar y escalar infraestructura sobre Incus.

Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía, frente a las restricciones y abusos a los usuarios por parte del software privativo.

Por cierto este mes se cumplen 40 años de la creación de la FSF.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2025/november
• Y traducido en español (cuando el equipo de traducción lo tengamos disponible) en este enlace: https://www.fsf.org/free-software-supporter/2025/noviembre

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

¿Te gustaría aportar tu ayuda en la traducción y colaborar con la FSF? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de noviembre de 2025.

La FSF anuncia el proyecto Librephone

Del 14 de octubre

La FSF está abordando la libertad en la telefonía móvil con su nuevo proyecto, Librephone. Este proyecto no construirá un sistema operativo móvil desde cero. Se trata de un proyecto a largo plazo para comprender mejor y aplicar ingeniería inversa al código no libre utilizado por prácticamente todos los SoC actuales, además de sentar las bases para un futuro de libertad en la telefonía móvil.

Puedes mantenerte informado uniéndote al canal #librephone en el servidor IRC Libera.Chat. Toda la información sobre Librephone se publicará en su página web, ¡así que no olvides añadirla a tus marcadores!

• https://www.fsf.org/news/librephone-project
• https://www.fsf.org/campaigns/librephone
• http://librephone.fsf.org/

La FSF cumple 40 años con un nuevo proyecto revolucionario y un nuevo presidente

Del 4 de octubre

El aniversario de la FSF comenzó con una conversación entre los miembros de la junta directiva Christina Haralanova, Gerald J. Sussman, Ian Kelling y Richard M. Stallman, quienes hablaron sobre la misión de la organización y su visión de futuro.

Durante esta conversación, se presentó a Ian Kelling como el nuevo presidente de la FSF. El anuncio de la presidencia de Kelling no fue el único cambio importante que se compartió en FSF40: la directora ejecutiva de la FSF, Zoë Kooyman, presentó el proyecto más reciente de la organización: Librephone. Puedes leer más sobre el evento del 40.º aniversario de la FSF en el siguiente artículo.

• https://www.fsf.org/news/fsf-turns-forty-with-a-new-president-and-a-new-campaign

El ocaso de Windows 10 no significa el fin de tu PC

Del 9 de octubre

Para quienes tengan ordenadores con Windows 10, es posible que hayan experimentado diversos problemas al intentar la actualización forzada a Windows 11 (siempre que su hardware fuera compatible). Esta no es la primera vez que Microsoft intenta controlar a los usuarios, ni será la última.

El fin del soporte para Windows 10 es la oportunidad perfecta para frenar este ciclo y pasarse a un sistema operativo GNU/Linux que respete la libertad. Existen varias distribuciones GNU/Linux libres y aprobadas por la FSF a las que pueden cambiarse, muchas de ellas con útiles tutoriales en línea. Prueben alguna si aún no usan un sistema operativo libre; siempre tendrán la libertad de volver a un sistema operativo que intente limitar sus funciones.

• https://www.fsf.org/es/2025-fin-de-windows-10

Estas son solo algunas de las noticias recogidas este mes, ¡¡pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2025/noviembre

Y todos los números del «supporter» o boletín de noticias de 2025 en español, francés, portugués e inglés aquí:

• https://www.fsf.org/free-software-supporter/2025

Allá por el año 1998, se filtraron una serie de documentos confidenciales internos de Microsoft donde se documentaban sus estrategias para hacer frente al software de «código abierto» en general y GNU/Linux en particular

Desde hace un tiempo grandes empresas tecnológicas se han vuelto «adoradoras» del software de código abierto u «open source». Una versión descafeinada y menos «radical» que software libre, para que a sus accionistas no piensen que aquello es un nido de wokes radicales.

Microsoft, la gran empresa de Bill Gates que desarrolló el sistema operativo más conocido: Windows, es una de esas empresas que se decanta por esas bondades del open source que tan bien sientan en las descripciones de sus productos.

Pero no siempre ha sido así (realmente ahora es así o es un «green washing» tecnológico). Hubo un tiempo en el que Microsoft tenía estrategias contra software que amenazaba su hegemonía y que se estaba desarrollando bajo eso tan alejado de sus políticas empresariales como era el código abierto y el software libre.

Y así se inicia esta «pesadilla» de Halloween…

Esas estrategias se suponía que tenían que ser confidenciales e internas. Una serie de pautas a seguir para hacer calar en el ideario colectivo que eso del código abierto, eso del software libre, eso de GNU/Linux era una moda pasajera, y que contenía peligros que desconocíamos, pero que desde Microsoft nos relataban.

Pero hete aquí que esos documentos secretos, que relataban la versión interna de desprestigio de esas tecnologías diametralmente opuestas al software privativo y restrictivo de Microsoft se filtraron y vieron la luz.

El exponer sus estrategias internas para tratar de acabar con el código abierto y GNU/Linux, además de revelar sus prácticas nada respetuosas, revelaba que aunque trataban de minimizar su impacto, lo que veían o a lo que tenían miedo era al potencial que aquello pudiera tener y que el número de frikis que «militaba» en alguno de esos proyectos de software libre y GNU/Linux creciera. Y lo que es peor que muchas empresas adoptaran ese nuevo modelo, haciendo así peligrar su estatus.

El número de personas, proyectos y empresas que han adoptado el código abierto y/o GNU/Linux efectivamente creció de manera muy superior a lo imaginado. Hoy el 100% de los grandes supercomputadores utilizan GNU/Linux o variantes. Los servidores que hacen que funcione Internet corren GNU/Linux y software de código abierto o software libre (o una mezcla de ambos)

Pero apesar de esas cifras enormes y crecientes, Microsoft no vio peligrar su hegemonía y sigue reinando en muchos campos de la tecnología. Eso sí, ha mudado su discurso de una actitud en contra de ese código abierto a posiciones a favor (o ese es el márqueting que quieren vender)

Pero volvamos a esos documentos Halloween que evidenciaron su lucha contra la amenaza del software de código abierto. Esos documentos son reales, y son auténticos, así lo ha reconocido Microsoft. Se dieron a conocer porque llegaron a manos de Eric S. Raymond (personaje controvertido por el cual no siento mucha simpatía).

Llegaron a sus manos un 30 de octubre de 1998 y los publicó en su web con anotaciones propias un 1 de noviembre de 1998. Por coincidir con fechas de celebración de la festividad de Halloween recibieron ese nombre.

Microsoft veía en ese movimiento del código abierto y software libre, en el que también englobamos a GNU/Linux, como una amenaza y expone que una de sus estrategias sería aplicar Embrace, Extend and Extinguish en español adoptar, extender, y extinguir para tratar que Microsoft siguiera siendo la pieza fundamental de esos nuevos tiempos y seguir siendo quien marcara los pasos a seguir.

Frente a esa nueva competencia también había intentado la estrategia FUD frente a sus competidores. FUD sería Fear, Uncertainly and Doubt traducido como Miedo, Incertidumbre y Duda. Es decir frente a un competidor, hacer creer desde tu postura dominante y con capacidades casi infinitas que los competidores representan una amenaza, en quien no se puede confiar. Algo así como el miente que algo queda de Goebbles que siguen practicando la extrema derecha en el terreno político en pleno siglo XXI… pero me desvío del tema.

Eric S. Raymond publicó esos documentos con sus propias anotaciones y además de los propios documentos de Microsoft, se han complementado con otros documentos relacionados.

¿Y todo esto a qué viene?

La cosa es que echando un vistazo por la red, me pareció muy pobre, que los documentos siguieran en la web de Eric S. Raymond y que esta estuviera en un dominio sin la «s» en su http. Ese siempre me parece un paso previo a la desaparición del dominio por completo.

Cierto que hay una versión archivada en archive.org, que es desde la que he cogido los textos de los documentos, porque referencian en los enlaces a páginas también archivadas en archive.org que en muchos casos las originales ya no existen.

Con los textos de los documentos descargados he querido subirlos a un repositorio Git, para seguir dándoles visibilidad y difusión en internet y seguir haciendo que estén disponibles, si otras fuentes fallasen.

He traducido algunas partes, no de los propios documentos originales, si no de la introducción que de ellos hace Eric S. Raymond y de algunas aclaraciones respuestas a preguntas más frecuentes (FAQ) que le hicieron al respecto.

Los documentos que descargué están en un repositorio de git en GitLab y he construido una pequeña página html con ellos. Tienes la web disponible en este enlace:

• https://victorhck.gitlab.io/documentos_halloween/

No espero que los leas todos (yo no lo he hecho) pero sí que les eches un vistazo o que leas las acotaciones de Eric S. Raymond o los anexos a los documentos originales.

Recordemos que Microsoft viene de estos pensamientos, que sí, que muchos ejecutivos han cambiado y los tiempos con ellos, peeeeeero siempre me causa cierto reparo admitir que todo aquello cambió y ahora el rumbo es diametralmente opuesto. Como dijo alguna vez uno de los protagonistas sin quererlo de esos documentos Halloween, Linus Torvalds: «Hablar es fácil, enséñame el código».

Es decir, Microsoft puede comprar el mayor repositorio de código abierto y software libre que existe, como es GitHub, y muchas otras acciones, pero sigue siendo una empresa de estándares cerrados y de código privativo. Desarrolla productos abusivos con sus usuarios y les fuerza a admitir condiciones nada respetuosas… Por eso siempre tengo ese resquemor de que si lo hicieron una vez, quizás lo sigan haciendo.

En fin, aquí tienes los enlaces a los documentos originales, a los de archive.org, a mi web, etc. Lee y saca tus propias conclusiones al respecto.

Happy Halloween !!

Enlaces de interés

• https://victorhck.gitlab.io/documentos_halloween/
• https://gitlab.com/victorhck/documentos_halloween
• http://www.catb.org/~esr/halloween/
• https://web.archive.org/web/20051225052023/http://www.catb.org/~esr/halloween/index.html

Hace ya varios años desde que soy una especie de fan de KDE. Antes usaba GNOME, como la mayoría, pero Ubuntu 19.04 fue un antes y un después para mí. El entorno gráfico maduró mucho y me ofrecía todo lo que necesitaba y mucho más. Recientemente, el proyecto ha presentado KDE Linux, una distribución inmutable pensada en la producción, y ya se puede probar. Así que le he dado una oportunidad para ver si en el futuro doy otro salto en mi distrohopping.

Antes de empezar a explicar mis impresiones, hay que aclarar, aunque sea por encima, qué es una distribución inmutable. No hay acceso a todo como en un Linux tradicional. Lo importante es de sólo lectura, por lo que el sistema es más difícil de romperse. El software se obtiene e instala de otra manera, y esto tiene sus cosas buenas y sus cosas malas..

KDE Linux obtiene su software de Flathub…

KDE Linux, como la mayoría de distribuciones inmutables, obtiene su software de Flathub. Tras la instalación de cero y ahora que está en fase alfa, tiene añadidos varios repositorios más, pero para actualizar aplicaciones como Gwenview o Haruna en su versión Nightly. Se pueden añadir otros repositorios para paquetes flatpak, como el beta de Flathub, pero es algo innecesario.

Siendo yo usuario de AceStream, lo primero que hice, por saber más que nada, fue si era posible instalar paquetes flatpak de fuera de Flathub. La respuesta es sencillamente que sí. Si un desarrollador crea una app y la sube a GitHub, es posible instalarla (flatpak install nombre.de.la.app), siempre y cuando todo sea compatible.

Otra duda que tenía era si había instalado software como FFmpeg, y también. A mí me gusta realizar algunas conversiones con ese software, y funciona desde el terminal como una distro Linux de toda la vida.

Lo siguiente que hice fue probar otro comando básico para mí: yt-dlp. No está añadido por defecto, pero se puede hacer funcionar de manera sencilla para un usuario medio:

1. Primero descargo el archivo desde su GitHub.
2. Le doy permisos de ejecución con el clic derecho (también se puede con chmod -x yt-dlp).
3. Lo muevo a la carpeta ~/.local/bin/, que tuve que crear.
4. Por último, añado esa carpeta al PATH con export PATH=»$HOME/.local/bin/:$PATH».

Y yt-dlp a funcionar.

… y Snapcraft

Era algo sobre lo que había leído, pero no estaba seguro. Ha sido al hacer búsquedas en el PATH (echo $PATH) cuando he visto la carpeta snapd. No aparecen en Discover, por lo menos en el momento de escribir este artículo, pero sí se pueden buscar desde la web oficial e instalar con el comando que nos indican allí.

Por lo tanto, KDE Linux es compatible con paquetes flatpak, snap y appimage tras la instalación de cero, lo que cubre la mayor parte del software. De hecho, en Flathub hay también extensiones de aplicaciones, como G’MIC o BIMP para GIMP.

Ahora bien, G’MIC justamente no funciona, no la que hay en Discover. Pero si se va a su página web nos indican el comando a usar, y allí nos permite instalar la versión 3 que sí funciona.

Distrobox incluido por defecto

Y para todo lo que pueda dar problemas, KDE Linux tiene instalado por defecto también Distrobox. Esto nos permite instalar distribuciones en contenedores para instalar cualquier programa. Si queremos algo de repositorios de Ubuntu, instalamos Ubuntu. ¿Que lo que queremos es de Fedora? Pues un contenedor de Fedora. Esto debería permitirnos añadir a la lista de instalables los paquetes DEB, RPM y todo lo demás.

Pero no todo funciona en KDE Linux

No todo funciona perfectamente en KDE Linux. Por ejemplo, no se puede instalar PHP porque no hay repositorios oficiales a los que acudir. Si queremos usar algo como LAMP, debemos intentarlo en un contenedor, o de lo contrario será imposible. De hecho, creo que será imposible para el usuario que no llegue a medio.

También cabe destacar que el software en paquetes flatpak y snap no es tan potente y versátil como el de repositorios oficiales. Por ejemplo, si queremos que Visual Studio Code funcione al 100%, hay que instalarlo en una distro de Distrobox. Aunque yo no he echado nada de menos, es posible que nos encontremos con alguna piedra en el camino si queremos hacer un uso avanzado.

¿Me quedaré en KDE Linux?

Lo dudo. Manjaro no me ha fallado en cerca de cinco años, y no necesito una distribución inmutable. De momento me quedo en Manjaro, por mucho que me guste KDE…

… aunque podría cambiar de opinión si en un futuro veo un fallo grosero en Manjaro + no necesito nada especial de desarrollador. KDE Linux pinta bien, pero aún está dando sus primeros pasos.

Hace aproximadamente una semana desde que Microsoft le dio al botón y abandono Windows 10. Por el mismo tiempo llegó una nueva versión de Zorin OS, una de las distribuciones más populares para los que quieren dar el salto desde un sistema de Microsoft. Y ya no lo digo yo; el mismo proyecto ha publicado este 21 de octubre que en una semana han sido 300.000 los usuarios que han descargado Zorin OS 18, y la mayoría lo hacen desde Windows.

Así que a nosotros nos ha parecido buena idea publicar un artículo para ayudar en el proceso de descarga e instalación de Zorin OS en cualquier equipo compatible. Si te has decidido a venir a Windows, te damos la bienvenida. Si no sabes por dónde empezar, no te preocupes, que a continuación vamos a detallar todo lo necesario para que puedas hacer el cambio.

Descargar Zorin OS

Zorin OS está disponible en tres versiones:

• La Pro, que es de pago, con un precio de 47.99€.
• La versión para la educación.
• La Core, que es la, digamos, normal.

Podremos descargar la versión Core desde su página de descargas, bajando un poco.

Al hacer clic en «Download» aparecerá una ventana emergente que nos invita a suscribirnos a su boletín de noticias. Yo recomiendo hacer clic en «Skip to download», lo que empezará a descargar la ISO de Zorin OS.

El tiempo de descarga puede variar. Si tarda mucho, se pueden elegir diferentes servidores.

Crear medio de instalación

Ahora que tenemos la ISO de Zorin OS en nuestro equipo, llega el momento de crear el medio de instalación. Hay muchas maneras de hacerlo, pero yo recomiendo usar Etcher:

1. Vamos a su página web oficial. En caso de no estar en Windows, Etcher está en repositorios como AUR, como AppImage y también como paquetes DEB y RPM. Pero suponemos que si estáis aquí es porque queréis migrar desde Windows. Las capturas son de Linux, pero la versión de Windows es igual.
2. Se descarga el instalador y se instala el programa.
3. A continuación, se inicia el programa. Si pide permisos de administrador, se le concede.
4. La interfaz de Etcher es muy sencilla:
   1. En el primer paso, se elige la ISO que queremos instalar haciendo clic en «Flash from file» y buscando la ISO de Zorin OS.

1. 2. En el segundo, la unidad en donde queremos crear el medio de instalación. Es más que suficiente uno de 8GB. Si es muy grande, nos preguntará para no borrar nada importante.

1. 3. Por último, le damos a «Flash», si pide permisos de administrador — o contraseña en Linux — aceptamos y esperamos. Al final tiene un paso en el que verifica que todo haya salido bien, y yo, que ya he usado esto muchas veces, suelo darle a omitir, pero no lo recomiendo.

Otra opción es hacerlo con Rufus, pero tiene más opciones y puede ser complicado. Lo que sí recomiendo es probar Rufus si Etcher da fallo de alguna manera. Rufus permite crear medios instalación para BIOS, UEFI o una opción que, en teoría, funciona en ambos casos.

Instalación del sistema operativo

Para poder instalar el sistema operativo hay que apagar el equipo o reiniciarlo e iniciar desde el medio de instalación que acabamos de crear. Es virtualmente imposible que podamos abarcar todas las opciones de todos los ordenadores que existen, pero hay que conseguir que inicie desde el USB. ¿Cómo? Depende del equipo. En mi portátil, yo puedo entrar a la BIOS (que aunque mi equipo es UEFI se sigue llamando BIOS a ese apartado) con F2 y cambiar el orden de inicio para que arranque primero desde el USB. También puedo pulsar F12 para seleccionar unidad de arranque, que es otra opción que tiene.

En otros casos será diferente. Puede que entrar a la BIOS sea con la tecla Supr, puede ser otro Fx y puede que haya opción de seleccionar arranque con otro Fx, como F7 en mi mini PC. Tenéis que averiguar cómo e iniciar desde el USB.

Proceso de instalación de Zorin OS

1. Una vez iniciado desde el USB, lo primero que veremos será una opción para probar o instalar el sistema. Podemos pulsar Intro o esperar a que entre automáticamente.

2. Lo primero que aparecerá a continuación será una opción para probar el sistema o instalarlo directamente. Yo he elegido «Probar» por la sencilla razón de que las capturas quedan mejor si se entra al sistema. Todo lo que veréis a continuación es la interfaz con el sistema abierto de fondo, pero da lo mismo si se elije la opción «Instalar» directamente
3. Ya en el instalador, el primer paso nos pedirá elegir idioma. En nuestro caso, elegimos «Español» y luego hacemos clic en «Continuar».

4. En el siguiente paso tenemos que elegir la disposición del teclado. A la izquierda se elige el idioma, y a la derecha al variante. Con la disposición de teclado elegida, se hace clic en «Continuar».

5. A continuación indicaremos si queremos descargar las actualizaciones mientras se instala Zorin OS o no, si queremos que se instale software de terceros o no y si queremos participar en el censo. Yo recomiendo marcar las dos primeras. Luego, «Continuar».

6. El siguiente paso es de los más importantes, pero también de los más confusos. Si lo que se busca es reemplazar Windows 10 con Zorin OS, se elige «Borrar el disco» y luego «Instalar ahora». Si ya había un sistema en el disco duro, el instalador lo detectará y nos permitirá instalar Zorin OS junto al sistema que ya había. Esto se conoce como Dualboot o inicio dual, y es posible mantener Windows junto a Zorin OS. De elegir esa opción, en una ventana se elegirá cuánto tamaño se le da a cada sistema operativo. La opción «Más opciones» es para crear particiones, eliminarlas y también para otras cosas que no vamos a explicar aquí.

7. Al «Instalar ahora» anterior le sigue una confirmación. En la ventana resumen de lo que va a hacer podemos «Volver» para hacer alguna modificación o «Continuar» y empezar la instalación.

Pasos finales

8. La instalación ya ha comenzado, pero faltan algunos ajustes más. El siguiente es elegir la zona horaria y luego «Continuar».

9. Ya casi hemos terminado nuestro trabajo. Lo último que tenemos que hacer es crear el usuario.
   • Nombre: ponemos nuestro nombre completo. Yo suelo ponerlo, pero para tutoriales elijo poner mi nick.
   • Nombre del equipo: cómo queremos que se llame el equipo.
   • Nombre de usuario: este es el nombre que aparecerá en el terminal, grupos y demás.
   • Contraseña: una contraseña de inicio de sesión y para el terminal. Hay que ponerla dos veces.
   • Se puede elegir que inicie directo, lo que no se recomienda en muchos escenarios, o que pida la contraseña.
   • También se puede cifrar el disco para mayor seguridad, algo que no he hecho nunca en mi vida. Pero poderse, se puede.

10. Tras darle a «Continuar» en la ventana anterior, esperamos. Veremos diapositivas y diferentes consejos.
11. Cuando finalice, aparecerá una ventana emergente más pequeña diciendo que podemos reiniciar o seguir probando. Para finalizar la instalación, le damos a «Reiniciar»

12. Por último, veremos una ventana con el logotipo que nos dirá que quitemos el medio de instalación y pulsemos Enter. Lo hacemos y cuando reinicie ya estaremos en Zorin OS.

Y eso sería todo. Ahora toca disfrutar de la buena vida.

El ecosistema maker suma un nuevo miembro de peso: Arduino UNO Q llega como una placa de formato clásico UNO, como en el caso del UNO R4 que combina cómputo avanzado con control en tiempo real. La propuesta se centra en permitir que proyectos de robótica, IoT, visión y audio escalen sin renunciar a la sencillez habitual de Arduino.

En paralelo al anuncio de su integración con Qualcomm, la compañía presenta el primer fruto de esa alianza: una placa con “doble cerebro” donde un procesador Linux convive con un microcontrolador RTOS. El objetivo es claro: unir IA en el edge y respuestas deterministas bajo un mismo diseño y con herramientas accesibles.

Arduino UNO Q con arquitectura de doble cerebro: Linux y tiempo real, juntos

En el corazón del UNO Q se encuentra el Qualcomm Dragonwing QRB2210, un SoC capaz de ejecutar Debian y acelerar cargas de trabajo de IA, acompañado por un STM32U585 que se encarga de las tareas en tiempo real. Esta combinación permite desarrollar aplicaciones que requieren procesamiento intensivo y control preciso sin repartir funciones en placas separadas.

La placa está pensada para ejecutar Linux (Debian) en el procesador y un RTOS como Zephyr en el microcontrolador, facilitando diseños de baja latencia con interfaces familiares, en entornos donde Arduino Create ya es compatible con GNU/Linux. Además, el motor gráfico y el soporte de librerías modernas abren la puerta a visión por computadora y pipelines multimedia con un enfoque de desarrollo más directo.

Hardware y conectividad para ir más allá del prototipo

UNO Q se ofrece con 2 GB o 4 GB de RAM LPDDR4 y almacenamiento eMMC de 16 GB o 32 GB, de modo que la placa puede comportarse como un miniordenador cuando es necesario. La conectividad incluye Wi‑Fi 5 y Bluetooth 5.1, junto a un puerto USB‑C que permite alimentación, datos y uso de periféricos, de forma que se puede trabajar con monitor, teclado y ratón sin depender de un PC anfitrión.

Para integrarse en sistemas embebidos, la placa conserva el ADN UNO con un tamaño aproximado de 68,85 × 53,34 mm y compatibilidad con accesorios del ecosistema, y herramientas de diseño como Fritzing. En el apartado de E/S, ofrece I2C/I3C, SPI, PWM, CAN, UART, GPIO y ADC, además de soporte para cámaras USB y MIPI CSI, audio y múltiples buses de expansión.

Desarrollo: IDE de Arduino, App Lab y ecosistema Qualcomm

Además del IDE clásico de Arduino, la compañía estrena Arduino App Lab, un entorno de desarrollo de código abierto que unifica flujos en tiempo real, Linux, Python e IA. La idea es reducir la fricción entre dominios, acelerar la iteración y facilitar tanto el prototipado como la industrialización.

La integración con Edge Impulse permite crear y ajustar modelos para tareas de detección de personas y objetos, clasificación de imágenes o reconocimiento de palabras clave y sonidos ambientales. Con la potencia del Dragonwing y el soporte de librerías modernas, es viable desplegar pipelines de IA en el borde sin depender de infraestructuras complejas. Para quienes lo necesiten, el procesador admite workflows basados en contenedores y herramientas de DevOps habituales en Linux.

Casos de uso de la Arduino UNO Q: del hogar inteligente a la fábrica

El formato y la arquitectura dual facilitan diseños que van desde hogares inteligentes, control industrial y robótica hasta visión embebida y tratamiento de audio. Con el microcontrolador gestionando sensors, actuadores y tiempos críticos, el procesador puede encargarse de inferencias de IA, visualización o comunicación, todo en una sola placa.

Precio, versiones y disponibilidad de la Arduino UNO Q

La configuración base de 2 GB de RAM y 16 GB eMMC se sitúa en el entorno de los 44 dólares en EE. UU. y 47,60 euros en España, mientras que la opción de 4 GB y 32 GB eMMC está prevista a un precio superior. Según el calendario compartido por la marca, las reservas ya están activas y los primeros envíos se esperan para finales de octubre, con la variante de mayor memoria prevista para noviembre en determinados mercados.

Tras la alianza con Qualcomm

Qualcomm ha comunicado la adquisición de Arduino, sujeta a aprobación regulatoria, y ambas compañías aseguran que la marca, el enfoque de código abierto y el soporte a múltiples fabricantes se mantendrán. Con una comunidad de más de 33 millones de desarrolladores, Arduino gana acceso a herramientas y capacidades de procesamiento, gráficos y visión del ecosistema Qualcomm, mientras que este se acerca aún más al universo maker y profesional.

Más allá del lanzamiento del UNO Q, ambas partes apuntan a nuevos productos y utilidades que aprovechen la combinación de software y hardware, incluyendo integraciones con plataformas como Edge Impulse y Foundries.io para acelerar rutas de desarrollo, pruebas y comercialización.

Con el formato UNO de siempre y un cerebro doble capaz de ejecutar Debian y un RTOS en paralelo, la nueva placa coloca IA y control determinista en la misma base de hardware, apoyándose en App Lab para un flujo de trabajo continuo y en una conectividad amplia para integrarse en proyectos reales; un paso natural para quienes quieran prototipar y escalar sin cambiar de plataforma.

40 años promoviendo la libertad de las personas que utilizan la informática. 40 años denunciando la injusticia del software privativo. Happy hacking

El 4 de octubre de 1985 se formalizaba la creación de la Free Software Foundation por parte de su fundador Richard Stallman.

Hoy 40 años después esa organización local ha aunado a personas de diferentes países y condiciones con un objetivo común: defender la libertad (cada vez más acotada e infravalorada) de las personas que software.

Y para ello la condición sine qua non es la libertad del software. Y para conseguir esa libertad del software, este debe seguir estas 4 libertades:

• La libertad de ejecutar el programa como se desee, con cualquier propósito (libertad 0).
• La libertad de estudiar cómo funciona el programa, y cambiarlo para que haga lo que se desee (libertad 1). El acceso al código fuente es una condición necesaria para ello.
• La libertad de redistribuir copias para ayudar a otros (libertad 2).
• La libertad de distribuir copias de sus versiones modificadas a terceros (libertad 3). Esto le permite ofrecer a toda la comunidad la oportunidad de beneficiarse de las modificaciones. El acceso al código fuente es una condición necesaria para ello.

Nótese que en ningún momento se habla de precio o dinero. La libertad del software nada tiene que ver con su precio.

A partir de ahí surgieron las licencias libres, aquellas que hacen que el software sea libre y se mantenga libre y que nadie pueda arrebatarle esa libertad al software.

Acerca de la Free Software Foundation (FSF)

La Free Software Foundaton (FSF) es una organización sin fines de lucro con la misión mundial de promover libertad delas personas que usan computadoras. Defiende los derechos de todos los usuarios de software.

La FSF, fundada en 1985, se dedica a promover el derecho de los usuarios de computadoras a usar, estudiar, copiar, copiar, modificar y redistribuir programas informáticos. La FSF promueve el desarrollo y el uso de software libre —particularmente el sistema operativo GNU y sus variantes GNU/Linux— y documentación libre para el software libre. La FSF también ayuda a difundir la conciencia de la ética y cuestiones políticas de libertad en el uso del software.

Qué realiza la FSF

• Financiación y promoción libre del desarrollo de software
• Defender el software libre, incluido el sistema operativo GNU, de los esfuerzos por convertirlo en privativo
• Hacer campaña por el software libre y en contra del software privativo
• Fomento del desarrollo del sistema operativo GNU
• Patrocinio fiscal de importantes proyectos de software libre
• Proporcionar infraestructura para el proyecto GNU para mantener el software
• Patrocinio del Proyecto GNU
• Publicar y administrar la familia de licencias GNU, que incluyen: la Licencia Pública General de GNU (GNU GPL), GNU Lesser General Public License (LGPL), GNU Affero General Public (AGPL) y la Licencia de Documentos Libres de GNU (FDL)
• Proporcionar recursos importantes a la comunidad, incluido el Directorio de Software Libre
• Mantener la definición de software libre
• Difundir los argumentos sobre la filosofía del software libre
• Recopilar a través de la cesión y la posesión de los derechos de autor una gran proporción del sistema operativo GNU y otros programas libres

Campañas que llevan a cabo la FSF

Además de todas las tareas anteriores, la FSF también se embarca en diferentes campañas puntuales sobre puntos clave para la defensa del software y de las personas que lo utilizan:

• Campaña para que el hardware funcione bajo software libre
• En contra del DRM que hace que el fabricante siga teniendo control sobre tu equipo aunque te pertenezca
• Finalización de patentes
• El derecho a reparar tus propios equipos
• Liberar la BIOS de tus equipos informáticos
• Persuadir a las instituciones del uso de JavaScript libre en sus webs
• Ayudar a las personas a cambiar al software libre
• Sistema operativo GNU
• y muchas otras campañas que defienden ciertos aspectos de la libertad del software…

Breve historia de los 40 años de la FSF

• Sep 1983 – El proyecto es anunciado por Richard Stallman
• Mar 1985 – Se publica el manifiesto GNU
• Oct 1985 – Se crea la FSF con Richard Stallman como presidente
• Feb 1986 – Publicada la primera versión de la definición de «software libre»
• Feb 1989 – Se publica la licencia GNU General Public License (GPL
• Oct 1999 – UNESCO y la FSF publican el Free Software Directory (FSD)
• Mar 2001 – Bradley Kuhn se convierte en el primer director ejecutivo de la FSF
• Mar 2001 – Se establece la FSFE en Europa
• Abril 2001 – Se crea la Free Software Foundation en Francia
• Jul 2001 – Se crea la FSF en la India
• Dec 2001 – Se crea el laboratorio de Licencias y Cumplimientos
• Nov 2002 – Se lanza el programa de miembros asociados
• Mar 2003 – La FSF celebra su primer encuentro anual
• Feb 2005 – Peter Brown se convierte en el segundo director ejecutivo
• Nov 2005 – Se crea la FSF en Latino América
• May 2006 – Se crea la campaña Defective by Design
• Jun 2007 – Se publica la licencia GNU GPLv3
• Nov 2007 – Se publica la licencia AGPLv3
• Mar 2008 – Se publica la primera edición del boletín de noticias de la FSF
• Mar 2009 – Se celebra la primera conferencia anual LibrePlanet
• Mar 2011 – John Sullivan se convierte en el tercer director ejecutivo
• Oct 2012 – Lulbotz es el primer dispositivo de hardware en recibir la certificación Respects Your Freedom (RYF)
• Dec 2013 – Gluglug x60 es el primer portátil en recibir la certificación RYF
• Jun 2014 – Se publica la guía sobre autodefensa del correo electrónico
• Dec 2015 – Los miembros asociados llegan a la cifra de 4.000
• Mar 2019 – El boletín de noticias llega a los 200.000 suscriptores
• Ago 2020 – Geoffrey Knauth elegido como presidente de la FSF
• Feb 2021 – FSF recibe una puntuación perfecta de Charity Navigator
• Feb 2011 – Zoë Kooyman se convierte en la cuarta directora ejecutiva
• Ene 2023 – FSF lanza el nuevo proceso de miembros del consejo que involucra a los miembros asociados
• May 2024 – FSF es depuesto en el caso de in Software Freedom Conservancy vs. VIZIO
• Ago 2024 – La FSF se convierte en una organización sin sede, abandonando la oficina en Franklin St de Boston después de 19 años
• Ago 2024 – La FSF forma parte del MMM del NIST de los Estados Unidos sobre la seguridad de la llamada «inteligencia oficial»
• Oct 2024 – FSF comienza a trabajar en la libertad de aplicaciones de machine learning
• May 2025 – La FSF lanza la iniciativa LibreLocal
• Oct 2025 – La FSF cumple 40 años
• Nov 2025 – Se celebra el FS40 Hackathon

La historia sigue…

40 años defendiendo el softwar de todos los ataques a los que se ve sometido en muchos frentes desde corporaciones más poderosas en recursos, y en alcance. Pero la FSF ha vertebrado un movimiento que se ha expandido de manera global para colaborar en diferentes frentes contra esa esclavización del software y por consiguiente de las personas que lo utilizan.

En estos 40 años ha inspirado y ha sido ejemplo de cómo combatir la injustica del software privativo y se han creado alternativas que poco a poco han ido ganando en calidad y contribuciones, hasta llegar al punto actual en el que el software libre es una alternativa totalmente válida.

Y todo eso como entidad independiente, sostenida por las contribuciones de las personas que son socias de la FSF y aportan una cuota para mantener toda su infraestructura y todo aquello que mantienen y por lo que siguen luchando como en estos 40 años de historia.

Enlaces de interés

• https://www.fsf.org
• https://www.gnu.org/
• https://my.fsf.org/donate
• https://www.fsf.org/associate/

Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía, frente a las restricciones y abusos a los usuarios por parte del software privativo.

Por cierto este mes se cumplen 40 años de la creación de la FSF.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2025/october
• Y traducido en español (cuando el equipo de traducción lo tengamos disponible) en este enlace: https://www.fsf.org/free-software-supporter/2025/octubre

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

¿Te gustaría aportar tu ayuda en la traducción y colaborar con la FSF? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de octubre de 2025.

Rincón legal: La guerra contra los bloqueadores de anuncios: el asalto de Axel Springer a la libertad del usuario

Del 16 de septiembre por la FSFE

Para muchos usuarios de Internet, los bloqueadores de anuncios son una pieza importante de software que les permite controlar la información digital que reciben de sus navegadores, proporcionando una experiencia de navegación sobre la que tienen más control. En una sentencia de 2023, un tribunal alemán afirmó que el uso de bloqueadores de anuncios es una elección que los usuarios tienen derecho a hacer en función de la libertad de elegir qué información recibir y rechazar.

A pesar de esto, una decisión reciente del Tribunal Federal de Justicia de Alemania le está dando a Axel Springer, una gran empresa de medios y publicaciones que presentó la demanda de 2023 contra el bloqueador de anuncios de software libre AdBlock Plus, una segunda oportunidad para erosionar la libertad del usuario.

Siga leyendo para comprender mejor cómo un posible veredicto positivo para Axel Springer afectaría los derechos de los usuarios.

• https://fsfe.org/news/2025/news-20250916-01.en.html
• https://victorhckinthefreeworld.com/2025/08/25/la-lucha-contra-los-bloqueadores-de-publicidad-sigue/

F-Droid dice que las nuevas restricciones de transferencia local de Google acabarán con el proyecto

Del 29 de septiembre por Ryan Whitwam

Las nuevas restricciones de Google para los desarrolladores de Android podrían acabar con las tiendas de aplicaciones de software libre como F-Droid. F-Droid existe desde hace unos 15 años y es la mayor fuente de software libre para Android.

Las aplicaciones en F-Droid no se instalan a través de Google Play Store, sino que se descargan. Google está apuntando a ese proceso en nombre de la llamada seguridad. Lea más sobre cuán peligrosas y bloqueadoras de la libertad son las nuevas restricciones de Google para el progreso del software libre en los teléfonos móviles en el siguiente artículo.

• https://arstechnica.com/gadgets/2025/09/f-droid-calls-for-regulators-to-stop-googles-crackdown-on-sideloading/

La actualización de software introduce anuncios a los costosos refrigeradores de Samsung

Del 18 de septiembre por Scharon Harding

Samsung ha encontrado otra forma de demostrar lo poco que les pertenecen a los usuarios sus propios dispositivos: léase aquí, el refrigerador «inteligente», cuyo precio oscila entre 1.800$ y 3.500$.

Bajo la última actualización, Samsung está enviando anuncios a las pantallas de los refrigeradores sin el consentimiento del usuario. Desafortunadamente, debido a que el usuario no controla su propio refrigerador, no hay forma de que los usuarios eviten que Samsung se meta en los hogares de las personas.

Cuando compra un electrodoméstico, aunque solo sea por unos pocos dólares, es completamente razonable esperar que lo posea y tenga el control total de él, y debería ser cierto para los electrodomésticos más caros. Puede leer más sobre este inquietante programa piloto en el siguiente artículo.

• https://arstechnica.com/gadgets/2025/09/samsung-forces-ads-onto-fridges-is-a-bad-sign-for-other-appliances/

Estas son solo algunas de las noticias recogidas este mes, ¡¡pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2025/octubre

Y todos los números del «supporter» o boletín de noticias de 2025 en español, francés, portugués e inglés aquí:

• https://www.fsf.org/free-software-supporter/2025

La nueva rama OpenSSL 3.6 ya está disponible, seis meses después de la anterior, como actualización de gran calado del popular conjunto de librerías criptográficas de código abierto. Llega con cambios funcionales, mejoras de seguridad y optimizaciones de rendimiento que impactan tanto a servidores como a aplicaciones cliente.

Además de incorporar soporte para tecnologías recientes y ajustes exigidos por estándares, esta versión introduce utilidades y APIs que simplifican la integración. En el plano práctico, se endurecen comprobaciones internas, se mejora la interoperabilidad y se afinan rutas críticas de cifrado en varias arquitecturas.

Novedades clave en funciones y protocolos de OpenSSL 3.6

Entre los cambios más visibles destaca la verificación de firmas LMS conforme a NIST SP 800-208 en los proveedores FIPS y por defecto, junto con la llegada de objetos de clave simétrica opacos EVP_SKEY para los métodos de derivación e intercambio de claves, accesibles vía EVP_KDF_CTX_set_SKEY(), EVP_KDF_derive_SKEY() y EVP_PKEY_derive_SKEY().

• CMS incorpora KEMRecipientInfo (RFC 9629) y soporte ML-KEM (borrador draft-ietf-lamps-cms-kyber), facilitando el uso de criptografía resistente a futuros adversarios cuánticos.
• El servidor puede habilitar OCSP multi-stapling en TLS 1.3, mejorando la entrega de estado de revocación para cadenas con múltiples certificados.
• Se permite definir un «free function thunk» en los tipos de pila OPENSSL_sk, dando más control sobre la liberación de recursos.

Seguridad y cumplimiento FIPS

La versión refuerza las garantías en modo validado con Pruebas de Autocomprobación (PCT) FIPS 140-3: en generación de claves DH, en importación de claves para SLH-DSA cuando se usa FIPS, y en el proveedor FIPS al importar claves RSA, EC y ECX, cumpliendo la guía IG 10.3.

También se añade a dicho proveedor el soporte de generación determinista de firmas ECDSA según FIPS 186-5, y se incorporan categorías de seguridad NIST para objetos PKEY, lo que facilita clasificar y aplicar políticas en función del nivel criptográfico requerido.

Rendimiento y optimizaciones por arquitectura en OpenSSL 3.6

En x86_64, OpenSSL 3.6 incorpora optimizaciones Intel AVX-512 y VAES para AES-CFB128, con mejoras notables en cargas de trabajo intensivas. En AArch64 (ARM de 64 bits) llega el soporte del algoritmo entrelazado AES-CBC+HMAC-SHA, pensado para acelerar escenarios de cifrado autenticado.

La arquitectura LoongArch recibe una implementación en ensamblador de SHA-2 para aumentar el rendimiento, mientras que el stack QUIC añade una notificación cuando todos los FIN de los flujos han sido reconocidos, adelantando información útil al plano de la aplicación.

Cambios en compilación y herramientas

El proyecto abandona definitivamente los compiladores ANSI-C: a partir de ahora es necesario un toolchain con características C99 para construir OpenSSL. Junto a ello, se añade la utilidad openssl configutl, pensada para procesar el archivo de configuración y volcar uno equivalente.

En el terreno de mantenimiento, se elimina el soporte para VxWorks y quedan obsoletas las funciones relacionadas con EVP_PKEY_ASN1_METHOD. Además, la aplicación incluye nuevas opciones CRYPTO_MEM_SEC y CRYPTO_MEM_SEC_MINSIZE para inicializar memoria segura de forma explícita.

Formatos, interoperabilidad y robustez

Se incrementa el parámetro por defecto PKCS12 macsaltlen de 8 a 16 (alineado con NIST SP 800-132) y se mejora la interoperabilidad de nuevos almacenes PKCS12 entre implementaciones FIPS y no FIPS, reduciendo fricciones en migraciones y auditorías.

En la capa de utilidades, openssl req ya no genera certificados con la lista de extensiones vacía cuando SKID/AKID se establecen a «none». Además, se añade una comprobación ausente para endurecer la operación pública RSA «encrypt»: el búfer de salida indicado por el llamador debe ser, como mínimo, del tamaño del módulo en bytes.

El manejo de claves HMAC deja de utilizar reservas de memoria segura (evitando sobrecostes innecesarios para este caso), y el API CRYPTO_THREAD__local se amplía para disminuir la dependencia de variables TLS específicas del sistema operativo.

Disponibilidad y soporte

La publicación de OpenSSL 3.6 se considera final y estable, con soporte de ciclo regular durante dos años. El equipo del proyecto agradece las contribuciones de la comunidad; las notas de la versión y el código fuente están disponibles en el repositorio oficial para quien desee compilar desde origen.

Esta entrega consolida el pilar de seguridad con controles FIPS más estrictos, amplía capacidades en protocolos como CMS y TLS, y exprime el rendimiento en arquitecturas populares; a la vez, moderniza el entorno de compilación y simplifica la administración con nuevas utilidades y ajustes de interoperabilidad.

La llegada de GNU Linux-libre 6.17 marca un nuevo peldaño para quienes buscan un sistema con 100% software libre en sus equipos. Esta edición se publica inmediatamente después del lanzamiento del kernel Linux 6.17 y aplica su tradicional proceso de limpieza de blobs (deblobbing) para eliminar microcódigo y firmware no libres, lo que, como es sabido, reduce el soporte de cierto hardware moderno pero asegura una base coherente con los principios de la Free Software Foundation.

En esta versión se han afinado múltiples frentes: desde la depuración del controlador Intel IPU7 y varios ficheros devicetree para AArch64, hasta ajustes de deblobbing en controladores como AMDGPU, prueth, iwlwifi, btusb, pci mhi host, adreno a6xx, nova-core y el audio Intel AVS. También se han adaptado cambios a raíz del traslado de los controladores PCI HDA corriente arriba y se ha retirado el deblobbing de QLogic InfiniBand, que ha desaparecido upstream. Como ya es costumbre, el proyecto sigue además invirtiendo en nuevo arte para cada lanzamiento.

Cambios específicos de GNU Linux-libre 6.17

La lista de ajustes propios de GNU Linux-libre 6.17 es extensa, con un foco claro en controladores muy utilizados. Entre los puntos destacados, se ha ajustado el deblobbing de varios drivers: AMDGPU (gráficos de AMD), prueth (red sobre PRU/ETH), drivers Intel Wi‑Fi en GNU Linux (iwlwifi), btusb (Bluetooth sobre USB), pci mhi host (buses MHI en PCIe), adreno a6xx (gráficos Adreno), nova-core (el driver en Rust de código abierto para GPUs NVIDIA) e Intel AVS (audio de Intel). Estos cambios buscan evitar llamadas o dependencias a firmware no libre que se hayan introducido o modificado con la base de Linux 6.17.

Una novedad especialmente visible es la limpieza del controlador Intel IPU7, la unidad de procesado de imagen que da soporte a webcams en portátiles de última hornada. Este IPU7 llega con Linux 6.17 para equipos con procesadores Lunar Lake y se extiende a los próximos Panther Lake, pero su funcionamiento implica blobs de firmware. GNU Linux-libre neutraliza esas rutas, lo que protege la libertad del sistema a costa de que, en muchos casos, esas webcams no funcionen sin componentes no libres.

Además, se han limpiado ficheros devicetree variados para AArch64, reforzando la coherencia del árbol de dispositivos con las políticas de eliminación de blobs. Por su parte, los controladores PCI HDA han sufrido ajustes a raíz de su movimiento corriente arriba (upstream), lo que ha exigido recalibrar el deblobbing para evitar falsas dependencias. Finalmente, se ha eliminado el deblobbing asociado a QLogic InfiniBand, ya que esos controladores se han retirado upstream y ya no es necesario mantener excepciones o parches de limpieza.

Intel IPU7 y el impacto en webcams modernas

Linux 6.17 incorpora el soporte inicial para Intel IPU7, el motor de captura y procesado de imagen que habilita la cámara web en algunos portátiles de última generación con Lunar Lake, así como en los modelos Panther Lake que están por venir. Ese soporte, en el kernel estándar, depende de blobs de firmware propietarios. En GNU Linux-libre 6.17, el equipo ha actuado para evitar que esos blobs se carguen, de forma que la plataforma siga siendo plenamente libre. Esto puede traducirse en que la webcam de determinados ultrabooks recientes quede sin soporte funcional al usar Linux‑libre.

Para usuarios que valoren la libertad por encima de todo, este enfoque tiene pleno sentido. Para quienes necesiten la cámara integrada sin complicaciones, será necesario evaluar si su equipo exige firmware no libre para el IPU7 y, en ese caso, sopesar alternativas (por ejemplo, usar el kernel estándar hasta que existan opciones libres o recurrir a cámaras USB compatibles cuyo funcionamiento sea completamente libre).

Novedades generales heredadas de Linux 6.17 en GNU Linux-libre 6.17

Aunque GNU Linux-libre retira blobs y rutas no libres, el proyecto hereda la base tecnológica de Linux 6.17. Esto significa que buena parte de las mejoras en arquitecturas, rendimiento, seguridad, redes, sistemas de ficheros y controladores también están presentes, siempre que no requieran firmware propietario. A continuación, se resumen las más relevantes.

Arquitecturas, CPU y núcleo de GNU Linux-libre 6.17

En el terreno de las arquitecturas, Linux 6.17 suma soporte para el Branch Record Buffer Extension (BRBE) de ARM, una característica útil para análisis y trazado de ejecución a bajo nivel. También se añade el AMD Hardware Feedback Interface (HFI), pensado para mejorar decisiones de rendimiento basadas en telemetría del hardware. En Intel, se incorpora soporte para Wildcat Lake y Bartlett Lake‑S, lo que permite detectar y gestionar mejor esas plataformas. Además, se estrena soporte de BPF para LoongArch, ampliando el alcance de esta pieza clave de observabilidad y filtrado dentro del kernel.

Otra novedad importante es el live patching en AArch64 (ARM de 64 bits), que abre la puerta a aplicar parches en caliente sin reiniciar en esa arquitectura. En paralelo, se añaden tracepoints de llamadas al sistema en UML (User‑Mode Linux), facilitando la instrumentación de kernels que corren como procesos de usuario. Y aparece el soporte inicial para proxy execution, un mecanismo cuyo desarrollo apunta a nuevas posibilidades de ejecución delegada dentro del núcleo.

Virtualización, seguridad y verificación en tiempo de ejecución

Para virtualización sobre ARM, se suma soporte del controlador de interrupciones GICv5 en KVM, mejorando la capacidad y el rendimiento de máquinas virtuales en esa arquitectura. En materia de seguridad, AppArmor gana capacidad para controlar el acceso a sockets AF_UNIX, refinando aún más las políticas de aislamiento de procesos. Además, el subsistema de verificación en tiempo de ejecución incorpora monitores de lógica temporal lineal (LTL), útiles para comprobar propiedades del sistema mientras este está funcionando.

Entre los cambios más llamativos también se menciona una implementación completa del “vector de ataque” en x86. Aunque el detalle fino es técnico, la idea es que el núcleo amplía su cobertura de casos y escenarios de seguridad en esa arquitectura, fortaleciendo su postura defensiva y las bases para futuras mitigaciones.

Memoria, planificación y observabilidad

En gestión de memoria, entra en escena DAMON_STAT, un nuevo módulo que simplifica el seguimiento de la actividad del gestor de memoria (MM), facilitando estadísticas sin tener que montar infraestructuras de observación complejas. También se añade una opción para reservar espacio para volcados de kernel (crash dumps), lo que hace más fiable la captura de información tras un fallo crítico.

En el planificador, Linux 6.17 agrega control de ancho de banda basado en cgroups a la clase de planificador extensible, permitiendo repartir de forma más fina los recursos de CPU en entornos multi‑tenant o con cargas mixtas. Por último, en s390 aparecen mejoras para intercambio y migración de huge pages transparentes, optimizando escenarios de memoria a gran escala en esa plataforma.

Redes y transporte

En redes, el subsistema MCTP gana soporte de enrutado por gateway, lo que amplía su utilidad en topologías complejas de gestión de componentes. TCP multipath puede ahora ajustar la opción TCP_MAXSEG, y se incorpora DualPI2 como nuevo algoritmo de control de congestión. Además, se introduce el sysctl IPv6 force_forwarding, que habilita el reenvío por interfaz, afinando políticas de enrutamiento.

Sistemas de ficheros

El sistema Btrfs recibe soporte de large‑folio, un paso importante para reducir sobrecarga y mejorar eficiencia en operaciones de memoria. EXT4 mejora su escalabilidad tanto en la asignación de bloques como en la E/S con buffer, lo que debería verse reflejado en menor contención y mayor rendimiento bajo carga. EROFS, por su parte, suma compresión de metadatos, recortando huella y potencialmente acelerando accesos en ciertas cargas de sólo lectura.

Controladores y soporte de hardware en GNU Linux-libre 6.17

En el área de drivers, destaca un nuevo controlador para acceder a gráficas discretas de Intel en dispositivos NVM, abriendo vías de gestión y diagnóstico más directas. Se incluyen mejoras para el Framework Laptop 13 con AMD Ryzen AI 300, así como soporte para portátiles ASUS Commercial que usan el chip de audio CS35L41 bajo HDA, y compatibilidad con los HP EliteBook x360 830 G6 y HP EliteBook 830 G6.

En placas y sistemas embebidos, aparece un regulador para la pantalla Raspberry Pi V2 de 7» (720×1280), soporte pinmux/pinconf para Raspberry Pi 1 y compatibilidad con el Argon40 Fan HAT. También llega SoundWire para la plataforma AMD ACP 7.2, y se añaden compatibilidades peculiares como las Touch Bar de los MacBook Pro x86, los dispositivos Forcepad (F21) o el OneXPlayer X1 Pro. Todo esto, claro está, sujeto a que no se requiera firmware propietario en el entorno Linux‑libre.

Disponibilidad de GNU Linux-libre 6.17, descargas e instalación

El proyecto ha anunciado la disponibilidad de los tarballs comprimidos de GNU Linux‑libre 6.17 en su web oficial, como en la llegada de Linux‑libre 6.16. Para quienes prefieran paquetes ya listos, existen binarios para distribuciones basadas en Debian (DEB) y en Red Hat (RPM), proporcionados respectivamente por los proyectos Freesh y RPM Freedom. La instalación del kernel GNU Linux‑libre es posible en prácticamente cualquier distribución, ya sea en paralelo al kernel estándar o como sustituto.

Si tu objetivo no es usar Linux‑libre sino el kernel Linux 6.17 estándar, puedes descargarlo desde kernel.org o desde el árbol git de Linus Torvalds. No obstante, la recomendación habitual es esperar a que la nueva versión aterrice en los repositorios estables de tu distribución para evitar incompatibilidades y disfrutar de parches de integración específicos.

Hoja de ruta: lo que viene con 6.18

Con el lanzamiento de Linux 6.17 se abre la ventana de fusiones (merge window) para la siguiente rama mayor, Linux 6.18. Según las previsiones compartidas, 6.18 debería llegar entre finales de noviembre y principios de diciembre de 2025 como nueva serie LTS, mientras que el primer Release Candidate está previsto para el 12 de octubre. Para GNU Linux‑libre, esto implica preparar de antemano los parches de deblobbing, revisar cambios en controladores y adaptar la limpieza allí donde aparezcan nuevas dependencias de firmware no libre.

Quien busque un kernel libre sin concesiones encontrará en GNU Linux‑libre 6.17 una edición acorde a sus principios, con limpiezas puntillosas y sincronía con las mejoras del kernel principal. Si bien la compatibilidad de ciertos dispositivos puede resentirse por la ausencia de blobs, el conjunto ofrece una base sólida, actualizada y con vías claras de descarga e instalación tanto en forma de tarballs como de paquetes para las familias DEB y RPM. Para el kernel Linux estándar 6.17, las mejoras de rendimiento, seguridad y soporte de hardware también se dejan notar, y conviene vigilar el calendario hacia 6.18 si te interesa subirte pronto a la próxima LTS.

Yarr (Yet another rss reader) es un agregador de feeds en el navegador que se puede utilizar tanto como una aplicación de escritorio como en un servidor personal autoalojado

Sigo utilizando a diario un lector de feeds para seguir las novedades de las webs que me interesan. Desde hace tiempo utilizo Commafeed, en su instancia propia que me permite leer mis feeds desde cualquier parte.

Y por esos vericuetos (¿no es bonita esa palabra?) de internet me he encontrado con otro lector de rss llamado Yarr publicado bajo una licencia MIT. que puedes utilizar como aplicación local, o puedes también autohospedarla en tu servidor.

Yarr es una aplicación para seguir los feeds de tus sitios preferidos. Utiliza el navegador para mostrarte su interfaz limpia y clara y desde la cual leer los artículos que las webs que sigues publican. Veamos la interfaz más en detalle.

Yarr es multiplataforma y está disponible también para GNU/Linux. La aplicación se instala con un simple binario que utiliza una base de datos en SQLite para mantener los datos de toda la interfaz.

Para descargar vamos a su repositorio de GitHub y descargamos la opción que deseemos. En mi caso la disponible para Linux, que contiene en el nombre: yarr_linux_amd64.zip

Descargado el archivo .zip lo descomprimimos y tendremos un ejecutable llamado yarr. Movemos ese archivo a nuestro $PATH, por ejemplo: ~/.local/bin para que podamos ejecutarlo desde cualquier ubicación.

Si queremos también podremos ejecutar este script, para que nos cree un icono y muchas otras cosas. En mi caso no lo he hecho y me he saltado esta parte.

Ahora desde la terminal simplemente ejecutamos yarr y empezará a ejecutar la aplicación. Si queremos abrirla en nuestro navegador, deberemos acceder a nuestro equipo en el puerto 7070 que es el utilizado de manera predeterminada: http://127.0.0.1:7070

También podemos ejecutar yarr -open y eso abrirá la pestala del navegador con yarr directamente.

Desde el navegador en su interfaz ya podremos empezar a configurar los feeds que queremos leer, color de la interfaz (claro, sepia u oscuro), tiempo de refresco de los feeds y muchas otras cosas. La interfaz es sencilla y muy clara.

También podemos importar un archivo .opml de feeds que tengamos ya preparado con todos los feeds y carpetas que queremos para no tener que estar añadiendo a mano uno a uno todos los feeds que queremos.

La interfaz se va llenando con los feeds y podemos ir leyéndolos a golpe de ratón o con atajos de teclado que se inspiran en los movimientos de Vim: hjkl. Podremos destacar alguno con una estrella si nos interesa, marcarlos como leídos, etc.

Algo que no me gusta es que no muestra un número al lado de la carpeta de feeds de los artículos sin leer de cada fuente. Solo en la pestaña del navegador nos muestra los feeds totales sin leer.

Yarr en un servidor como servicio remoto

Pero no solo podemos utilizarlo como aplicación en nuestro propio equipo. Si lo instalamos en un servidor propio podremos hacer que podamos acceder a ese servicio desde cualquier parte de internet.

En mi caso lo he instalado en un viejo portátil ejecutando la aplicación de la siguiente manera: yarr -addr 192.168.1.42:7070 (192.168.1.42 sería la IP local del equipo donde lo ejecutamos, en tu caso tendrías que poner la IP local que utilice tu equipo) y con eso desde otro equipo dentro de mi red he podido acceder al Yarr ejecutándose en el portátil.

Y si utilizamos un servicio de DNS dinámica y en nuestro router redireccionamos el puerto, podremos acceder desde cualquier ubicación a Yarr.

También permite configurar nuestro certificado de seguridad y así en vez de acceder mediante http, lo hagamos de manera más segura mediante https.

Puedes echar un vistazo a más opciones mediante yarr -h

A la hora de escribir este artículo está en la versión 2.5 y recibe actualizaciones en su repositorio. Cuando haya una nueva versión deberás descargar el nuevo ejecutable y sustituir el actual con el nuevo y debería seguir funcionando, pero incluyendo las nuevas funcionalidades y correcciones.

¿Sigues utilizando feeds? ¿Te animas a probar este nuevo software? Puedes añadir como prueba mi blog: https://victorhckinthefreeworld.com/feed/

Enlaces de interés

• https://github.com/nkanaev/yarr