Debian replantea su política en torno al firmware privativo

publicado en: Debian, Linux | 0

 

 

Steve McIntyre, desarrollador de Debian, ha propuesto a través de su blog personal un cambio en la política que el proyecto aplica en torno al firmware privativo, cuya distribución ha quedado relegada al conocido repositorio non-free y a las imágenes no oficiales que se pueden encontrar en el dominio de Debian.

En tiempos pasados los requerimientos a nivel de firmware no eran altos en equipos de servidor y sobremesa (no tanto en portátiles), así que resultaba viable para un uso real apartar el privativo y distribuirlo aparte. Sin embargo, en los últimos años el uso de firmware privativo o que se distribuye solo en formato binario resulta necesario para aplicar, por cuestiones de seguridad, las actualizaciones de los microcódigos de los procesadores, además de que algunos de ellos son ficheros de inicialización necesarios para que las gráficas puedan dar todo su poder (o tan siquiera funcionar en algunos casos).

Aquí se puede destacar la situación de las gráficas AMD Radeon. Si bien tanto Radeon (el viejo driver semioficial) como AMDGPU (el “nuevo” driver plenamente oficial) son Open Source y están incluidos en el kernel, para liberar todo su poder requieren de un firmware privativo. Esto hace que usuarios de Debian vean que el sistema les devuelve en muchos casos una pantalla en negro tras instalarlo e intentar hacerlo funcionar sobre una gráfica de AMD.

Solucionar el tema de las gráficas AMD Radeon en Debian es tan simple como recurrir a una imagen non-free, pero a día de hoy muchas personas siguen ignorando este detalle. Y sí, lo que pasa con Debian se puede extender a toda distribución Linux-libre.

En resumidas cuentas, que los requerimientos cada vez mayores en torno al firmware están empezando a poner a Debian en una situación difícil, así que Steve McIntyre ha decidido poner la cuestión sobre la mesa y ver si dentro de la distribución se decide seguir haciendo las cosas como hasta ahora o aplicar ciertos cambios. Las opciones planteadas por el desarrollador son las siguientes:

  1. Mantener la configuración existente, que desde el punto de vista de McIntyre es horrible, pero que igualmente es lo mejor que pueden hacer desde Debian.
  2. Dejar de proporcionar las imágenes non-free, lo que dificultaría a los usuarios la instalación del sistema. Aunque el resultado sería un sistema más puro en términos de software libre, para McIntyre tampoco es que ayude a promover la causa en términos prácticos.
  3. Dejar de fingir que las imágenes non-free no son oficiales y posiblemente colocarlas junto a las normales. En consecuencia, dichas imágenes serían más fáciles de encontrar para los usuarios, pero otros podrían preguntarse qué sentido tiene mantener las imágenes sin el firmware privativo si en esencia son iguales a las otras.
  4. El equipo responsable podría simplemente incluir el soporte non-free en las imágenes oficiales y agregar paquetes de firmware a las listas de entrada de esas imágenes, pero eso dejaría al proyecto con el problema planteado en el punto anterior.
  5. Dividir los paquetes con firmware privativo en un nuevo componente de firmware non-free en el archivo y permitir una excepción específica solo para su inclusión en los medios oficiales, haciendo que solo se generen un conjunto de medios oficiales que podrían a disposición los paquetes de firmware no libre.

McIntyre deja claro que estas son sus propuestas para abordar el tema debido a que las ve como las opciones más probables, pero que no está cerrado a otras sugerencias procedentes de otras personas. Eso sí, no se corta al exponer su preferencia por la quinta opción, la cual, desde su punto de vista, ofrece un punto de equilibrio entre el compromiso de Debian con el software libre y el ofrecer unos medios de instalación que sean prácticos para los usuarios.

Viendo las fechas en las que estamos, es probable que, en caso de aprobarse, la nueva política en torno al firmware privativo sea aplicada para el lanzamiento como estable de Debian 12.

Fuente: Muy Linux

Des-habilitar bluetooth al inicio del sistema por default

publicado en: Debian, Software Libre | 0

Esto se probo en Debian GNU/Linux bookworm/sid (testing) probablemente también funcione en la mayoría de sus distribuciones derivadas.
Para los usuarios que no les gusta dejar cosas encendidas cuando no la usas por varios motivos, ecológicos o mantener el espectro saludable, etc.
En este caso, no uso con mucha frecuencia el bluetooth, por lo cual me gusta que este apagado y encenderlo cuando lo necesito. Pero por defecto se iniciaba automáticamente, incluso a veces trayendo alguna complicación al conectarse automáticamente a algún dispositivo no deseado. por lo cual dejo aquí lo que encontré como la forma mas limpia y optima para que el mismo inicie des habilitado por defecto.

Editar /etc/bluetooth/main.conf y buscar la linea

AutoEnable=true

Reemplazar con:

AutoEnable=false

Reiniciar y listo.

Si esto no funciona, la alternativa manual puede ser esta:

sudo systemctl disable bluetooth

y cuando queremos activar:

sudo systemctl enable bluetooth

Y la otra es con rfkill, y ponerlo en un script de arranque. Cuando encuentre una manera mas amigable, publicaremos otra entrada.

Saludos.

Endless OS 4 da el salto a Debian 11, refuerza Flatpak y mejora la privacidad

publicado en: Debian, Internet, Linux, Software Libre, Terminal | 0

Endless OS 4 ha sido publicado para continuar con la misión que tiene la fundación que lo desarrolla de reducir la brecha digital en el mundo. En esta ocasión nos encontramos con otro sistema operativo basado en excelente Debian 11 Bullseye, que incorpora más aplicaciones en formato Flatpak y que mantiene el sistema de actualizaciones atómicas OSTree como uno de sus principales puntales.

Como derivado de Debian 11 Bullseye que es, Endless OS 4 hereda muchas de las características del sistema operativo en el que se basada, pero la primera novedad destacada por los responsables de la distribución es la posibilidad de poder cambiar rápidamente entre usuarios sin cerrar sesión.

La segunda novedad mencionada por la fundación es el soporte de impresión sin drivers gracias a IPP-over-USB, que trata todo dispositivo conectado por USB (en este caso, impresoras) como si estuviera funcionando a través de red, haciendo de esta manera prescindible, al menos en un principio, el uso de drivers. Endless avisa que la actualización a la versión 4 de su sistema eliminará todas las impresoras que el usuario haya configurado.

