Valve sorprendió a propios y extraños al anunciar que SteamOS 3, el sistema operativo de la Steam Deck, se basaría en Arch Linux en lugar de Debian y que sería un sistema operativo inmutable. La compañía tenía motivos para el cambio de base, empezando con el fácil acceso a software reciente y además en un estado bastante vanilla.

Viendo la buena acogida que ha tenido la Steam Deck entre el público general, parece que a Valve le ha interesado profundizar su relación con la distribución madre de SteamOS 3, ya que Levente Polyak, actual líder de Arch Linux, ha anunciado una colaboración directa con la compañía. Viendo la trayectoria de la responsable de Steam en torno a Linux, un movimiento como este no debería sorprender.

Polyak ha explicado en el anuncio que “Valve está brindando su generoso apoyo para dos proyectos críticos que tendrán un gran impacto en nuestra distribución: una infraestructura de servicio de compilación y un enclave de firma seguro. Al respaldar el trabajo de manera independiente sobre estos temas, Valve nos permite trabajar en ellos sin estar limitados únicamente por el tiempo libre de nuestros voluntarios.”

“Esta oportunidad nos permite abordar algunos de los mayores desafíos pendientes que hemos estado enfrentando durante un tiempo. La colaboración acelerará el progreso que de otra manera nos llevaría mucho más tiempo lograr y, en última instancia, nos permitirá avanzar en algunos de los proyectos que teníamos planeados. Estamos increíblemente agradecidos a Valve por hacer esto posible y por su compromiso explícito de ayudar y apoyar a Arch Linux”.

Otro punto que ha destacado Polyak es que “estos proyectos seguirán nuestros flujos de trabajo habituales de desarrollo y de construcción de consensos”. Dicho de otra manera, que Arch Linux debería seguir funcionando igual que siempre, pero con los beneficios y aceleración que aportará la colaboración con Valve.

Si esta relación funciona de manera honesta, ambas partes se verían beneficiadas. Arch Linux podrá acelerar su desarrollo gracias a las aportaciones de Valve, mientras que esta última posiblemente obtenga unos paquetes con un mejor punto de partida para la creación de SteamOS. Según han recogido en GamingOnLinux, uno de los aspectos que podrían verse mejorados es la seguridad de los paquetes servidos a través de los repositorios.

Además de la colaboración con Arch Linux, Valve intenta en estos momentos acelerar el desarrollo de Wayland a través de dos vías: la inclusión de protocolos procedentes de proyectos de terceros y la introducción de una fase más en el desarrollo de protocolos para Wayland. Por ahora ambas vías siguen abiertas según sus respectivas peticiones de fusión y hasta podrían terminar siendo complementarias dependiendo de las decisiones que se terminen tomando.

Fuente: Muy Linux.

La cuota de Linux en PC se estabiliza por encima del 4%. En concreto, Linux cerró septiembre con un 4,48% de cuota de mercado, un 4,5 de facto según marca StatCounter, lo que se traduce en una constante digna de mención como es la que nos ocupa.

Esto no tiene nada que ver con vaivenes pasados más complicados de digerir. Son datos de StatCounter, que desde la desaparición de NetmarketShare (un medidor tradicionalmente más optimista para con Linux) ha quedado como referente para este tipo de métricas, aun cuando hay que tener en cuenta que no reflejan la realidad con rigor, porque no hay una manera certera de hacerlo.

Sea como fuere, son los datos de StatCounter los que generan los titulares y, por lo tanto, la asunción de cuotas de mercado que damos por ciertas, como que Windows domina el segmento del PC con más del 70% o que Chrome hace lo propio en el de los navegadores web con más del 65%. Son datos que tomamos por hecho, pese a no ser absolutos, porque no tenemos otros.

Ergo, desterremos de una vez del imaginario colectivo que Linux es el 1%, porque no lo es. Linux es el 4 y pico por ciento, tal y como ha venido demostrando poco a poco su crecimiento: entre la pasada década y esta se alcanzó el 2% y desde el último par de años el ascenso ha sido más rápido. Los hitos más destacados los tuvimos a principios del año pasado y el presente, cuando Linux superó el 3 y 4 por ciento de cuota de mercado respectivamente.

