Linux se encarga de soportar una gran cantidad de tecnologías, entre las que se encuentra una amplia gama de sistemas de ficheros. EXT4, XFS y Btrfs se han convertido en los más populares y en los únicos establecidos por defecto en la escena mainstream, mientras que F2FS es el contendiente que aspira a ser el cuarto en discordia. Con este panorama, algunos desarrolladores del kernel han propuesto retirar el veterano ReiserFS, que desde hace tiempo está más abandonado que mantenido.
ReiserFS fue introducido en el kernel Linux hace 21 años como sistema de ficheros de propósito general, con soporte de journaling y que llegó a ofrecer características innovadoras para el contexto de su época. Fue creado por Hans Reiser dentro de las instalaciones de una empresa llamada Namesys y hasta llegó a ser establecido por defecto en SUSE Linux.
Parecía que la situación de ReiserFS era, cuanto menos, relativamente buena, pero todo empezó a torcerse cuando Hans Reiser fue declarado culpable hace década y media del asesinato de su propia esposa. Desde entonces el trabajo en torno ReiserFS disminuyó bastante debido a la pérdida de su principal desarrollador y la mayor parte del trabajo realizado desde entonces fue hecho por Edward Shishkin, un exdesarrollador Namesys. La empresa, que echó a andar en 2004, dejó de operar aparentemente en el año 2007.
Viendo que ReiserFS tiene poco mantenimiento y su desarrollo está bastante parado desde hace años, el desarrollador Matthew Wilcox, que contribuye a Linux, ha iniciado una discusión con el propósito de eliminar el sistema de ficheros. Wilcox ha sostenido su postura en los cambios que se están aplicando en la estructura del kernel y que ReiserFS es la única cosa que está bloqueando su trabajo, más viendo que no parece haber recibido contribuciones importantes desde el año 2019.
Tras iniciarse la discusión, Edward Shishkin publicó un parche para que la flag que impide progresar a Wilcox fuera eliminada, pero otros desarrolladores del kernel han decidido intervenir y no precisamente a favor de ReiserFS, así que el futuro que le espera al sistema de ficheros no parece ser muy halagüeño.
Las peculiares circunstancias derivadas del encarcelamiento de Hans Reiser han despertado susceptibilidades debido a que algunos piensan que la eliminación de ReiserFS podría deberse más a cuestiones personales que tecnológicas, sin embargo, no es menos cierto que al sistema de ficheros le prestan poca atención desde hace tiempo y está lejos de ser una tecnología popular tanto entre los usuarios domésticos como corporativos de Linux.
Es oficial: ReiserFS tiene los días contados en el kernel Linux. Será en 2025 cuando desaparezca del núcleo… a menos que aparezca alguien que se comprometa a mantenerlo como corresponde. Pero como ya hemos dicho, hay alternativas de sobra en Linux.
Pero no pienses lo que no es: Linux, el núcleo, está escrito en el lenguaje de programación C… y así va a continuar. Al menos, en el corto y medio plazo. Sin embargo, la versión de C en al que está escrito Linux es antigua y tiene ‘sus cosas’. Cosas que Linus Torvalds tiene la intención de resolver con una actualización.
Según lo cuentan en ZDNet, el código del kernel Linux está escrito en C89, conocido también como ANSI C o ANSI X3.159-1989, el estándar de una época que ha quedado muy atrás en el tiempo. Tanto, que la mera actualización puede ayudar a no toparse con problemas cuya solución está disponible desde hace bastante tiempo también.
No es que C89 ya no «funcione» o no esté soportado: C es todo un estándar de la programación y su compatibilidad, incluso para el código que lleva escrito décadas, está garantizada a través de su propio compilador y en el caso de Linux, a través de GCC (GNU Compiler Collection), con el que se introdujeron diversos cambios con respecto al C corriente.
No obstante, mantenerse en una versión tan antigua de C tiene sus contraindicaciones, como ha descubierto el mismo Torvalds a raíz de la propuesta de un parche de seguridad que resolvía un problema, pero revelaba otro, derivado del uso no de C89, sino de C99, la versión estándar de C lanzada en 1999, también soportada en el kernel.
Sin entrar en pormenores técnicos que lo cierto es que se nos escapan, digamos que la solución del padre de la criatura ha sido la obvia: actualizar el código C de Linux a C11, la versión estándar lanzada en 2011 y que corrige situaciones como la que ha hecho reaccionar a Torvalds (en el anterior enlace está la conversación con todos los detalles, pro si a alguien le interesa).
Así las cosas, los principales mantenedores de Linux tienen trabajo por delante, ya que el cambio de versión es factible y la compatibilidad hacia detrás está asegurada, pero también «podría revelar cualquier cantidad de sorpresas en lugares oscuros del kernel», apunta uno de ellos ante la iniciativa de Torvalds de moverlo de cara al lanzamiento de Linux 5.18… si se puede.
Desde luego, es mucho menos trabajo del que sería portar todo el código de Linux a Rust, una propuesta que avanza por su cuenta, pero que no se prevé que pase mañana o que lo haga como parece, reemplazando la totalidad del código del kernel… y es que C no se va a ningún sitio.
Project Zero, el equipo de analistas de seguridad compuesto por empleados de Google dedicado principalmente a hallar vulnerabilidades de día cero (zero-day), ha publicado un informe en el que se muestra a Linux como proyecto más rápido que compañías como Apple y Microsoft a la hora de corregir fallos de seguridad.
Para realizar el informe, Project Zero ha tomado todos los fallos de seguridad corregidos desde enero de 2019 hasta diciembre de 2021. El equipo de analistas de seguridad de Google ha recalcado el trabajo que hace para dificultar el terreno a los actores maliciosos, pero también ha comentado sobre su informe que “hay una serie de advertencias con nuestros datos, la mayor de las cuales es que analizaremos una pequeña cantidad de muestras, por lo que las diferencias en los números pueden o no ser estadísticamente significativas”.
Project Zero notifica al vendedor y le concede 90 días para corregir un fallo antes de hacerlo público, pudiendo dar 14 días de gracia si se confirma que hay planes serios de publicar un parche antes de los 104 días. Del informe, lo más interesante es la tabla en la que se comparan los fallos corregidos con el tiempo empleado para publicar los correspondientes parches.
Por lo que se puede ver en la tabla, Linux (en este caso el kernel como proyecto) ha sido el vendedor más rápido a la hora de solucionar sus vulnerabilidades, habiendo conseguido corregir el 96% de los fallos reportados por Project Zero dentro del límite estándar de 90 días. Esto quiere decir que de 24 de las 25 vulnerabilidades reportadas por los investigadores en seguridad de Google han sido resueltas dentro del plazo que el gigante del buscador considera como razonable, mientras que el fallo restante excedió tanto el plazo estándar como el periodo de gracia.
Entre los vendedores que aparecen en la tabla de arriba, que corresponde a los fallos que han sido resueltos, solo Google sigue la estela de Linux al haber corregido el 95% de las vulnerabilidades dentro del plazo estándar de 90 días, con 53 fallos que fueron corregidos a tiempo de 56 descubiertos por su propio equipo de seguridad. Por su parte, Microsoft ha cumplido en el 76% de los casos dentro de los 90 días (61 de 80) y ha apurado el tiempo de gracia en el 19% de los casos (15 de 61), mientras que Apple ha corregido el 87% de los fallos dentro en los 90 primeros días tras ser informada (73 de 84). Sorprende ver cómo Apple y Microsoft se sitúan por debajo de Mozilla, que logró corregir 9 fallos de los 10 reportados dentro del límite estándar, aunque posiblemente el volumen influya en la mayor efectividad de la fundación tras Firefox.
Otro dato que sobresale de Linux es el tiempo medio necesario para corregir un fallo, que en el kernel es de tan “solo” 25 días. Dejando atrás el campo de “otros”, que engloba muchos proyectos y empresas de naturaleza muy diversa, vemos que Google se alza con el segundo puesto con 44 días y Mozilla es tercera con 46 días. Apple y Microsoft han tardado de media 69 y 83 días respectivamente.
Parece que los vendedores se lo están poniendo cada vez más difícil a Project Zero. En la siguiente tabla se puede ver un descenso en la cantidad de fallos reportados por parte de la división de Google y también como, a niveles generales, los desarrolladores son más rápidos a la hora de parchear, sobre todo en lo que respecta a Linux. Google empeora sus registros en el año 2021 y Apple no consigue mejorar de forma consistente.
En cuanto a plataformas para móviles, Project Zero ha tenido en cuenta tres: iOS, Android de Samsung y Android de Pixel. De la primera descubrieron 76 fallos con un tiempo de corrección medio de 70 días, mientras que del Android de Samsung se reportaron 10 fallos con un periodo medio de corrección de 72 días y del Android de Pixel 6 fallos con 72 días como tiempo medio necesario para parchear. La razón de la desproporcionada cantidad de vulnerabilidades de iOS se debe a que ahí se han contado también las aplicaciones suministradas junto al propio sistema operativo.
Y cerramos nuestro resumen del informe de Project Zero con los navegadores web, donde se han tenido en cuenta, siguiendo lo expuesto en el informe, a Chrome, WebKit y Firefox. El navegador de Mozilla es el más lento a la hora de publicar un parche tras ser reportarle un fallo, pero es la más rápida cuando se trata del periodo entre la publicación del parche y su liberación a través de un lanzamiento de Firefox. Chrome se muestra extremadamente rápido en la publicación de parches, pero no tanto en el lanzamiento, mientras que WebKit corrige a más velocidad que Mozilla, pero termina siendo de lejos el que más tarda en el lanzamiento.
En total, Chrome termina siendo el más rápido a la hora de solucionar sus fallos, si bien Firefox sigue su estela en términos relativos. Por su parte, WebKit tiene bastante que mejorar para dar alcance a sus rivales.
Conclusión
Como vemos, y según los datos recopilados por Project Zero de Google, Linux se muestra como un proyecto muy efectivo cuando se trata de corregir fallos de seguridad, y no solo a la hora de resolverlos, sino también de hacerlo en periodos de tiempo bastante cortos, incluso más cortos que los empleados por gigantes como Apple, Microsoft, Google y Oracle.
Aunque Linux ha tenido a su favor el hecho de ser el desarrollo de un único producto, no es menos cierto que mantener a raya los en torno a 30 millones de líneas de código del kernel no es algo fácil.
Intel ha dado un golpe de autoridad con Alder Lake, la última generación de sus procesadores. Después de un tiempo en el que la compañía se veía un tanto superada por AMD, ha sabido reaccionar de buenas maneras con el 12600K, que al menos en noviembre de 2021 fue capaz de plantarle cara hasta al Ryzen 7 5800X de AMD para erigirse como un procesador top dentro de la gama media.
Sin embargo, cuando aplicamos la revolución que ha supuesto Alder Lake a los sistemas operativos, los resultados resultaron ser, en un principio, decepcionantes para los usuarios de Linux, que vieron cómo Windows 11 mostraba un rendimiento superior en una comparativa realizada por Phoronix en el mismo mes de noviembre de 2021.
Los resultados de aquella comparativa entre Linux y Windows 11 sobre Alder Lake despertó las críticas de algunos usuarios del sistema de código abierto, que acusaron a Intel de haber creado su última generación de procesadores centrándose exclusivamente en Windows. La razón de la derrota de Linux, que muchas veces vence en estas comparativas, fue debido a que todavía tenía cosas por pulir, sobre todo en lo referido a repartir las cargas de trabajo entre los núcleos de alto rendimiento y los de bajo rendimiento.
A pesar de haber centrado sus esfuerzos inicialmente en Windows debido a que ahí está, y con gran diferencia, la mayor cuota de usuarios, eso no significó que Intel hubiese dejado tirado a Linux. Por suerte, con la versión 5.16 del kernel el panorama ha cambiado, lo suficiente como para que la situación frente a Windows 11 se haya invertido según pruebas más recientes realizadas por Phoronix.
Si bien todavía quedan cosas por pulir, Linux 5.16 ha traído importantes mejoras en la gestión y distribución de las cargas de trabajo en los procesadores Alder Lake, las cuales han sido suficientes para doblegar a su rival. Merece la pena mencionar que en Phoronix no se ha empleado el Intel Core i5-12600K, sino el Core i9 12900K, que está orientado al escritorio de gama alta.
En cuanto a las distribuciones que se han enfrentado a Windows 11 en la segunda comparativa, la única que ha logrado superarlo con cierta diferencia ha sido Clear Linux, el sistema “experimental” de Intel. Sendas versiones modificadas de Ubuntu también han logrado superar a Windows 11, mientras que la versión diaria y estándar de la distribución de Canonical ha quedado en última posición.
Si Linux 5.16 ha dado muestras de remontar frente a Windows, lo mejor podría estar por llegar con la futura versión 5.18 del kernel, la cual incorporará, o al menos así está planeado, la Interfaz de Retroalimentación de Hardware Mejorada (Enhanced Hardware Feedback Interface/EHFI), que debería de mejorar todavía más el rendimiento y la eficiencia de los procesadores híbridos Alder Lake.
A pesar de las críticas que recibe desde ciertos círculos, la realidad es que Intel es posiblemente el fabricante que mejor cuida su soporte de Linux, además de ser uno de los principales contribuidores del kernel.
En torno a Linux ha existido el mito de que es invencible frente al malware, sin embargo, la realidad es bien distinta, sobre todo en los últimos años, en los que la cantidad de malware que afecta al sistema Open Source ha aumentado de manera exponencial.
Según un informe de Crowdstrike del que se han hecho eco en Bleeping Computer, la cantidad de malware que afecta a Linux ha aumentando en un 35% en 2021 comparado con los datos obtenidos el año anterior. No es el crecimiento más grande que hemos publicado a través de los medios de TPNET, ya que AV-Test indicó en un informe de 2017 que el malware contra Linux había aumentado en un 300% en 2016.
De entre todo el malware sobresalen tres familias, Mirai, Mozi y XorDDoS, que juntas han representado el 22% de todos los ataques de malware dirigidos contra Linux en 2021. El objetivo principal sigue siendo los dispositivos IoT, así que los usuarios de escritorio no tienen por qué alarmarse, al menos de momento.
Mirai es todo un veterano entre los malware dirigidos contra Linux. Habiendo sido descubierto en el año 2016, es un potente troyano que, al menos en su forma original, fue creado con el fin de comprometer dispositivos IoT para sumarlos a una botnet orientada a lanzas ataques DDoS. De hecho, fue lo empleado para el ataque DDoS llevado a cabo contra las DNS de Dyn, una acción con la que se consiguió tumbar importantes sitios web como PayPal, Amazon, Twitter, Netflix, Spotify, Airbnb, Reddit y SoundCloud.
Que el código fuente de Mirai esté disponible ha permitido la creación de numerosas bifurcaciones, variantes y evoluciones del malware, las cuales por lo general implementan protocolos de comunicación de mando y control y se dedican a realizar ataques de fuerza bruta contra dispositivos con credenciales débiles. Comparado con el año anterior, en 2021 han sobresalido las variantes Sora, IZIH9 y Rekai, de las cuales el número de muestras ha aumentado un 33%, 39% y 83% respectivamente.
Cambiando de familia, Mozi es una botnet de P2P que se apoya en el sistema búsqueda de Tablas de Hash Distribuidas (DHT) para ocultar las comunicaciones sospechosas y evitar que sean detectadas por las soluciones encargadas de monitorizar la red. Según X-Force, la unidad de ciberseguridad de IBM, fue el responsable de alrededor del 90% del tráfico de red malicioso de dispositivos IoT entre octubre de 2019 y junio de 2020. Con el paso del tiempo ha ido evolucionando para añadir más vulnerabilidades y así expandir su radio de acción.
Y por último tenemos a XorDDoS, un troyano capaz de afectar a compilaciones de Linux para diversas arquitecturas, entre ellas ARM y x86, y emplea cifrado XOR para las comunicaciones de mando y control. Aplica fuerza bruta (probar contraseñas una a una hasta dar con la correcta) a través de SSH y utiliza el puerto 2375 para lograr acceso como root sin contraseña. La distribución de XorDDoS se ha extendido en 2021 en parte gracias a un actor malicioso de origen chino llamado Winnti, que lo implementaba con otras botnets derivadas.
Como vemos, el malware contra Linux es una tendencia al alza que apunta a mantenerse en los próximos años, pero aparentemente centrado en el Internet de las Cosas y en menor medida los servidores. Sin embargo, y a pesar de no arrastrar decisiones cuestionables implementadas en Windows, esto no debería de ser un incentivo para que los usuarios de escritorio bajen la guardia, más viendo que muchos de ellos ven a Linux como un sistema operativo invencible que ofrece seguridad por arte de magia.
En torno a Linux ha existido el mito de que es invencible frente al malware, sin embargo, la realidad es bien distinta, sobre todo en los últimos años, en los que la cantidad de malware que afecta al sistema Open Source ha aumentado de manera exponencial.
Según un informe de Crowdstrike del que se han hecho eco en Bleeping Computer, la cantidad de malware que afecta a Linux ha aumentando en un 35% en 2021 comparado con los datos obtenidos el año anterior. No es el crecimiento más grande que hemos publicado a través de los medios de TPNET, ya que AV-Test indicó en un informe de 2017 que el malware contra Linux había aumentado en un 300% en 2016.
De entre todo el malware sobresalen tres familias, Mirai, Mozi y XorDDoS, que juntas han representado el 22% de todos los ataques de malware dirigidos contra Linux en 2021. El objetivo principal sigue siendo los dispositivos IoT, así que los usuarios de escritorio no tienen por qué alarmarse, al menos de momento.
Mirai es todo un veterano entre los malware dirigidos contra Linux. Habiendo sido descubierto en el año 2016, es un potente troyano que, al menos en su forma original, fue creado con el fin de comprometer dispositivos IoT para sumarlos a una botnet orientada a lanzas ataques DDoS. De hecho, fue lo empleado para el ataque DDoS llevado a cabo contra las DNS de Dyn, una acción con la que se consiguió tumbar importantes sitios web como PayPal, Amazon, Twitter, Netflix, Spotify, Airbnb, Reddit y SoundCloud.
Que el código fuente de Mirai esté disponible ha permitido la creación de numerosas bifurcaciones, variantes y evoluciones del malware, las cuales por lo general implementan protocolos de comunicación de mando y control y se dedican a realizar ataques de fuerza bruta contra dispositivos con credenciales débiles. Comparado con el año anterior, en 2021 han sobresalido las variantes Sora, IZIH9 y Rekai, de las cuales el número de muestras ha aumentado un 33%, 39% y 83% respectivamente.
Cambiando de familia, Mozi es una botnet de P2P que se apoya en el sistema búsqueda de Tablas de Hash Distribuidas (DHT) para ocultar las comunicaciones sospechosas y evitar que sean detectadas por las soluciones encargadas de monitorizar la red. Según X-Force, la unidad de ciberseguridad de IBM, fue el responsable de alrededor del 90% del tráfico de red malicioso de dispositivos IoT entre octubre de 2019 y junio de 2020. Con el paso del tiempo ha ido evolucionando para añadir más vulnerabilidades y así expandir su radio de acción.
Y por último tenemos a XorDDoS, un troyano capaz de afectar a compilaciones de Linux para diversas arquitecturas, entre ellas ARM y x86, y emplea cifrado XOR para las comunicaciones de mando y control. Aplica fuerza bruta (probar contraseñas una a una hasta dar con la correcta) a través de SSH y utiliza el puerto 2375 para lograr acceso como root sin contraseña. La distribución de XorDDoS se ha extendido en 2021 en parte gracias a un actor malicioso de origen chino llamado Winnti, que lo implementaba con otras botnets derivadas.
Como vemos, el malware contra Linux es una tendencia al alza que apunta a mantenerse en los próximos años, pero aparentemente centrado en el Internet de las Cosas y en menor medida los servidores. Sin embargo, y a pesar de no arrastrar decisiones cuestionables implementadas en Windows, esto no debería de ser un incentivo para que los usuarios de escritorio bajen la guardia, más viendo que muchos de ellos ven a Linux como un sistema operativo invencible que ofrece seguridad por arte de magia.
Se trata de una vulnerabilidad de escalación de privilegios y de fácil explotación en Linux que puede proporcionar acceso root. Ya está circulando un exploit.
Descubrieron una vulnerabilidad en Polkit, un componente para controlar sistemas con todos los privilegios presente en la mayoría de las distribuciones de Linux. Este componente cuenta con pkexec, una herramienta que permite a un usuario sin privilegios ejecutar comandos como si fuera otro usuario y con los máximos privilegios. La vulnerabilidad fue registrada como CVE-2021-4034 y apodada PwnKit. Una particularidad es que existe desde 2009, por lo que afecta a todas las versiones de Polkit.
La explotación exitosa de esta CVE permite a un usuario local sin privilegios obtener acceso root en el host vulnerable. Además, investigadores de Qualys, responsables del hallazgo, desarrollaron un exploit y comprobaron que podían obtener privilegios root en Ubuntu, Debian, Fedora y CentOS. También aseguran que probablemente otras distribuciones de Linux sean vulnerables a PwnKit.
Si bien los investigadores mencionan que la explotación del fallo es sencilla, no deja de sorprender que menos de tres horas después de se publicara el análisis técnico de la vulnerabilidad por parte de Qualys, se haya publicado un exploit que medios como BleepingComputer confirman que funciona y permite obtener privilegios root en un sistema. Asimismo, Will Dorman, analista del CERT Coordination Center confirmó que funciona en sistemas ARM64.
El error radica en que pkexec no manipula correctamente los parámetros de llamada y termina intentando ejecutar variables de entorno como comandos. Los investigadores recomiendan instalar los parches que publicaron los autores de Polkit. La mayoría de los distribuidores de Linux están trabajando en un parche que estiman saldrá a la brevedad. Ubuntu ya lanzó un parche que corrige la vulnerabilidad para las versiones ESM 14.04 y 16.04 y para las versiones 18.04, 20.04 y 21.10.
Si bien no puede ser explotada remotamente y es necesario que el atacante obtenga acceso local a una cuenta, se trata de una vulnerabilidad importante. Además, si bien ya se lanzó un exploit, es esperable que aparezcan otros.
FLB Music es otro de los tantos reproductores multimedia que existen para Linux. Este software está basado en Electron, y cuenta con una interfaz gráfica intuitiva y fácil de usa. Además, lo positivo de este reproductor de audio es que integra tanto las funciones para reproducir y administrar tus playlists favoritas como también un gestor de descargas integrado.
Lo encontrarás en algunos repos de las distros más populares, para instalarlo fácilmente. También lo tienes en paquetes Snap y como AppImage, si prefieres estos otros formatos para instalar el binario en tu distro. Recuerda que si optas por el AppImage, una vez descargues el paquete tendrás que darle permisos de ejecución…
Si te preguntas por lo que puede ofrecerte FLB Music, aquí tienes un resumen:
GUI sencilla y atractiva.
Soporte para organizar la música por artistas, álbumes, directorios, y soporte para playlists configuradas.
Muestra la letra de canciones.
Integra un gestor de descargas para descargar canciones de plataformas de streaming como Deezer y Youtube.
Modo mini para dejarte espacio para hacer otras tareas en tu escritorio mientras escuchas música.
Ecualizador.
Soporte para temas nuevos en su interfaz.
¿Problemas de FLB Music? Pues, como podrías imaginar de algo que usa Electron, es que no va a ser todo lo ligero que te gustaría que fuese. El uso de recursos de hardware por parte de este reproductor de audio es considerable, especialmente el uso de memoria RAM. Comparado con otros reproductores similares para Linux, este FLB Music usa algo más de 500 MB, muy por encima de otros como Deepin Music (200 MB), Sayonara (99 MB), o musikcube (32 MB). Esto supone un coste importante, especialmente si no tienes una máquina suficientemente potente y con una gran capacidad de RAM. Mucho más si tienes pensado usarlo junto con entornos de escritorio pesados y navegadores como Chrome, que no destacan por necesitar poca memoria principal precisamente.
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.
La defenestración de CentOS por parte de Red Hat el año pasado sacudió un avispero que no existía y sin importar que la compañía del sombrero rojo anunciase planes de compensación con la propia RHEL, donde había un solo clon de esta ocupando el panorama, ahora hay al menos tres que se pueda contar con ellos, y más en marcha.
El tema lo hemos tratado en multitud de ocasiones, pero si en el párrafo de introducción no has encontrado nada con sentido, te lo traducimos y resumimos en poco más que titulares:
Red Hat acabó con CentOS, la distribución derivada de Red Hat Enterprise Linux (RHEL) más popular del mercado.
Alternativas había de sobra, algunas iguales a lo que ofrecía CentOS, otras no tanto; pero alternativas todas ellas, a fin de cuentas.
Con todo, la «comunidad» respondió y a lo largo de las primeras semanas tras la noticia de marras, se anunciaron varios forks de RHEL.
Red Hat respondió con un gesto, con la intención de calmar las aguas y compensar un poco al personal, que no a las corporaciones roñosas de turno.
Red Hat extendió el gesto, para que no cupiese duda de que con la muerte de CentOS no buscan aprovecharse de nadie, sino que se trata de una reestructuración con otros intereses.
Pero ninguno de los cambios propuestos por Red Hat surtió efecto, una vez las ruedas «comunitarias» comenzaron a girar. Y en esas estamos ahora, con el primer derivado de RHEL, AlmaLinux, viento en popa a toda vela y marcando el ritmo desde la primera actualización; con otro a punto de aparecer, para más datos el primero que se anunció y el de corte más puramente comunitario hasta la fecha; y con un desconocido que acaba de presentarse en sociedad: VzLinux.
VzLinux
VzLinux es un sistema mantenido por Virtuozzo, una compañía de servicios de virtualización con una larga trayectoria a sus espaldas. Lo mismo ocurre con VzLinux, cuyo uso de manera interna -incluidos sus clientes- ha sido constante desde hace más 20 años, que se dice pronto. ¿Por qué nadie sabía de VzLinux hasta ahora? Porque no se distribuía de puertas afuera, se entiende. ¿Que ha cambiado? Lo ya expuesto. Así lo explica Maik Broemme, Gerente de Producto Senior de Virtuozzo:
«El mercado empresarial de distribuciones de Linux se está alejando de los servidores Linux dominados por CentOS por el ocaso de la distribución programado para finales de este año. La brecha resultante en el mercado requiere una solución confiable con longevidad, por lo que optamos por hacer que nuestro VzLinux esté disponible públicamente. Nuestro objetivo es simplemente brindar a la industria una alternativa viable y gratuita con capacidades de transición fluidas.»
Virtuozzo describe a VzLinux como «una distribución multipropósito gratuita optimizada para ejecutarse en contenedores, máquinas virtuales o servidores bare-metal. Está diseñado para admitir cargas de trabajo y aplicaciones de nivel empresarial intensivas». Una distribución para la que Virtuozzo ya tiene preparado el proceso de migración desde CentOS «sin tiempo de inactividad», y de la que presume por su rapidez de actualización con respecto a RHEL y en comparación con CentOS.
En contra de esa rapidez de actualización, sin embargo, está la versión de la distribución disponible para descarga: VzLinux 8.3, un poco por detrás de lo esperado cuando RHEL 8.4 salió a finales de abril y un mes después Oracle Linux y Almalinux le siguieron el paso. Sea como fuere, VzLinux es un hecho y una alternativa a priori solvente más con la que cubrir el hueco dejado por CentOS.
Ya solo falta Rocky Linux en aparecer, al menos en cuanto a los derivados de RHEL bien respaldados de los que se tenía constancia. No debería tardar mucho. Mientras tanto, las propuestas empresariales llevan la iniciativa: primero fue AlmaLinux y ahora es VzLinux, ambas bajo el paraguas de sus respectivas compañías, a la postre largo tiempo especializadas en lo que ahora ofrecen a todo el mundo.
PipeWire es una de las tecnologías llamadas a jugar un papel muy importante en el futuro del escritorio Linux, no solo porque ha sido postulada como la sustituta de PulseAudio y JACK, sino porque en realidad es un servidor de transmisión de multimedia que va más allá de la etiqueta de “servidor de sonido” que muchos le han puesto.
Los retos a los que se enfrenta PipeWire han quedado plasmados en una entrevista publicada en Fedora Magazne que Christian Schaller, director senior del equipo de escritorio de Red Hat y uno de los pesos pesados de GNOME y Fedora, ha realizado a Wim Taymans, uno de los fundadores de GStreamer, creador de PipeWire y también empleado de Red Hat.
La ambición mostrada en el desarrollo de PipeWire queda plasmada en los diversos desafíos que tiene por delante, de entre los que se puede destacar el dotar a GNU/Linux de un servidor de sonido de categoría profesional y el ofrecer un marco que facilite la captura y la compartición de la pantalla en sesiones de Wayland. En lo que respecta al último apartado se han dado muchos pasos hacia adelante en los últimos meses, sobre todo gracias al futuro OBS Studio 27 y a pequeños proyectos como Kooha.
Wim Taymans explica en la entrevista que PipeWire ha terminado siendo el resultado de dos ideas anteriores: “La primera fue PulseVideo, que fue escrito por William Manley en 2015. Era un pequeño servidor que enviaba el video desde una cámara V4L2 a uno o más procesos. Usó GStreamer, DBus y el pase de descriptor de archivo (fd) para realizar el proceso de manera eficiente.”
“Por aquella época empezamos a pensar en la captura de la pantalla desde Wayland y me pidieron que investigara las opciones. La idea fue entonces tomar el concepto de PulseVideo e implementar la posibilidad de que los clientes también proporcionen transmisiones (no solo dispositivos V4L2). Otro requisito era hacer esto de forma segura y lidiar correctamente con Flatpak y su concepto de portales para manejar cosas con posibles problemas de seguridad”.
Llegados a este punto, podría ser de valor recordar que el desarrollo de PipeWire está bastante vinculado al de Flatpak, algo que no tendría que sorprender si tenemos en cuenta que esas dos tecnologías, además de GNOME, systemd y PulseAudio, están todas impulsadas principalmente por Red Hat, lo que explica el hecho de que Fedora sea la distribución que marque la evolución tecnológica de GNU/Linux.
Como vemos, la función de PipeWire como servidor de sonido es algo que no estaba al principio, ya que en Fedora 27, primera versión de la distribución que lo suministró, solo era capaz de lidiar con la captura de vídeo. El propio Wim Taymans dice que PipeWire necesitó de “otra reescritura” para poder manejar sonido, cosa que refuerza su condición de servidor de transmisión de multimedia. Sin embargo, desde MuyLinux no vamos a rebatir a quien lo defina como un servidor de sonido, porque así será visto y percibido por parte de los usuarios de perfil más bajo que se limitan a usar su ordenador solo para Internet, oficina y jugar a videojuegos.
En lo que respecta a la relación de PipeWire con GNOME, Taymans ha explicado que “GNOME Shell enviará una transmisión a PipeWire cuando se active el uso compartido de la pantalla. PipeWire enrutará este flujo a aplicaciones como Firefox o la grabadora de pantalla. Tenemos algunas características más avanzadas implementadas, como el paso de DMA-BUF y los metadatos para el cursor y las regiones de recorte cuando se comparte una sola ventana. También existe el control de volumen que interactúa a través de la API de PulseAudio con PipeWire para administrar los volúmenes”.
El nuevo marco para realizar screencasting y screensharing desde una sesión de Wayland, que es uno de los principales frentes que se pretenden cubrir con PipeWire, está suponiendo todo un reto, más si tenemos en cuenta que las gráficas de Intel son las únicas que cuentan con una implementación madura de DMA-BUF. En AMD Radeon por ahora está presentando bastantes problemas y NVIDIA está empezando a recorrer el camino por su terquedad.
Continuando con la relación de PipeWire con GNOME, Taymans expone que en realidad antes “no había nada para compartir la pantalla”, sino solo llamadas de X11 para capturar el contenido de la pantalla. “Jan Grulich trabajó con el proyecto WebRTC para agregar código que interaccionara con las nuevas API de portales definidas para Wayland y luego negociara las opciones de uso compartido de la pantalla y el soporte nativo de PipeWire para obtener el contenido de la pantalla. Luego, Martin Stransky portó hacia atrás ese trabajo en la copia de Firefox de WebRTC y Jan Grulich y Tomas Popela se aseguraron de que los cambios se fusionaran en Chromium/Chrome”.
A estas alturas no hace falta explicar que PipeWire es compatible con ALSA, PulseAudio y JACK, pero solo puede sustituir a los dos últimos porque el primero, al ser parte del kernel Linux, se encarga de suministrar el firmware necesario para hacer funcionar los chips de sonido. La transición de PulseAudio y JACK a PipeWire ha sido muy bien estudiada, hasta el extremo de que el tercero ofrece una alta compatibilidad con las herramientas hechas para funcionar con los dos primeros.
Quienes siguen de cerca este portal saben que soy usuario de Fedora y que ahora tengo una configuración pura de PipeWire con la versión 34 de la distribución (Ubuntu 21.04 sigue usando PulseAudio por defecto). Tengo que reconocer que PipeWire me tenía atemorizado porque en mi equipo de sobremesa no uso un chip de sonido Realtek, sino una tarjeta de sonido dedicada Xonar DSX debido a que el ALC1220 de la placa base que uso me ha salido rana. La razón de mi temor no venía de la detección de la tarjeta, porque de eso se encarga ALSA, sino del hecho de que la integración de la Xonar DSX con PulseAudio lleva rota muchos años.
Por suerte, PipeWire trabaja muy bien con la Xonar DSX, detectando correctamente los conectores Jack y no solo eso, sino que he recuperado la gestión centralizada del volumen de salida a través de la interfaz de GNOME, permitiéndome de esta manera prescindir de QasMixer, una interfaz gráfica para alsamixer que he usado durante un tiempo debido a los mencionados problemas con PulseAudio (sin embargo, desde la versión 0.36 de PipeWire me he encontrado con un bug que se reproduce cuando se cierra y abre la sesión a gran velocidad).
Como vemos, PipeWire tiene muchos retos por delante y es ahora cuando empezará a tener que lidiar con entornos reales en los que hay configuraciones de hardware y software de lo más variopinto. Si queréis saber más detalles y curiosidades de PipeWire, cuyo desarrollo se inició en Andalucía (si bien Taymans es belga), os invitamos a ver la entrevista publicada en Fedora Magazine.