Como kernel, Endless OS 4 trae Linux 5.11 con el paquete ‘linux-firmware’ actualizado para así soportar un mayor rango de hardware. Continuando con el soporte para las partes tangibles del ordenador, también está presente la versión 460.91.03 del driver oficial de NVIDIA.

Otras novedades del sistema que nos ocupa son el soporte para las VPN L2TP y OpenConnect/AnyConnect, la incorporación de OSTree 2020.8 y Flatpak 1.10.2, el cambio de ‘fake-hwclock’ y ‘ntpd’ por ‘systemd-timesyncd’ para el reloj monótono y la sincronización de tiempo, el soporte para la Raspberry Pi 4B con 8GB RAM, además de unos componentes del cargador de arranque actualizados.

Como entorno de escritorio está el maduro GNOME 3.38, al cual se le ha revertido los iconos para emplear Adwaita por defecto. Esta decisión se ha tomado con el propósito de soportar resoluciones más altas y ofrecer una mayor consistencia a través de la interfaz. Por otro lado, Rhythmbox y Cheese son suministrados ahora en formato Flatpak y se han separado los repositorios del sistema operativo y de las aplicaciones Flatpak.

Con el fin de mejorar la confidencialidad de las métricas, en Endless OS 4 se han incorporado algunos cambios para hacer que los puntos de datos no estén “asociados con la computadora en particular que los envió. En su lugar, están asociados con el canal de distribución de esa computadora, identificado por el ID de compilación de la imagen de instalación, que generalmente se comparte entre miles de sistemas. Endless OS 4 tampoco envía muchos puntos de datos que fueron enviados por versiones anteriores de Endless OS”. A pesar de todo, las métricas siempre pueden ser inhabilitadas en Configuración > Privacidad > Métricas.

Para terminar, nos encontramos con las partes que han sido eliminadas, las cuales son el visualizador de escritorio remoto integrado, las cuentas compartidas, los atajos integrados para los sitios web y la descarga automática de Google Chrome. Dependiendo del hardware que se use, puede ser conveniente la reinstalación completa del sistema operativo en lugar de actualizar desde una versión anterior.

Endless OS 4 puede ser descargado de forma gratuita desde la correspondiente sección en el sitio web oficial del proyecto. Los detalles completos de este lanzamiento están disponibles a través de las notas de lanzamiento.

Fuente: MuyLinux

Cómo instalar correctamente la versión Flatpak de Steam

publicado en: Debian, Linux | 0

 

 

Los resultados de la encuesta de Steam correspondiente a octubre de 2021 han arrojado un dato curioso, y es la presencia de la versión Flatpak del cliente como una de las distribuciones más utilizadas. Viendo que el formato de paquetes impulsado por Red Hat está ganando poco a poco más adeptos, vamos a enseñar a preparar Steam Flatpak para distintas distribuciones.

A pesar de que Flatpak va limando poco a poco sus carencias a nivel de integración, el cliente de Steam en ese formato arrastra dos inconvenientes a tener en cuenta:

  • Primero, no suministra las reglas de udev para controladores, así que el usuario puede encontrarse que su controlador, ya sea el difunto Steam Controller, uno de PlayStation, uno de Xbox o el Pro Controller de Switch, no se integra con la aplicación.
  • Segundo, si no se usa Flatpak 1.12, el usuario puede encontrarse un bug que hace que las versiones de Proton suministradas por el cliente no funcionen, lo que fuerza al usuario a tener que recurrir a las compilaciones comunitarias de Proton publicadas en formato Flatpak. Se cumpla o no con el requisito de Flatpak 1.12 para no arrastrar el bug, es preferible tener Proton Glorious Eggroll en formato Flaptak.

La ventaja de usar la versión Flatpak de Steam

Usar Steam en formato Flatpak tiene sus inconvenientes, pero también una ventaja importante, y es que dicha compilación de la aplicación usa una versión reciente de Mesa en el mismo formato para la ejecución de los videojuegos.

La versión Flatpak de Mesa no sustituye a la que está presente en el sistema en formato “tradicional” (Deb, RPM, tar.xz de Arch Linux… ), sino que la complementa y entra en acción solo cuando una aplicación Flatpak la requiere. Esto quiere decir que la integridad y la funcionalidad del sistema no quedan comprometidas al mantenerse las versiones de las bibliotecas suministradas oficialmente por y para la distribución.

La forma de funcionar de Mesa en formato Flatpak hace su uso atractivo en sistemas que suministran un conjunto de software estanco debido a que anteponen la estabilidad a todo, como Debian Stable y openSUSE Leap.

Instalando la integración de los controladores para Steam

El cliente de Steam en formato Flatpak no ofrece integración para los controladores, o dicho de manera más técnica, no suministra las reglas de udev necesarias para integrar un controlador de PlayStation, Xbox, el Pro Controller de Switch o el Steam Controller en la aplicación. La razón es porque la aplicación “no tiene permisos para instalar reglas de udev en las ubicaciones apropiadas y las reglas de udev enviadas por Steam también pueden ser insuficientes sin las personalizaciones de distribución”.

La integración de los controladores con Steam tiene que ser instalada de forma “tradicional”, a través de un paquete RPM o Deb. Por suerte, el nombre de dicho paquete es ‘steam-devices’ y está estandarizado, así que encontrarlo suele ser sencillo y está disponible, directa o indirectamente, para la mayoría de las distribuciones populares (en caso de no estar disponible, significa que las reglas de udev son suministradas por el cliente de Steam en formato “tradicional”).

Debian

Para instalar ‘steam-devices’ en Debian hay que ejecutar el siguiente comando después de habilitar los repositorios non-free:

Ubuntu

En Ubuntu puede que las reglas no estén puestas al día, aparte que tienen como dependencia la propia aplicación de Steam con toda su parafernalia. Para instalar solo las reglas de udev hay que añadir una opción al comando.

Fedora

En Fedora depende de si está usando la edición Workstation (o cualquier spin “tradicional” para el escritorio) o la Silverblue (que abarca Kinoite). Debido a que esta distribución suministra de por sí una versión muy reciente de Mesa sin necesidad de recurrir a repositorios de terceros, el uso del paquete Flatpak de Steam solo se justifica en las ediciones Silverblue y Kinoite, las cuales son sistemas inmutables que invitan al usuario a tragarse la mayoría de las modificaciones a través de paquetes Flatpak.