Lo positivo de la nueva marca es que está siendo consistente a lo largo de los meses: febrero 4,03%, marzo 4,05%, abril 3,88%, mayo 3,77%, junio 4,05%, julio 4,44%, agosto 4,55%… se han dado altos y bajos, pero manteniendo una constancia que, no lo olvidemos, tiene el el «sistema desconocido» que recogen las estadísticas de StatCounter con un porcentaje muy similar (lleva oscilando entre el 4 y el 6 desde hace más de un año) parte de lo que le correspondería, que no todo, ojo.

¿Y si a la cuota de Linux le sumáramos la de lo que también es Linux, como ChromeOS? Entonces hablaríamos del 6,75%. ¿Y si a eso le añadimos la cuota de Android, que a fin de cuentas también es Linux? Entonces… Estaríamos haciendo trampas. A nosotros mismos, usuarios y amantes del escritorio Linux que usamos por diferentes motivos. Resulta más interesante observar cómo varía la presencia de Linux en los mercados alrededor del mundo, por continentes, por países…

Por ejemplo, en África Linux tiene un 2,64%, en Asia un 6,39%, en Europa un 3,07%… En América del Norte un 3,93%, en América del Sur un 3,17% (no sé por qué separa al continente en dos partes)… Y ya por países, en España sigue anclado en el 3,16%, en México en el 2,37%, en Colombia en el 3,01%, en Argentina en el 3,2%… (por mencionar algunos de los países desde donde más nos leéis).

Ahora bien ¿queréis alucinar un poco? Porque hay países donde la cuota de Linux es muy superior a la media, mucho más de lo que cualquiera podría imaginar. Unos ejemplos de menos a más: en Finlandia llega al 4,95%, en Serbia al 5,02%, Yemen 5,21%, Laos 5,6%, Macao 5,65%, Seychelles 5,74%, Hong Kong 5,81%, Montenegro 6,27%, Venezuela 6,65%, Grecia 6,96%, Cuba 7,41%, Turquía 7,46%, Irak 7,89%, Singapur 8,37%, Panamá 9,57%, Sudán 11%, Groenlandia 11,72%, Noruega 17,03%, India 17,32%… Todo ello según datos de StatCounter, cabe repetir.

¿Seguirá fluctuando la cuota de mercado global de Linux? Es lo más probable, pero por lo que llevamos de 2023 y 2024, el crecimiento parece estable. Así que quedaos con el dato, para cuando se necesite: somos el 4%. Como mínimo.

Fuente: Muy Linux.

Si eres usuario de SUSE u openSUSE, ya la tienes en los repositorios y si no, la puedes descargar igualmente, si es que te interesa hacerte con una nueva fuente tipográfica de código abierto llamada… SUSE. La puedes usar en el sistema, en una página web… Donde quieras.

«Nos complace anunciar el lanzamiento del tipo de letra oficial SUSE, apropiadamente llamado “SUSE”. La familia de fuentes SUSE admite más de 200 idiomas de base latina», anunciaba Ivo Totev, Director de Innovación de SUSE, en el blog de la compañía. «Ahora lucimos más SUSE que nunca. La publicación de nuestra familia de fuentes oficial como código abierto es la opción obvia para SUSE, y eso es exactamente lo que hemos hecho».

SUSE es una tipografía sans serif diseñada por René Bieder, que incorpora un híbrido único entre características geométricas y monoespaciadas. Capta la esencia de SUSE, una empresa reconocida por sus soluciones de código abierto. Esta versátil familia de tipos de letra incluye los siguientes estilos: Thin, ExtraLight, Light, Regular, Medium, SemiBold, Bold y ExtraBold.

SUSE fue creada para reflejar el espíritu innovador y de código abierto de la empresa SUSE. Proporciona claridad y legibilidad, lo que lo hace ideal tanto para medios digitales como impresos. El diseño híbrido combina precisión geométrica con estabilidad monoespaciada, asegurando una estética moderna y eficiente.

SUSE se destaca por su diseño distintivo, perfecto para proyectos modernos, de código abierto y centrados en la tecnología. Su variedad de pesos permite flexibilidad en el diseño, desde titulares hasta el cuerpo del texto, lo que garantiza coherencia y armonía en diferentes casos de uso.

La tipografía de SUSE se publicó a finales de junio bajo la licencia SIL Open Font License 1.1, según se puede ver en GitHub , donde se dan todos los detalles técnicos acerca de la misma; aunque no ha sido hasta hace unos días cuando se hizo público el lanzamiento. Si te interesa probarla, además de en los repositorios de SUSE y openSUSE y en GitHub, está disponible en Google Fonts, para descargar o usarla en la web.

¿Será está la próxima fuente tipográfica predeterminada de SUSE y openSUSE? Todo parece indicar que sí, si bien de momento no ha sido implementada de tal forma. Sea como fuere, ahí tienes una opción más que se une a otras más conocidas y extendidas como Ubuntu (¡de Ubuntu¡) o Cantarell de GNOME.

Fuente: Muy Linux.

En los últimos tiempos han surgido iniciativas para hacer que los fallos de Linux sean más fáciles de leer. Si systemd 255 introdujo un pantallazo azul de la muerte cuyo uso es opcional, hace poco se ha propuesto para Linux 6.12 la muestra de un código QR cuando se produce un kernel panic.

Los códigos QR se han mostrado como muy eficaces para almacenar una gran cantidad de información en poco espacio, así que, procedente del repositorio DRM-Misc-Next, se ha propuesto su implementación en DRM Panic, que es el componente encargado de mostrar un mensaje cuando se produce un kernel panic a través de los drivers gráficos soportados.

Pero antes de continuar, hay que dejar claro que aquí DRM no hace referencia a la gestión de derechos digitales de plataformas como Netflix o SkyShowtime, sino a la gestión de renderización directa. Dicho con otras palabras, nos estamos refiriendo al subsistema del kernel Linux responsable de interactuar con las GPU modernas, el cual abarca los drivers AMDGPU, el viejo Radeon dirigido principalmente a viejas gráficas publicadas bajo la marca ATI, además de los drivers de Intel i915 y Xe, siendo el primero el actual y el segundo su sucesor para procesadores gráficos modernos. Obviamente hay muchos otros controladores, pero en el ecosistema x86 esos son los más populares y los que tienen mayor proyección.

La información arrojada por un kernel panic tiende a no ser muy amigable, así que un código QR puede ser una buena herramienta para almacenar más información y de manera que se pueda consultar en el futuro, con la posibilidad de obtenerla de forma que sea más comprensible para el usuario. La característica es opcional y está escrita en Rust, por lo que el soporte para dicho lenguaje debe estar habilitada en la compilación del kernel.

Profundizando un poco en la característica, tiene una opción llamada DRM_PANIC_SCREEN_QR_CODE que añade un generador de códigos QR y una pantalla de pánico con un código de QR. El código QR contendrá las últimas líneas de kmsg y otra información de depuración. Esto debería facilitar al usuario el reporte de un kernel panic con toda la información disponible. Otra opción, DRM_PANIC_SCREEN_QR_CODE_URL, establece la URL base para reportar un kernel panic y en caso de estar establecido en propio código QR contendrá la URL y el kmsg comprimidos con zlib como un parámetro de la URL. En caso de estar vacío, el código QR solo contendrá solamente el kmsg como texto sin comprimir.

Por ahora la intención es introducir el soporte para el código QR en Linux 6.12, pero todavía queda bastante para su lanzamiento (la versión 6.11 se encuentra en RC) y es posible que se demore. No se trata de una característica que vaya a revolucionar nada y muchos posiblemente la vean inútil, pero es probable que algunos usuarios vean aquí una vía para obtener una mejor información de una de las incidencias más desagradables que uno puede tener a la hora de usar Linux.

Fuente: Muy Linux.