Otro detalle a tener en cuenta es que RPM Fusion, el archiconocido repositorio de terceros para Fedora, ha separado no hace mucho las reglas de udev de la versión RPM de la aplicación a propuesta de este servidor. Mi intención era aportar un granito de arena que ayudara a los usuarios interesados en usar Fedora Silverblue/Kinoite como un escritorio común.

Para instalar las reglas de udev para controladores de Steam, en primer lugar hay que habilitar el repositorio de terceros que permite instalar la aplicación (que es una activación parcial de RPM Fusion) o configurar el conjunto entero de RPM Fusion.

La configuración de RPM Fusion en Fedora Workstation y los spins “tradicionales” orientados al escritorio se realizar de la siguiente manera:

sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

El comando para la instalación de ‘steam-devices’ en Fedora Workstation es el siguiente:

sudo dnf install steam-devices

Mientras que en Silverblue/Kinoite hay que recurrir a rpm-ostree. En primer lugar hay que configurar los repositorios de RPM Fusion y reiniciar el sistema:

sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Luego se instalan las reglas y se vuelve a reiniciar para aplicar los cambios introducidos en la imagen del sistema (en otra ocasión nos extenderemos con Silverblue/Kinoite):

sudo rpm-ostree install steam-devices

openSUSE

Por último tenemos a openSUSE Leap, otro sistema para el que usar Steam Flatpak es algo atractivo. Sin embargo, y al igual que Ubuntu, al seleccionar el paquete ‘steam-devices’ se instala el cliente de Steam junto a todas sus dependencias, así que el usuario termina con dos versiones de la aplicación instaladas.

sudo zypper install steam-devices

Instalar el cliente de Steam en formato Flatpak

En caso de contar con una versión de GNOME Software o Discover bien implementada, el usuario solo tiene que descargar el instalador desde Flathub y luego abrirlo con la tienda de software que esté empleando. Para ello el usuario tiene que asegurarse de tener instalado el soporte de Flathub y la correspondiente integración para la tienda, que para Discover es ‘plasma-discover-backend-flatpak’ y para GNOME Software es ‘gnome-software-plugin-flatpak’ (al menos en Debian). En Fedora con GNOME este soporte viene preinstalado.

De manera alternativa se puede recurrir a la línea de comandos, configurando primero el repositorio de Flathub y luego instalando la aplicación.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub com.valvesoftware.Steam

Instalar Proton en formato Flatpak

Si se quiere jugar a juegos de Windows desde Linux es altamente recomendable usar Proton, la reimplementación de Wine desarrollada por Valve para facilitar la ejecución de videojuegos compilados para el sistema de Microsoft.

Sin embargo, salvo que se use Flatpak 1.12, los lanzamientos recientes de las compilaciones de Proton suministradas por Valve no funcionan con la versión Flatpak de Steam, así que habrá que recurrir a las compilaciones comunitarias de Proton en formato Flatpak que hay disponibles. Eso sí, Proton Glorious Eggroll (Proton-GE), que es más competente para la ejecución de títulos AAA recientes, sería preferible en este caso tenerlo en formato Flatpak.

Si se ha instalado el repositorio de Flathub y la integración con Discover funciona, el usuario solo tiene que buscar Proton en la mencionada tienda e instalar los paquetes que le aparecen, los cuales son la última versión estable del Proton de Valve (recompilado), el Proton Experimental de Valve (recompilado) y GloriousEggroll, la conocida bifurcación comunitaria de Proton que suele ir mejor con los juegos AAA recientes.

En caso extremo, si se usa Flatpak 1.12 o posterior, sería recomendable instalar Proton Glorious Eggroll en ese formato, ya que cuenta con la ventaja de que se actualiza de forma automática:

flatpak install flathub com.valvesoftware.Steam.CompatibilityTool.Proton-GE

En caso de no tener en funcionamiento Flatpak 1.12, el soporte completo de Proton puede obtenerse con el siguiente comando:

flatpak install flathub com.valvesoftware.Steam.CompatibilityTool.Proton com.valvesoftware.Steam.CompatibilityTool.Proton-Exp com.valvesoftware.Steam.CompatibilityTool.Proton-GE

Conclusión

Con esto ya tenemos todo lo necesario para usar la versión Flatpak del cliente de Steam, abarcando tanto el soporte para controladores como el uso de Proton para poder ejecutar los juegos para Windows.

A pesar de que Flatpak todavía tiene carencias a nivel de integración, su mejora está siendo constante y cada vez se muestra más capaz. De hecho, este servidor ya usa las aplicaciones multimedia en ese formato, tanto para audio con Lollypop como para vídeo con SMPlayer.

Aparte de romper las limitaciones de las bibliotecas compartidas “tradicionales” a la hora de portar aplicaciones gráficas, donde más sentido cobra el uso de Flatpak es en Fedora Siverblue/Kinoite, aunque esto dependerá de la aceptación que tengan los sistemas inmutables entre los usuarios de Linux.

 

Fuente: Muy Linux

Disponibles Debian 11.1 Bullseye y 10.11 Buster

publicado en: Debian, Linux | 0

 

Los responsables de Debian han anunciado la publicación de las versiones 10.11 Buster y 11.1 Bullseye, que vienen a ser los últimos lanzamientos de las ramas old stable y stable respectivamente. Como es de esperar, nos encontramos con la aplicación de los parches que se han ido acumulando desde los lanzamientos previos con el fin de evitar la realización de una actualización “pesada” justo después de completar la instalación.

Los lanzamientos estables de Debian tienen un conjunto de software estanco que raras veces es modificada durante el tiempo de vida del sistema, así que de 11.1 Bullseye sobresalen los parches para corregir tanto fallos de software como de seguridad. Entre los fallos de seguridad corregidos, nos encontramos una que permitía la ejecución de código arbitrario (CVE-2021-38173) y otra la “falta la validación de entrada en los nombres de host devueltos por los servidores DNS” (CVE-2021-3672).

En cuanto al kernel, que recordamos que en Bullseye es Linux 5.10, han llegado correcciones para los drivers Radeon (el viejo Open Source para gráficas AMD Radeon), AMDGPU (el “nuevo” para gráficas AMD Radeon) y Nouveau (el libre para gráficas de NVIDIA). Esto se suma a las correcciones aplicadas a los chips de sonido Realtek incorporado a diversos modelos de portátiles de HP.