A pesar de haber moderado su actitud, Linus Torvalds sigue sorprendiendo con sus declaraciones y reflexiones, que en no pocas ocasiones se desmarcan de los tópicos que muchos atribuyen a una persona de su perfil. Siguiendo esta tónica, el creador de Linux ha expuesto en la conferencia Open Source Summit China 2024 su punto de vista sobre la adopción de Rust en el kernel, su postura en torno a la inteligencia artificial y cómo se toma ciertas tecnologías.

Sobre la situación de Rust en Linux, parece que ha habido cierto cambio en la visión de Linus Torvalds. Si en el pasado sus declaraciones denotaban cierto escepticismo sobre cómo terminaría funcionando Rust a la hora de la verdad, en la última Open Source Summit celebrada en China ha dicho que “esperaba que las actualizaciones fueran más rápidas, pero parte del problema es que los antiguos desarrolladores del kernel están acostumbrados a C y no conocen Rust. No les entusiasma precisamente tener que aprender un lenguaje nuevo que en algunos aspectos es muy diferente. Así que ha habido cierta reacción contra Rust”.

El desconocimiento por parte de los desarrolladores y su resistencia a adoptar una tecnología más reciente no es el único motivo según ha explicado Torvalds, ya que “otra razón ha sido que la infraestructura de Rust en sí no ha sido súper estable”.

Continuando con tecnologías que están de moda, Linus Torvalds también ha expresado su postura en torno a la inteligencia artificial (IA). Si bien no comparte el exceso de entusiasmo que ha despertado, sí ve que las herramientas apoyadas en inteligencia artificial contribuirán a la revisión de código y a la detección de errores.

Otra cosa que el creador de Linux ha mencionado sobre la IA es que hecho que NVIDIA se involucre mucho más en kernel, hasta el extremo de decir que el gigante verde ha pasado “de estar en mi lista de empresas que no son buenas a mi lista de empresas que están haciendo un trabajo realmente bueno”. Aquí nos encontramos con una aparente rectificación de su icónico fuck you, que vino después de decir que NVIDIA era “la peor empresa con la que habían tratado” los responsables del kernel y que era “foco de contínuos problemas para Linux”.

Y por último nos encontramos con sectores como la computación en la nube y tecnologías como Kubernetes, que al parecer no son del interés de Torvalds, quien prefiere estar centrado en el kernel Linux. Obviamente, el ingeniero finés no niega la importancia de la nube y tecnologías como Kubernetes, pero que a la hora de la verdad no son su problema. Por otro lado, ha comentado que lo bueno del código abierto es que cada uno se especializa en lo que le interesa.

Lo que dice Linus Torvalds en los eventos suele ser tenido en cuenta no solo por el debate que puedan generar sus palabras, sino también porque a veces da pistas sobre posibles decisiones en torno al desarrollo de Linux. El ingeniero finés estuvo acompañado en la conferencia por Dirk Hohndel, quien es director de la oficina del programa de código abierto de Verizon y amigo del creador de Linux.

Fuente: Muy Linux.

El Equipo del Kernel de Canonical, CKT en sus siglas en inglés, ha anunciado una nueva política de selección de versiones de Linux con la que pretenden suministrar los lanzamientos más recientes del kernel a través de Ubuntu.

Lo primero que explica el CKT es que los encargados del kernel manejan una fecha de publicación fluida con el fin de ajustarla a los problemas que pudieran surgir en el desarrollo, si bien el actual calendario hace que tengamos una nueva versión de Linux cada dos o tres meses. Por su parte, Ubuntu maneja como distribución un calendario fijo, con un lanzamiento cada seis meses que solo se retrasa en circunstancias extremas.

Debido a que los lanzamientos del Linux y de Ubuntu no están alineados, se puede dar el caso de que una versión del kernel sea publicada en unas fechas similares al de un nuevo lanzamiento de la distribución o que la versión de Linux sea publicada después del lanzamiento de Ubuntu debido a que fue retrasada. Por otro lado está la política del propio CKT, que ha estimado en un mes el tiempo requerido entre la nueva versión de Linux y el kernel asociado a Ubuntu para que sea considerado lo suficientemente estable para su publicación en los repositorios.