De Debian 10.11 Buster destaca la eliminación de una gran cantidad de componentes y módulos relacionados con los núcleos 4.19.0-16 y anteriores debido a que ya nos son copilados por Linux. Esto no debería de acarrear ninguna merma a nivel de funcionamiento y características, ya que el kernel actual de Buster es la versión 4.19.0-18. Por lo demás, también están presentes los parches y cambios aplicados para corregir fallos de software y de seguridad, de entre los que sobresale la incorporación de las nuevas versiones de los microcódigos de Intel.

Los que quieran conocer todos los detalles de estos lanzamientos pueden consultar las listas de cambios de Bullseye 11.1 y Buster 10.11 publicadas por Debian. Os dejamos con los enlaces para descargar tanto la actual stable como la old stable de la distribución, aunque si se usa una gráfica Radeon sería recomendable echar un vistazo a las imágenes non-free para garantizar el arranque de los medios en vivo o del propio sistema tras realizar la instalación:

  • Descargar Debian 10.11 Buster (old stable).
  • DVD de Debian 11.1 Bullseye – Descarga directa: 32-bit, 64-bit | Torrent: 32-bit, 64-bit.
  • Medios en vivo de Debian 11.1 Bullseye – Descarga directa: 32-bit, 64-bit | Torrent: 32-bit, 64-bit.

Fuente: Muylinux

Apache Foundation publica su informe del año fiscal 2021

publicado en: Debian, Linux | 0

 

 

Apache Foundation, una de las instituciones más relevantes del código abierto y la responsable de proyectos como el servidor HTTP Apache, Tomcat, OpenOffice y Hadoop, ha presentado su informe del año fiscal 2021, que empezó 1 de mayo de 2020 y terminó el 30 de abril de 2021.

Si hablamos de año fiscal, es obvio estamos tratando con números económicos. Lo primero que se puede destacar del informe es que Apache Foundation tuvo en el año fiscal 2021 unos ingresos de tres millones de dólares frente a los 2,2 millones del año anterior. Lo que más destaca es el aumento de las donaciones públicas, que pasaron de 76.893 a 994.975 dólares y el programa de patrocinadores, mediante el cual se ingresaron 1.949.992 dólares frente a los 1.510.100 del año fiscal 2020.

En lo que respecta a los gastos, que abarcan impuestos, administración, conferencias, infraestructuras y la recaudación de fondos, entre otras cosas, han ascendido a cerca 1,6 millones de dólares en año fiscal 2021 frente a los 2,5 millones del año fiscal 2020, dando como como resultado que la fundación ha tenido unos beneficios operativos de 1.448.543 dólares en el año fiscal 2021 frente a los 277.452 obtenidos en el año fiscal 2020.

Apache Foundation tiene alojados más de 227 millones de líneas de código, que según la institución tienen un valor total de 22.000 millones de dólares. No es la primera vez que se le estima un valor tan alto a una institución o un proyecto de código abierto, ya que el código de Debian 7 Wheezy fue valorado en unos 14.400 millones de euros en el año 2012.

Más allá del debate que genera la cantidad monetaria, no es menos cierto que proyectos como Debian y muchos de los que están debajo de Apache Foundation llevan muchos años demostrando su valía en el sector corporativo, por lo que no es de extrañar que su valor estimado sea muy alto.

Abarcando los aspectos más destacados del informe del año fiscal 2021, Apache Foundation eligió 40 nuevos miembros individuales para sumar un total de 853, ha contado con 200 comités de gestión que supervisan un total de 351 proyectos junto a docenas de subproyectos e iniciativas y que 14 proyectos de alto nivel se han graduado de Apache Incubator.

Los cinco proyectos más activos en cuanto a cantidad de accesos han sido Kafka, Hadoop, ZooKeeper, POI y Logging, mientras que los principales proyectos por commits han sido Camel, Flink, Airflow, Lucene-Solr y NuttX y los más visitados en GitHub han sido Spark, Flink, Kafka, Arrow y Beam. Otros datos interesantes son el hecho de que 17.758 autores han enviado 2.184.671 de emails sobre 780.274 temas y que el equipo de seguridad de la fundación ha enviado más de 17.000 correos electrónicos.

A lo largo del año, 3.058 emisores de commits han modificado un total de 134.517.884 de líneas de código a través de 258.860 commits, se han firmado 672 acuerdos de licencias de colaborador individual, 23 acuerdos de licencia de colaborador corporativo y se han ejecutado 32 acuerdos de subvención de software.

De todo lo destacado en el informe, que es mucho, las operaciones de Apache Foundation han estado respaldadas por las contribuciones de 9 patrocinadores de nivel platino, 10 de nivel oro, 8 de nivel plata, 30 de nivel bronce, 10 patrocinadores dirigidos de nivel platino, 5 patrocinadores dirigidos de nivel oro, 3 patrocinadores dirigidos de nivel plata y 21 patrocinadores dirigidos de nivel bronce, además de 630 donantes individuales. Los que quieran conocer la lista completa de patrocinadores de Apache Foundation pueden consultar la lista desde aquí.

Los puntos más importantes del informe del año fiscal 2021 de Apache Foundation pueden ser consultados desde la correspondiente entrada en el blog de la fundación y los más curiosos o deseosos de conocer todos los detalles tienen a disposición el documento completo en formato PDF.

 

Fuente: Muylinux

«The GNOME Way» es «The Fedora Way», el futuro del escritorio Linux

publicado en: Aplicaciones, Debian, Linux, Software Libre | 0

La semana pasada nos hicimos eco de una entrada publicada los blogs de GNOME llamada “The GNOME Way”, en la que Tobias Bernard exponía su punto de vista sobre el futuro del escritorio Linux. Dejando de lado la parte más áspera para aquellos que no tienen conocimientos de desarrollo de software, sus conclusiones en torno Flatpak, las extensiones de GNOME y el futuro del escritorio tradicional fueron muy claras.

GNOME 3, desde su primera aparición, ha dejado divididos a los usuarios en tres grandes grupos: los que defienden la experiencia por defecto, los que defienden la experiencia con extensiones y los que rechazan de plano su propuesta. Esta división también llega a los redactores de MuyLinux, J.Pomeyrol y yo, así que hemos decidido de exponer nuestras opiniones (la de Jose llegará más adelante) sobre la entrada publicada por Tobias Bernard.