Lo planteado por el CKT puede ser un problema cuando una nueva versión de Linux es lanzada solo cuatro semanas antes de una nueva publicación de Ubuntu o una semanas después de la fecha programada para el sistema operativo. Para ilustrar la situación con un ejemplo, el equipo ha publicado un gráfico en el que se ve que el lanzamiento de Ubuntu 24.10 casi coincide con el de Linux 6.11.

El CKT reconoce que la situación que se le plantea es un dilema, ya que, con su esquema actual, debería incluir en Ubuntu 24.10 un kernel que ya tiene entre dos y tres meses en lugar del último, cuyo lanzamiento en caso de cumplirse la fecha se produciría poco antes de la publicación del sistema. Esto plantea si es mejor incluir un kernel que tiene dos o tres meses o si acortar el proceso de clarificación para llegar a la fecha de lanzamiento, con la posibilidad de que la segunda opción derive en un producto que proporciona menos confianza, o si ajustar la fecha de lanzamiento de Ubuntu.

Sobre la política en torno a la introducción de un kernel reciente en Ubuntu, el CKT ha explicado lo siguiente: “La forma en que CKT ha elegido históricamente una versión upstream del kernel de Linux fue con un enfoque conservador de ‘esperar y ver’. Dada la ventana de estabilización de un mes requerida, una versión upstream del kernel que se lanzará casi con seguridad sería la selección tentativa, con un posible salto de último minuto a una versión más reciente en caso de que se lance en un plazo viable. Este enfoque garantizaría la estabilidad en el día de lanzamiento designado, pero estaba resultando impopular entre los consumidores que buscaban adoptar las últimas características y soporte de hardware, así como entre los proveedores de silicio que buscaban un compromiso de versión más firme para alinear su soporte de Ubuntu.”

“La intención detrás de esta publicación es describir una nueva política que el CKT está adoptando con respecto a la selección de la versión del kernel para una próxima versión de Ubuntu. Para brindar a los usuarios lo último en características y soporte de hardware, Ubuntu ahora suministrará la última versión disponible del kernel de Linux upstream en la fecha de congelación de lanzamiento especificada de Ubuntu, incluso si el upstream aún se encuentra en estado de Lanzamiento Candidato (RC)”.

De entre los términos recurrentes mencionados por el CKT, está el lanzamiento apretado (Tight Release), que consiste en “cuando un kernel upstream está en las candidatas de lanzamiento de la 4 a la 6 dentro de la congelación de características (Feature Freeze). La suposición aquí es que el kernel upstream está lo suficientemente avanzado como para que el equipo del kernel tenga gran confianza en que se lanzará antes de la beta congelada de Ubuntu. Sin embargo, la versión upstream del kernel estará tan cerca de la versión de Ubuntu que necesitará un período limitado para realizar pruebas, solucionar problemas e integrar componentes dependientes”.

Otro término a destacar es el lanzamiento inestable: “Cuando un kernel upstream todavía está en la ventana de fusión abierta o en candidata de lanzamiento de la 1 a la 3 dentro la congelación de características, esto se conocerá como versión inestable. En esta situación, el CKT confía en que el kernel upstream todavía estará en un estado RC en la beta congelada de Ubuntu, donde la versión del kernel está congelada y, por lo tanto, no se puede esperar una estabilidad completa o incluso soporte completo de componentes dependientes”.

Obviamente, la situación no solo consiste en meter la última versión del kernel o confiar en una candidata de lanzamiento que está en una fase avanzada, ya que hay componentes como el driver de NVIDIA y el soporte de ZFS que tienen que ser tenidos en cuenta. Esto introduce bastante complejidad en lo que respecta a tomar la decisión de introducir un kernel más reciente en Ubuntu con el fin de ofrecer un mejor soporte para aquellos que usan un hardware reciente.