A estas alturas no hace falta que diga que soy un férreo defensor de la experiencia por defecto de GNOME Shell, sin extensiones, y con el cuestionado Adwaita como tema. Por otro lado, no es ningún secreto que creo firmemente que la propuesta de Fedora, impulsada por Red Hat, es el camino correcto a seguir para el escritorio Linux, sobre todo porque aplica una visión uniforme que abarca systemd, Wayland, GNOME, Flatpak y PipeWire y por el avance hacia la automatizción sin sacrificar el concepto del software libre.

Tras exponer los antecedentes, no hace falta ser un genio para adivinar que comparto hasta cierto grado la visión de Tobias Bernard, aunque también discrepo totalmente con él en una de sus conclusiones más polémicas y no comparto al 100% lo que dice en la mayoría de apartados.

Flatpak sí es el futuro de la distribución de aplicaciones para GNU/Linux

Para empezar, y al igual que Bernard, yo sí creo que Flatpak es el futuro de la distribución de aplicaciones para GNU/Linux. La tecnología de paquetes sin dependencias tradicionales impulsada por Red Hat, gracias a que se publica y distribuye como un proyecto comunitario, abre un espacio neutral para que los desarrolladores puedan abarcar, al menos teóricamente, todas las distribuciones mediante una única compilación de sus aplicaciones.

Aunque muchas personas apegadas a la filosofía Unix han rechazado Flatpak debido a la duplicación de bibliotecas, el formato de paquetes se ha convertido en un poderoso aliado para los desarrolladores, sobre todo los pequeños. Sé que esta afirmación puede resultar extraña para algunos, pero todo tiene una explicación.

Nos guste o no, GNU/Linux es la plataforma más elitista cuando se trata de desarrollar para ella, mucho más que macOS. La existencia muchísimas distribuciones, con cada una de ellas manejando versiones diferentes de las mismas bibliotecas, hace que el abarcar diversos sistemas GNU/Linux sea complicado para los desarrolladores, a veces incluso dentro de una misma distribución. Esta situación hace que los costes de desarrollar aplicaciones para GNU/Linux se eleven mucho, por lo que al final muchas aplicaciones se limitan a abarcar Ubuntu debido a que es la distribución más popular.

El problema de tener lidiar con las dependencias de las distribuciones no es algo que afecte demasiado a Microsoft o Google, porque las grandes corporaciones tienen medios económicos de sobra para dotarse de los medios necesarios, sino que los principales perjudicados son los pequeños proyectos, que no pueden hacer frente a semejante escenario y luego tienen que pedir o rezar para que las comunidades lleven sus creaciones más allá de Ubuntu.

Aquí es donde Flatpak entra en juego, porque permite que la compilación oficial de una aplicación pueda ser ejecutada, al menos en un principio, sobre cualquier distribución (aquí abarcamos otra conclusión de Tobias Bernard: Los desarrolladores de aplicaciones deben hacer sus propios paquetes). De hecho, las versiones de aplicaciones como Steam, Steam Link y LibreOffice son oficiales, por lo que el usuario puede disponer de la última versión de cada una de ellas de forma fácil y sin comprometer la integridad del sistema gracias a que Flatpak ejecuta las bibliotecas dentro de su propio entorno.

Flatpak tiene un gran rival: el formato Snap de Canonical. Sinceramente, desconfío mucho de Snap porque la distribución de los paquetes se centra casi en su totalidad en la Snap Store, que pertenece a Canonical, frente a un Flathub que es un repositorio independiente. El hecho de que la Snap Store centralice la distribución de aplicaciones daría a Canonical el poder para determinar qué aplicaciones se distribuyen no solo para Ubuntu, sino también para el resto de distribuciones que decidan utilizar Snap.

Aprovecho la ocasión para pedir a corporaciones como Microsoft y Slack para que publiquen compilaciones oficiales de sus aplicaciones en formato Flatpak (si es que deciden no alojarlas en Flathub), porque alimentar la Snap Store podría terminar derivando en una situación de monopolio perjudicial para los usuarios de GNU/Linux.

El escritorio tradicional no ha muerto

La conclusión más polémica de Bernard fue la de que el escritorio tradicional había muerto. Sinceramente, para mí el escritorio tradicional no ha muerto, sino que GNOME ha sumado otra propuesta al mercado que los usuarios de GNU/Linux pueden elegir.

GNOME Shell y su paradigma han suscitado muchos debates que han abarcado distintos temas, pero desde mi punto de vista, el rechazo de muchos usuarios se basa principalmente en un hecho: Que GNOME ha invertido la forma en que el usuario de GNU/Linux ha tendido a entender su escritorio.

El escritorio Linux ha tendido a ofrecer mucha personalización, pero poca automatización. El usuario siempre ha podido personalizar hasta el más mínimo detalle de su escritorio, pero luego incluso para realizar las tareas más sencillas tenía que tirar de la línea de comandos. GNOME 3 invirtió dicho paradigma, presentando un entorno de escritorio que no es, al menos en un principio, muy personalizable, pero que por debajo ejecuta una gran cantidad de servicios que al final terminan ofreciendo una experiencia bastante automatizada, minimizando de esta manera el uso de la consola (de ahí que Fedora Workstation tenga poca dependencia de la consola, a pesar de no contar con un panel a nivel de administrador como Yast).

Por otro lado, pienso que el concepto de escritorio propuesto por GNOME Shell ha sido incomprendido. Muchas personas se empecinan en usar GNOME Shell como un entorno tipo Windows, sin entender que fue concebido para ser usado mediante ventanas flotantes que el usuario tiene que organizar a través de los espacios de trabajo, de ahí que carezca de una barra de tareas tradicional.

El poner a disposición solamente las opciones necesarias es para muchos un inconveniente, pero yo lo veo como una ventaja porque elimina distracciones innecesarias, ayudando al usuario a centrarse en la tarea. Tanto Adwaita como la eliminación de elementos del entorno van encaminados en esa misma dirección, y después de años de uso, puedo decir que los desarrolladores de GNOME han logrado con creces dicho objetivo, aunque eso no quita que haya algunos aspectos por pulir.

Pese a todo, creo que el escritorio tradicional seguirá entre nosotros por muchos años (por no decir décadas). Solo hay que ver el reciente Steam Deck, que ha apostado por KDE Plasma como entorno de escritorio (y probablemente interfaz secundaria) probablemente por su similitud con Windows a nivel de diseño, la más fácil de reconfiguración de Kwin en algunos aspectos frente a Mutter y el hecho de que tiene la puerta abierta a tener Wayland a pleno rendimiento en un futuro cercano.