En lo que respecta a los lanzamientos LTS de Ubuntu, Livepatch seguirá funcionando como de costumbre para los kernels liberados; no existirá ningún kernel puente, una opción para los usuarios que desean actualizar a la versión pendiente pero que requieren de componentes dependientes que aún no están estabilizados, por lo que todas las actualizaciones estarán deshabilitadas hasta la estabilización; además de que se proporcionará un kernel estabilizado para la primera versión de mantenimiento. Dicho con otras palabras, parece que la política será algo más conservadora con los lanzamiento LTS de Ubuntu, cosa normal si tenemos en cuenta el perfil del producto.

El CKT reconoce que con esta nueva política puede ser más agresivo a la hora de proporcionar una nueva versión del kernel. Sin embargo, avisa que por ahora solo puede anunciar lo que hará en la próxima versión de Ubuntu, o sea, la 24.10, que por ahora apunta a incorporar Linux 6.11. De cumplirse los plazos mostrados en los gráficos, el kernel ya debería estar en fase estable para el día de lanzamiento del sistema operativo.

Fuente: Muy Linux.

Podman 5.2 ya está disponible como la nueva versión del motor de contenedores de código abierto, multiplataforma y que funciona sin daemon. En esta ocasión nos encontramos con un lanzamiento que no incluye un número significativo de novedades, de las cuales la primera mencionada no va dirigida a Linux.

Comenzando con lo que ya hemos adelantado, Podman soporta a partir de este lanzamiento libkrun como backend para crear máquinas virtuales en macOS. La principal ventaja de usar libkrun como backend es que permite montar las GPU en la máquina virtual para acelerar las tareas, si bien por defecto todavía se sigue usando applehv.

La segunda novedad más importante de Podman 5.2 es que Quadlet soporta ahora los ficheros .build, lo que permite que las imágenes puedan ser creadas por Quadlet y que luego sean utilizadas como contenedores de Quadlet. Para los que anden perdidos, Quadlet es una herramienta para ejecutar contenedores de Podman en systemd de forma óptima al permitir que los contenedores se ejecuten en systemd de forma declarativa.

El contenedor (.container) de Quadlet y los ficheros .pod soportan un nuevo campo, NetworkAlias, con el que es posible añadir alias de red. Por otro lado, las rutas de búsqueda directa de Quadlet han sido ampliadas para incluir entradas directas de nivel superior (container.d, pod.d) y entradas directas de unidades truncadas (unit-.container.d).

En lo que respecta a los comandos, se ha introducido un nuevo, podman system check, que se encargará de identificar y a ser posible corregir corrupciones dentro del almacenamiento local de contenedores, mientras podman machine reset restablecerá todos los proveedores disponibles en el sistema operativo actual (por ejemplo, garantizando que las máquinas virtuales de la máquina podman HyperV y WSL se eliminarán en Windows).

Podman 5.2 también ha introducido un puñado de cambios de calado, de entre los que destaca que a partir de este lanzamiento se requiere una nueva API de montaje del kernel que ha sido introducida en Linux 5.2, que las unidades de imágenes (.image) de Quadlet tienen ahora una dependencia sobre network-online.target y que la opción --device de podman create y podman run ya no es ignorada cuando la opción --privileged también es especificada.

Continuando con más cambios, tenemos el uso de virtiofs en lugar de 9p sobre Linux si virtiofsd está instalado en el sistema anfitrión y se quiere montar el sistema de ficheros del anfitrión en las máquinas virtuales creadas con podman machine, la posibilidad de usar las opciones --squash y --layers=false al mismo tiempo en podman build, la capacidad de Podman de pasar un tiempo de espera para la detención del contenedor a systemd cuando se crean cgroups, el marcado de la opción --volume-driver como obsoleta en podman machine init, además de que los comandos podman start y podman stop ya no imprimen el ID completo del pod iniciado o detenido, sino la entrada del usuario utilizada para especificar el pod.