Si bien mi preferencia es clara, mi visión del escritorio Linux no se limita a GNOME. He apoyado muchas veces (espiritualmente) a KDE Plasma en su transición a Wayland, y Discover, bien implementado, es capaz de ofrecer una experiencia de instalación gráfica tan buena como la de GNOME Software. Como alternativa a los dos grandes para ordenadores modestos me decanto por MATE, que uso en mi discreto netbook Atom.

Los temas para personalizar el acabado estético del escritorio son un disparate

Tobias Bernard dijo que “los temas que abarcan todo el sistema son una idea rota”, y personalmente, estoy de acuerdo con él, aunque posiblemente no desde la misma perspectiva.

Jose dio en el clavo cuando dijo en agosto de 2020 que soy una persona que se adapta al entorno y no al revés. Esta visión no solo deriva del uso de la implementación base de GNOME Shell, sino también de mi mala experiencia cuando cambiaba el tema usado de manera predeterminada por el entorno de escritorio.

En tiempos pasados, tras cambiar el tema del escritorio o modificarlo descubría que había cosas que no estaban en su sitio, como letras blancas sobre un fondo gris claro o letras negras sobre un fondo azul oscuro, y eso cuando los elementos no se salían de su ubicación, rompiendo totalmente el diseño de la aplicación que tenía delante. Aquello me hizo reacio a cambiar el tema por defecto salvo en Ubuntu 18.04, ya que Ambiance luce horrible en GNOME Shell y Yaru, el tema por el que lo sustituía, es oficial y mantenido por Canonical.

Por lo demás, es que no cambio nunca el tema por defecto. En Debian con GNOME y Fedora Workstation dejo Adwaita, en Debian con MATE dejo el Menta personalizado que trae, en Manjaro KDE dejaba Maia, en KDE neon dejaba Brisa/Breeze, y siempre veo que todo está en su sitio salvo contadísimas excepciones. No, no me parece una buena idea personalizar el aspecto estético, pero eso no quita que esté a favor de la presencia de una tema Adwaita oscuro que sea fácil de establecer en GNOME.

Para cerrar el tema de la personalización, ni Windows, ni macOS, ni Android, ni iOS ofrece el nivel de personalización de GNU/Linux, lo que me lleva a la siguiente pregunta: ¿es la personalización una característica que hará triunfar al escritorio Linux? Mi respuesta es un contundente no, y eso no quiere decir que KDE Plasma tenga que traicionarse a sí mismo, pero es obvio que lo que busca la mayoría de los usuarios es facilidad, comodidad, automatización y un aspecto bonito.

Las extensiones merecen un mejor trato, pero no para personalizar el entorno

Bernard dijo que las extensiones de GNOME serán un nicho y que, en caso de buscar un impacto real, lo suyo sería contribuir directamente al entorno. Yo, en cambio, creo que las extensiones merecen un mejor trato, pero no para transformar la experiencia ofrecida por la implementación base del escritorio.

La mayoría de la gente usa extensiones para modificar la experiencia con el entorno, intentando muchas veces tener una disposición tipo Windows. Para tener un escritorio tipo Windows, creo que sería mejor usar otro entorno, y aquí es donde entra KDE Plasma para ofrecer una experiencia de ese tipo, añadiéndole potencia, versatilidad, optimización y con las vistas puestas en las tecnologías del futuro para el despliegue de gráficos en GNU/Linux (Wayland y las bibliotecas que los acompañen).

No desprecio todas las extensiones, porque algunas como GSConnect, el porcentaje de la batería del Dual Shock 4 (ojalá algún día soporte el DualSense) y el de GameMode aportan cosas de utilidad, pero aquellas orientadas a convertir el dash en un dock o que introducen bandejas del sistema se dedican a forzar a GNOME Shell para que trabaje de una manera para la que no fue concebido.

Conclusión: Tobias Bernard acierta en muchas cosas del qué, pero poco del cómo

La relación entre Fedora, Red Hat y GNOME es muy estrecha. Esto no solo vincula al entorno de escritorio y las correspondientes distribuciones, sino también a tecnologías como PulseAudio, PipeWire, Flatpak, systemd y Wayland. Con esto sobre la mesa, queda en evidencia que la postura de Tobias Bernard está bastante influida por ese factor, a pesar de que él es empleado de Purism.

A través de “The GNOME Way”, Bernard señala indirectamente hacia la creación de un framework unificado para GNU/Linux que abarca bastantes componentes, demasiados para algunos, pero en mi opinión los necesarios. Si queremos que GNU/Linux triunfe en el escritorio, no queda otra que establecer una visión uniforme que abarque distintas tecnologías para que estas trabajen en forma conjunta y uniforme, y ya que aquí nadie se pone de acuerdo, la única vía que queda es la de la imposición, que es lo que está ocurriendo.

Sin embargo, no soy partidario de que ese framework deje fuera al escritorio tradicional, y viendo que tampoco lo soy de la personalización de GNOME, lo mejor es dejar la puerta abierta para que entornos de escritorio “tradicionales” puedan acoplarse a dicho framework, cosa KDE Plasma está haciendo.

 

Fuente: Muylinux

The Linux Foundation lanza una encuesta sobre diversidad, equidad e inclusión en el código abierto

publicado en: Aplicaciones, Debian, Linux | 0

Los debates identitarios están a la orden del día en las sociedades occidentales y el mundo del software no es una excepción. Así, The Linux Foundation acaba de publicar una encuesta sobre diversidad, equidad e inclusión (DEI) en el código abierto a la que invita a participar a todo aquel que lo desee.

Esta encuesta de The Linux Foundation está amparada por otras compañías de relevancia en el sector tecnológico y del código abierto, como AWS, CHAOSS, GitHub, GitLab, Red Hat o VMware, entre otras, y a todas servirán sus resultados, una vez reunidos los cuales estarán a disposición de quien los solicite.

El propósito de la encuesta es el de «comprender la demografía y la dinámica con respecto a la participación general de los contribuyentes e identificar las brechas que deben abordarse como un medio para promover culturas inclusivas dentro de estos entornos».

Con todo, la encuesta se centra más en suscitar la denuncia de conflictos que en detectar la posible diversidad de los participantes, con preguntas excepcionales en relación, por ejemplo, al idioma -y la barrera que este supone para introducirse en comunidades de código abierto-, discapacidades, orígenes étnicos, género, percepción de género, orientación sexual, etc.