Y estas son las novedades más importantes de Podman 5.2. Los que quieran conocer todos los detalles pueden consultar el anuncio oficial y el registro de cambios, mientras que para obtener el motor de contenedores uno puede consultar las instrucciones al respecto o esperar a que sea suministrado a través de los repositorios de la distribución Linux utilizada si esta es rolling release o una bleeding edge relativamente “agresiva”, y eso sin contar la posibilidad de que existan repositorios externos.

KI

Manjaro ha anunciado la puesta a disposición en fase experimental de su futuro sistema operativo inmutable (o atómico, según se vea), el cual se convertirá en otra edición oficial de la distribución. Aquí nos encontramos con otra propuesta que sigue más o menos las líneas ya marcadas por Fedora Silverblue, openSUSE Aeon y Vanilla OS, con mecanismos de actualizaciones atómicas, de retroceso (rollback) para volver a una versión anterior del sistema y de separación de las aplicaciones del sistema mediante Podman, Distrobox y Flatpak.

Como nos volvemos a topar con conceptos que hemos repetido en diversas ocasiones, vamos a centrarnos Arkdep, el mecanismo de actualizaciones atómicas empleado por el sistema inmutable de Manjaro, cuyo nombre al menos por ahora es Manjaro Immutable. Su origen está en Arkane Linux, una derivada inmutable de Arch Linux, y según su descripción en GitHub se trata de un “conjunto de herramientas para construir, implementar y mantener un sistema atómico e inmutable basado en Btrfs. Es el conjunto de herramientas que proporciona inmutabilidad a Arkane Linux. Intenta diferenciarse de otras herramientas similares por ser ‘estúpidamente simple’, modificable, flexible y fácil de adoptar para proyectos personales”.

Arkdep pone en evidencia el sistema de ficheros empleado Manjaro Immutable, Btrfs, el cual es un clásico en los sistemas inmutables gracias a que soporta instantáneas de manera nativa. Debido a que Arkdep se apoya en Btrfs, no se permite usar otro sistema de ficheros, algo que también ocurre con los sistemas inmutables del espectro SUSE por el hecho de apoyarse en transactional-update y Snapper para el mecanismo de retroceso mediante instantáneas de Btrfs.

Arkdep parece tener alguna que otra similitud con OSTree, ya que con un solo comando y un reinicio es posible cambiar la rama de GNOME por la de KDE:

sudo arkdep deploy test-manjaro-kde

Otro aspecto a destacar de Manjaro Immutable es que su experiencia está centrada en GNOME al menos de momento, con un sistema que está bastante limpio a nivel de aplicaciones. El usuario se encontrará con que no hay ningún navegador web preinstalado y verá solo algunas aplicaciones básicas del escritorio y BoxBuddy, una aplicación gráfica que facilita la creación de contenedores de Distrobox.

Un punto a tener en cuenta de Manjaro Immutable es que emplea systemd-boot como gestor de arranque, por lo que requiere de un ordenador o una máquina virtual que soporte UEFI para funcionar. No, este sistema operativo no funciona sobre legacy BIOS, por si a alguien se le ocurre probarlo en un ordenador muy antiguo o una máquina virtual sin configurar correctamente tipo de firmware. Si se quiere establecer otra imagen del sistema para que sea iniciada por defecto, hay que empezar por ejecutar el siguiente comando:

cat /arkdep/tracker

Que debería arrojar un resultado como el siguiente:

8da5433c34d8633d686c0c6cdc8b0d7d0c77d0d5f7 # Primera imagen
1b07985e7fd28c5722f73ed6937b0c6afedfba33d6 # Segunda imagen

Para establecer la segunda imagen como la predeterminada:

sudo bootctl set-default 1b07985e7fd28c5722f73ed6937b0c6afedfba33d6

Y si se quiere eliminar una imagen del sistema, el proceso es el siguiente:

sudo arkdep remove 8da5433c34d8633d686c0c6cdc8b0d7d0c77d0d5f7

Además de un equipo que use UEFI, el requisito mínimo a nivel de almacenamiento para datos es de 32GB, si bien lo recomendado son 64GB. Recordamos que estos sistemas operativos inmutables no están especialmente orientados al ahorro de espacio en disco debido a la presencia del mecanismo de retroceso, de Distrobox y Flatpak, pero cualquier equipo de gama media de hace años tiene capacidad más que sobra para soportarlos sin problemas.