«El objetivo es identificar los sentimientos y las brechas que deben abordarse específicamente en las comunidades de código abierto, como un medio para avanzar en las culturas inclusivas en estos entornos», se explica en la introducción de la encuesta. «Esta encuesta está abierta a cualquier persona que utilice, contribuya o piense en el software de código abierto», se añade.

«El software de código abierto está creado por personas de orígenes, nacionalidades, orientaciones e identidades muy diferentes, todas cuyas opiniones deben ser respetadas, incluidas y reconocidas», dice Jim Zemlin, director ejecutivo de The Linux Foundation. «Como líderes en la gestión de las comunidades de código abierto más importantes del mundo, nos corresponde a nosotros elevar esas opiniones y preocupaciones con respecto a problemas importantes de DEI con datos cuantificables.»

Puedes participar en la encuesta a través de este enlace.

No deja de ser curioso la incidencia que están teniendo estos movimientos en el mundo de código abierto, tradicionalmente impulsado por la meritocracia, pero bienvenidos sean si de incentivar la participación y eliminar la discriminación -en cualquier sentido- se trata.

Imagen: Unspash

 

Fuente: Muylinux

Valve presenta Steam Deck, su consola híbrida con Linux

publicado en: Aplicaciones, Debian, Linux | 0

Pues ya es una realidad. Después de que se filtrara información durante el transcurso de la pasada primavera, Valve ha anunciado Steam Deck, su nueva consola de videojuegos con la que pretende adentrarse en el sector del hardware usando Linux (SteamOS) como sistema operativo.

Steam Deck es un giro de 180 grados frente a las fallidas Steam Machines. Valve ha decidido inspirarse en Nintendo Switch y presentar una consola híbrida que empieza siendo una portátil, pero que puede ser convertida en una de sobremesa mediante el uso de una estación de conexión que hará la función de dock. Otro detalle importante es que usa una APU de AMD, por lo que utiliza la arquitectura x86_64 para mantener la compatibilidad con el software existente.

Steam Deck: Características de hardware

Profundizando en las características, la Steam Deck incorpora una APU de AMD personalizada con una GPU RDNA 2 integrada y un procesador Zen 2 que funciona a una frecuencia de entre 2,4 y 3,5 gigahercios. A nivel de memoria de ejecución incluye 16GB de RAM LPDDR5 y la pantalla es de 7 pulgadas, LCD, táctil y funciona a una resolución de 1.280×800 píxeles con un ratio de aspecto de 16:10 y una tasa de refresco de 60Hz.

Posiblemente la resolución en modo portátil se quede corta para muchos, pero hay que tener en cuenta que Steam Deck usa la arquitectura x86_64 y apunta a ejecutar las versiones para PC de videojuegos exigentes, así que el usar una resolución baja en modo portátil podría ser una buena decisión para aumentar la autonomía. La batería de la consola es de 40Wh y según Valve ofrecerá una autonomía de entre dos y ocho horas (esto puede depender de aspectos como la configuración gráfica utilizada y las exigencias del propio videojuego).

Steam Deck tiene para la conectividad Wi-Fi en las bandas de 2,4 y 5 gigahercios (a/b/g/n/ac), Bluetooth 5, USB Type-C para los accesorios y una ranura para microSD. Como estamos ante un producto que puede hacer la función de consola portátil, otro punto muy interesante son los controles que incorpora, que son los siguientes:

  • Botones A, B, X e Y.
  • Cruceta.
  • Gatillos analógicos L y R.
  • Botones frontales L y R.
  • Botones de Ver y de Menú.
  • 4 botones de empuñadura asignables.
  • 2 sticks analógicos de tamaño completo con toque capacitivo.
  • 2 trackpads cuadrados de 30 mm con retroalimentación háptica.
  • Pantalla táctil.

Cerramos el apartado de hardware mencionando que se comercializarán tres versiones de la Steam Deck, las cuales se distinguen por el almacenamiento de datos y algún que otro detalle:

  • La Steam Deck de entrada cuenta con 64GB de almacenamiento eMMC e incluye un estuche de transporte. Su precio es de 419 euros.
  • El modelo intermedio tiene 256GB de almacenamiento mediante NVMe SSD, ofreciendo un mejor rendimiento en este aspecto además de más capacidad. Incluye el estuche de transporte, un lote de perfil exclusivo de la Comunidad Steam y su precio es de 549 euros.
  • El modelo tope de gama de la Steam Deck incorpora una unidad NVMe SSD de 512GB y cuenta con una pantalla antirreflectante. Además, incluye el estuche de transporte, el lote de perfil exclusivo de la Comunidad Steam y un teclado virtual con un tema exclusivo. Su precio es de 679 euros.

SteamOS 3.0: Arch Linux como base y KDE Plasma como entorno de escritorio

Valve vuelve a apostar por Linux como sistema operativo para su hardware, más concretamente por su propia distribución: SteamOS. Sin embargo, frente a versiones anteriores del sistema, la tercera versión mayor incluye cambios radicales.

SteamOS 3 se basa en Arch Linux en lugar de Debian. Esto repercutiría en el gestor de paquetes, que pasaría a ser Pacman en lugar de APT. Además, en la elección de Arch Linux ha podido influir los siguientes factores:

  • Tener más fácil acceso a versiones recientes del software. Aquí resultan especialmente importantes el kernel, el driver AMDGPU y Mesa. Veremos si Valve al final se decanta por usar un kernel LTS para minimizar el impacto de los cambios constantes y si adopta un modelo similar al de Manjaro para ofrecer actualizaciones más escalonadas a la vez que suministra las últimas versiones de los drivers.
  • Arch Linux es uno de los reyes del software vanilla dentro del espectro GNU/Linux, así que posiblemente su base sea para Valve más fácil de tratar que la de Debian, cuyo software ya viene modificado.

El uso de KDE Plasma como entorno de escritorio tiene su lógica si tenemos en cuenta que la mayoría de los gamers vienen de Windows, por lo que su disposición predeterminada les resultará más familiar. Sin embargo, es probable que la primera interfaz que vea el usuario tras iniciar sesión no sea KDE Plasma, sino Big Picture u otra interfaz de características similares, estando el entorno de escritorio como opción secundaria por si necesita retocar algo en el sistema.

Pero la disposición tipo Windows no es la única virtud de KDE Plasma frente a sus rivales, sino también algunas características como la opción “Permitir que las aplicaciones bloqueen la composición” del Compositor. En caso de que un juego dé problemas con la sincronización vertical, el usuario puede inahbilitar dicha opción, inhabilitar la sincronización vertical del juego y delegar de esta forma la sincronización vertical en Kwin. Esta vía puede reducir un poco el rendimiento de los juegos, pero igual compensa para aquellos que detestan el tearing.

 

 

Por último, los desarrolladores de KDE Plasma han metido el turbo a su implementación de Wayland, así que en un futuro no muy lejano veremos al entorno de escritorio totalmente preparado para soportar las últimas tecnologías de despliegue de gráficos para GNU/Linux. En GNOME no es necesario activar la sincronización vertical de los juegos en caso de usar Wayland, así que veremos qué beneficios aportará el protocolo a KDE Plasma en ese frente.

Steam Deck + SteamOS 3: Algunos pros y algunos contras

Como vemos, y ciñéndonos a la arquitectura, Steam Deck no es mucho más que una Steam Machine de tamaño reducido, pero las circunstancias han cambiado lo suficiente como para tener unas expectativas diferentes.

Los drivers de AMD para Linux han mejorado enormemente desde el anuncio de AMDGPU, hasta el extremo de rendir a la par que NVIDIA y ser capaces de derrotar a la combinación de Windows y NVIDIA ejecutando una “patata rodante” como Red Dead Redemption 2. Valve está muy implicada en el desarrollo de RADV, el driver de Vulkan para Radeon incluido en Mesa, y también está por ahí la reciente liberación del código de FidelityFX Super Resolution, el rival de AMD para el DLSS de NVIDIA.

Cuando las Steam Machines originales fueron comercializadas, Proton no existía. A estas alturas no hace falta recordar que Proton, que se sirve a través de la característica Steam Play del cliente de Steam, ha incrementado enormemente la cantidad de videojuegos que se pueden ejecutar en Linux. Los traductores DXVK y VKD3D (DirectX a Vulkan) han demostrado ser capaces de ofrecer un desempeño muy bueno, llegando a quedarse cerca o igualar el rendimiento de la ejecución nativa de DirectX en muchas ocasiones. Esto, junto a la destacable cantidad de videojuegos nativos disponibles para Linux, harán que Steam Deck inicie su andadura con un catálogo bastante amplio.

 

Pero no todas son buenas noticias para la nueva consola de Valve, porque tiene en su contra los elevados precios y la capacidad de almacenamiento del modelo más básico, que sobre el papel sería incapaz de soportar una instalación de Doom 2016 por cuestiones de espacio, o en el mejor de los casos se quedaría extremadamente justa. En cuanto a potencia podría ser incapaz de ejecutar colosos como Cyberpunk 2077 y el mencionado Red Dead Redemption 2 con buenos resultados, ya que se especula que el rendimiento sería similar al de una PlayStation 4.

Veremos cómo le va a Steam Deck, porque a su favor tiene su enfoque híbrido y las grandes mejoras que ha experimentado el Linux gaming en los últimos años, pero apunta a ir dirigida a un público que no parece dispuesto a usar nada que no sea Windows y NVIDIA.

Los que estén interesados en la consola ya pueden reservarla desde el sitio web oficial siempre y cuando hayan efectuado alguna compra en Steam con anterioridad a junio de 2021, una medida con la que Valve pretende limitar la reventa. La Steam Deck sería lanzada al mercado en diciembre de 2021 en Estados Unidos, Canadá y la Unión Europea, con las vistas puestas a que llegue a otros mercados durante el transcurso de 2022. Os dejamos con el vídeo de presentación de la consola.

 

Fuente: Muylinux

le9, un parche para mitigar la escasez de RAM en Linux

publicado en: Aplicaciones, Debian, Linux, Terminal, web | 0

 

El escritorio Linux se enfrenta desde hace tiempo (puede que desde siempre) a una extraña paradoja. Por un lado, es un sistema al que se recurre bastante para resucitar hardware antiguo gracias a su menor consumo de recursos frente a Windows (sobre todo a partir de Vista), pero la realidad es que no destaca por su desempeño en ordenadores con poca RAM. Dicho con otras palabras, usar Linux en un equipo antiguo y con poca RAM podría ser una idea no tan brillante como aparenta en un principio.

Por suerte los desarrolladores de Linux son conscientes del problema con la poca RAM y existen diversas iniciativas para al menos mitigarlo. Por ejemplo, systemd-oomd (OOMD hace referencia a out-of-memory daemon) es un servicio creado para tomar medidas correctivas cuando la memoria RAM disponible se está agotando. Otro esfuerzo es el parche ‘le9’, que se aplicaría al kernel Linux y viene dispuesto a ayudar en un escenario en el que se han detectado deficiencias.

‘le9’ lleva en desarrollo desde hace dos años y ha sido creado para proteger la caché del fichero y hacer que no acabe expulsado de la RAM. Siendo más específicos, ‘le9’ protege las páginas limpias del fichero que se encuentran bajo la presión de la memoria para evitar el “martilleo” y las situaciones de alta latencia y bloqueo que los usuarios se suelen encontrar cuando la cantidad de RAM disponible empieza a escasear.

Uno de los contribuidores de ‘le9’ ha comentado a Phoronix que ha sido capaz de ejecutar Firefox con 37 pestañas, Skype, Discord, dos ficheros PDF y LibreOffice en un viejo equipo con diez años de antigüedad y 2GB de RAM. Es importante mencionar que Firefox es desde hace tiempo un navegador web pesado y que las actuales versiones de Skype y Discord son aplicaciones Electron, lo que en teoría aumenta la cantidad de recursos que necesitan para ofrecer un buen desempeño.

‘le9’ todavía sigue en desarrollo, así que no es una característica de Linux. Hasta ahora parece haber despertado el interés de los encargados de XanMod y los desarrolladores de ‘le9’ esperan presentarlo cuando esté terminado para que sea revisado e incorporado en un futuro a la rama oficial de Linux. Para lograr dicho objetivo, ‘le9’ tendrá que cumplir con las exigencias de los pesos pesados del kernel, entre ellos Linus Torvalds, quien ha tardado siete años en dar el visto bueno a Lockdown y ha mostrado su escepticismo sobre las virtudes de Rust.

Además de los “clásicos” equipos antiguos x86 que por lo general no suelen ir muy sobrados de RAM, el uso de ‘le9’ podría ser interesante en áreas como el IoT y mini-PC de arquitectura ARM que no andan sobrados de recursos.

 

Fuente: Muylinux