En resumidas cuentas, Manjaro se suma a la moda de los sistemas inmutables con una propuesta que sigue en buena medida lo realizado por otros con anterioridad. Los que quieran conocer todos los detalles sobre este sistema, que todavía se encuentra en fase experimental, pueden consultarlos en el anuncio oficial, desde donde también es posible obtener la imagen ISO para llevar a cabo el proceso de instalación.

La cuota de Linux en el escritorio no para de dar buenas noticias en los últimos tiempos, o al menos eso es lo que nos llega a partir de los datos recopilados por Statcounter, que se ha convertido en la firma de estadística de referencia tras el cierre de NetMarketShare.

Linux había superado el 4% de cuota en escritorio el pasado mes de febrero, una situación que se mantuvo un mes más hasta que en el siguiente la cosa se desinfló un poco, aunque manteniéndose claramente por encima del 3%. En junio la cuota se situó en el 4,05% y el pasado mes de julio volvió a subir para alcanzar el 4,45%, lo cual supone su máximo en la historia de Statcounter o al menos su máximo en muchos años.

No viene mal recordar que los datos de estos medidores tienen que ser cogidos con pinzas, ya que es muy probable que manejen unos márgenes de error bastante grandes. Sin embargo, en la actualidad es lo menos malo que hay, así que es lo que se suele usar para tener una imagen aproximada de la situación de algún segmento, ya sean los sistemas para escritorio, los sistemas para móviles, los navegadores web, los motores de búsqueda, etc.

Sobre las cuotas de los distintos sistemas para escritorio en julio de 2024, los datos de Stacounter son los siguientes:

• Windows: 72,08%
• macOS: 14,92%
• Desconocido: 7,14%
• Linux: 4,45%
• ChromeOS: 1,41%
• FreeBSD: 0,01%

Como suele ser habitual por parte de Statcounter, nos encontramos con el misterio que representa ese “Desconocido”, que en un principio apunta a ser principalmente sistemas no identificados que operan detrás de una VPN. Algunos posiblemente piensen que un porcentaje de esos sistemas sean Linux que no han sido correctamente identificados, pero la teoría de las VPN apunta a tener fuerza si vemos la alta cuota de Linux en términos relativos.

Si vemos la cuota de Linux por continentes, en Asia es del 6,16%, en África del 2,77%, en Europa del 3,42%, en Norteamérica del 3,52%, en Oceanía del 1,82% y en Sudamérica del 3,02% (nos estamos ciñendo a los datos de Statcounter, por si alguien ve que algo no tiene sentido). Por (algunos) países tenemos el 3,47% de España, el 3,74% de Estados Unidos, el 3,13% de Brasil, el 2,54% de México, el 3,37% de Argentina, el 3,15% de Colombia, el 1,3% de Chile, el 3,12% de Ecuador, el 6,77% de Venezuela, el 2,61% de Bolivia y el 2,04% de Perú.

Retomando la cuota a nivel mundial, es obvio que el 4,45% es poco, pero como persona que vivió la época en la que a Linux le costaba horrores mantener el 1%, prefiero ver el vaso medio lleno, sobre todo tras observar la tendencia al alza de los últimos años. Sobre las razones se pueden exponer muchas teorías, pero algunas de ellas pueden ser el descontento que muchos usuarios sienten con las versiones 10 y 11 de Windows, una Steam Deck que ha podido contribuir a que más de uno haya perdido el miedo a usar Linux, unos ordenadores Mac con Intel que se están quedando sin soporte y la mejora de los controladores gráficos. Como digo, todas estas son teorías, pero al menos no suenan muy disparatadas.

Veremos si el escritorio Linux sigue ganando cuota poco a poco para que así más compañías y aplicaciones se lo tomen en serio, con especial mención a Adobe, AutoCAD y algunos servicios como SkyShowtime, que en caso de poder usarse debe ser a través de algún resorte.