Epic Games publica los primeros ejecutables de Unreal Engine para Linux

publicado en: juegos, Linux | 0

Epic Games no es la empresa que mejor trata a Linux, una situación que se agrava si vemos la cínica postura de la compañía en torno al sistema y que es la comunidad la que está cubriendo muchas de sus carencias. Sin embargo, de vez en cuando da un paso en la dirección correcta, como la publicación de unos ejecutables de Unreal Engine para Linux.

Unreal Engine soporta Linux oficialmente desde hace años, sin embargo, y al contrario de macOS y Windows, su instalación sobre el sistema de código abierto tenía que realizarse a través de un tortuoso proceso de compilación que mostramos hace siete años sobre Ubuntu 14.04. Obviamente, con todo el tiempo transcurrido desde entonces, hoy en día ese tutorial está obsoleto, pero hasta hace poco era la única vía para tener Unreal Engine funcionando en Linux.

El tener a mano unos binarios de Unreal Engine compilados para Linux acerca un poco el soporte a lo que siempre han tenido los usuarios de Windows y macOS, que nunca han tenido la necesidad de llevar a cabo el proceso de compilación. El código fuente está disponible bajo una licencia privativa y puede que en algunos casos específicos sea conveniente compilarlo incluso en los sistemas privativos, pero el no tener unos binarios compilados para simplemente descargarlos y usarlos supone una barrera importante que pone a Linux en clara desventaja frente a sus competidores.

La versión compilada de Unreal Engine para Linux puede obtenerse a partir de este enlace. Para iniciar el proceso de descarga se requiere tener una cuenta de Epic Games, la cual puede crearse directamente o a partir de otra de Facebook, Google, Xbox Live, PlayStation Network, Nintendo, Steam o Apple. Si es la primera vez que se realiza la descarga, el usuario tendrá que aceptar los términos de uso para iniciarla. Unreal Engine está dentro de un fichero ZIP que ocupa algo más de 20GB, que una vez descomprimido se transforma en un directorio que ocupa más de 56GB en disco.

Tras descomprimir el fichero ZIP, un proceso que puede llegar a tardar bastante si uno no dispone de un equipo potente, es posible iniciar el editor ejecutando el siguiente comando o realizando la ruta indicada con el explorador de ficheros a partir de la ubicación en la que se encuentra el directorio con Unreal Engine descomprimido (el 5.0.3 corresponde a la versión, así que esa parte cambiará dentro de poco):

./Linux_Unreal_Engine_5.0.3/Engine/Binaries/Linux/UnrealEditor

Este servidor no sabe usar Unreal Engine, así que no puede decir si la versión compilada para Linux funciona bien de verdad o no, pero al menos sí ha sido capaz de iniciar el editor sobre Fedora 36 Silverblue, aunque a nivel de requisitos se recomienda Ubuntu.

Y hasta aquí la novedad de Unreal Engine para Linux, que al menos ya puede ser iniciado sin tener romperse la cabeza con las dependencias hasta lograr compilarlo en un proceso que, por lo general, suele ser más complicado de realizar fuera de Ubuntu debido a la falta de documentación.

 

 

Fuente: Muy Linux.

 

 

Steam en vehículos Tesla ¿otro paso para el Linux Gaming?

publicado en: Linux | 0

 

 

 

Elon Musk, persona que dirige y que desde hace tiempo es la cara visible de Tesla, ha anunciado a través de Twitter que la compañía está haciendo progresos para integrar el cliente de Steam en el sistema operativo empleado por sus coches eléctricos, lo que en teoría debería de ser un empujón en el buen sentido para el Linux Gaming.

La integración del cliente de Steam en los vehículos eléctricos de Tesla puede sonar a una locura si uno lo ve desde fuera, pero la realidad es que es un movimiento que tiene mucho sentido si vemos la base tecnológica desde el punto de vista de la computación, ya que el sistema operativo es Linux y los modelos más recientes emplean procesadores AMD Ryzen con gráficos RDNA 2. Dicha combinación es en base la misma que la empleada por la Steam Deck, así que la llegada de Steam a los vehículos de Tesla suena a algo verosímil.

Parece que Tesla va a apostar por una estrategia parecida a la de Google para con ChromeOS, sistema al que Steam ha llegado a modo de port del cliente para Linux. Tomar el cliente de Steam para Linux permite ejecutar una gran cantidad de videojuegos sin muchas más complicaciones, porque además de los ports nativos, también está a Proton, la conocida capa de compatibilidad basada en Wine que facilita la ejecución de videojuegos de Windows en los sistemas operativos Linux y macOS.

La llegada de Steam a los vehículos Tesla no es un movimiento hecho en caliente por parte de la compañía, sino que se está cocinando a fuego lento desde al menos principios de año, cuando el propio Elon Musk dijo a través de la misma red social que estaban “trabajando en el caso general de hacer que los juegos de Steam funcionen en un Tesla frente a títulos específicos”. Para los mencionados vehículos ya existe Tesla Arcade, que ofrece videojuegos conocidos como Cuphead y Sonic the Hedgehog 1, pero la incorporación de Steam aceleraría la disposición de títulos triple A sin que tengan que ser específicamente portados.

Y hasta aquí nada que sea realmente nuevo por estos lares. A estas alturas hemos publicado bastante de Steam para Linux y sobre las ventajas y los posibles inconvenientes de Proton, que, nos guste o no, se ha convertido en el verdadero puntal del Linux Gaming, y a eso se están aferrando Valve, Google y probablemente Tesla si todo va según hemos entendido.

Con un Linux cada vez más utilizado en los ordenadores que no adoptan la forma de las computadoras personales de toda la vida, la ejecución de videojuegos sobre el sistema de código abierto parece tener más recorrido en dichos dispositivos.

 

Fuente: Muy Linux.

 

 

Lubuntu Backports pretende suministrar el último LXQt sobre una base LTS

publicado en: Linux | 0

 

Lubuntu, uno de los grandes referentes de LXQt (antes LXDE), parece que va a intentar a reforzar su posición con un PPA oficial de backports que facilitará la instalación de la última versión del escritorio (o al menos una más reciente) sobre la base de Ubuntu LTS.

Seguro que a más de uno se le ha pasado por la cabeza Kubuntu Backports, un PPA que suministra una versión más reciente de KDE Plasma para el mencionado miembro de la familia de Ubuntu. El caso de Lubuntu Backports no es muy diferente según reconocen los responsables, que también admiten las similitudes con KDE neon.

Los encargados de Lubuntu han explicado en una entrada publicada en su blog oficial que, “a medida que pase el tiempo, nuestro enfoque de desarrollo seguirá centrado en los nuevos lanzamientos, y planeamos aterrizar y probar los cambios allí antes de enviarlos a Backports. Dicho esto, este es un término medio perfecto entre la estabilidad y las nuevas funciones que los usuarios de todos los niveles podrán disfrutar”.

A la espera de cómo acabará funcionando una vez que todo haya sido desplegado, parece que desde Lubuntu quieren que su PPA se acerque más al modelo “agresivo” de neon que a la política más pausada que por lo general se aplica en Kubuntu Backports. Obviamente, y al igual que pasa con el miembro de la familia Ubuntu con KDE Plasma, Lubuntu Backports no es una nueva edición de la distribución, sino más bien una vía para que los usuarios puedan tener la última versión de LXQt (o una más reciente) sobre la base de Ubuntu 22.04 LTS.

El hecho de centrarse en el último lanzamiento LTS de Ubuntu ha abierto la posibilidad que haya una versión del repositorio para Debian. Los responsables de Lubuntu han anunciado a través de Twitter que están trabajando para llevar los cambios que están desarrollando a Debian, así que la puerta está abierta para que los usuarios de la “gran madre” de las distribuciones también se beneficien de este esfuerzo, aunque veremos a qué ramas llega y bajo qué condiciones.

Actualmente hay un PPA en fase staging, el cual puede considerarse como en fase beta. Oficialmente el repositorio tendría que ser puesto en funcionamiento mañana si no surgen contratiempos de última hora. Desde Lubuntu se han planteado el posible lanzamiento de una imagen ISO de la versión 22.04.1 LTS con el repositorio de backports habilitado por defecto si hay demanda suficiente por parte de los usuarios.

Fuente: Muy Linux.

Rocky Linux 9, nueva versión del más fiel reemplazo de CentOS

publicado en: Linux | 0

Llega la que faltaba: Rocky Linux 9, la nueva versión de una de las derivadas más destacadas de Red Hat Enterprise Linux (RHEL) de nueva hornada, esas que aparecieron a raíz de la desaparición del CentOS clásico y que ya han ocupado su posición en el segmento del mercado que les corresponde.

Hablando así, no obstante, puede parecer que la desaparición de CentOS hizo que las derivadas de RHEL surgiesen como caracoles después de la lluvia, cuando lo cierto es que de todas las que se anunciaron, solo unas pocas han conseguido sacar cabeza, siendo AlmaLinux y Rocky Linux las dos más señaladas, que no las únicas.

Volviendo con el lanzamiento que nos ocupa, Rocky Linux 9 sigue como es obvio los pasos de Red Hat Enterprise Linux 9

, contando con las mismas novedades que trajo el buque insignia del Linux corporativo en esa versión. Es decir, lo mismo que con AlmaLinux 9 o la más reciente Oracle Linux 9, la última de las clásicas que se mantiene al día.

En este sentido, sin embargo, Rocky Linux 9 es con toda probabilidad la derivada más apegada a la base de RHEL de las que pululan por ahí. Quizás sea por su carácter comunitario -aunque AlmaLinux también va por el mismo camino, o eso es lo que pretende-, pero es que no hay prácticamente diferencias entre el lanzamiento original y este. Pero ¿acaso debería haberlas?

Si comparamos a Rocky Linux con CentOS, es estilo es ciertamente muy similar: se cambia la marca de Red Hat, ya que está registrada, cuatro cosas más a nivel de diseño y hasta ahí. Al contrario que AlmaLinux u Oracle Linux: la primera ofrece un abanico de opciones de escritorio más animado, mientras que la segunda aplica su Unbreakable Enterprise Kernel, entre otros cambios.

Rocky Linux 9, por su parte, se limita a reproducir RHEL al milímetro: GNOME 40 y sus correspondientes novedades son lo más destacado para con el escritorio; trae nuevas versiones de herramientas y lenguajes de programación como GCC 11.2.1, LLVM 13.0.1, Rust (1.58.1), and Go (1.17.1). Python 3.9, Node.js 16, Ruby 3.0.3, Perl 5.32, PHP 8.0, Rust 1.58.1, Go 1.17.1…

Sucede igual como las demás novedades que destacan en el anuncio oficial de Rocky Linux 9 donde, eso sí, recuerdan el tiempo de soporte para las versiones en curso de la distribución, aplicables al resto de derivadas de RHEL: Rocky Linux 8 mantendrá su soporte hasta el 31 de mayo de 2029, Rocky Linux 9 hasta el 31 de mayo de 2032.

En resumen, Rocky Linux es lo que se esperaba que fuera, un fiel clon de Red Hat Enterprise Linux, y Rocky Linux 9 su flamante versión, disponible para arquitecturas Intel/AMD (x86_64), ARM64 (aarch64), IBM PowerPC (ppc64le) y IBM Z (s390x), así como en imágenes para AWS en la página de descargas oficial.

Para más datos, consulta las notas de lanzamiento, donde se desgranan todos los pormenores de Rocky Linux 9.

 

Fuente: Muy Linux.

Oracle Linux 9 llega con lo mejor de RHEL 9, su Unbreakable Enterprise Kernel y más

publicado en: Linux | 0

 

Oracle Linux 9 es la nueva versión del sistema operativo del gigante tecnológico y uno de los derivados más veteranos y extendidos de Red Hat Linux Enterprise (RHEL), por lo que no es de extrañar que tras el no venga el otro, aunque los cambios más recientes han alterado de manera significativa un panorama que no se había movido apenas desde hace muchos años.

Así, tras el lanzamiento de Red Hat Enterprise Linux 9 no llegó, tal y como era habitual, CentOS 9, pues la distribución, como tal, ya no existe; sino que lo hizo AlmaLinux 9, posicionada casi desde un principio como la nueva derivada estrella de RHEL, aun cuando todavía falta por aparecer Rocky Linux.

La que ya está aquí, sin embargo, es Oracle Linux 9, una que no ha faltado a su cita desde hace tres lustros, que se dice pronto. Y siempre lo ha hecho con bastante solvencia: cual clon a nivel binario de RHEL, con una compatibilidad asegurada para con los paquetes de este, pero con sus propias especias, léase el Unbreakable Enterprise Kernel, su sello más distintivo.

Otras de las características de la distribución que también vale destacar para con el lanzamiento de Oracle Linux 9, al margen de su kernel personalizado, es se trata de un sistema totalmente gratuito y sin limitaciones de instalación: Oracle solo te cobra si quieres soporte. En caso contrario, puedes usar el sistema para lo que quieras.

Con respecto a las novedades de Oracle Linux 9, podrían resumirse en «todo lo que trajo RHEL 9 más el Unbreakable Enterprise Kernel», pero sería faltar a la verdad. A diferencia de derivadas mucho más apegadas al sabor original como son AlmaLinux o Rocky Linux, Oracle, sin romper la compatibilidad, le mete mano al sistema en varios apartados.

Por ejemplo, Oracle Linux 9 el Unbreakable Enterprise Kernel, UEK R7, basado en Linux 5.15 LTS, en lugar de Linux 5.14, que fue el que presentó RHEL9; incluye mejoras del sosrte de sistemas de archivos como Btrfs,que sigue disponible desde la misma instalación para quien desee usarlo; y mejor la integración con VirtualBox, en concreto, añadiendo soporte para carpetas compartidas de VirtualBox.

Usuarios habituales, potenciales y curiosos encontrarán la descarga de Oracle Linux 9 lista para su despliegue, en formatos DVD e imagen de arranque para arquitecturas x86_64 (x86_64) y ARM (aarch64).

 

Fuente: Muy Linux.

Disponible Debian 11.4 para pulir la experiencia estable de Bullseye

publicado en: Debian, Linux | 0

 

 

Debian 11.4 es la nueva actualización de mantenimiento de de la actual versión estable de la distribución y la segunda que ve la luz esta año, aunque por su numeración es fácil discernir en qué punto nos encontramos de la vida útil de ‘Bullseye’, cuyo lanzamiento original se dio el año pasado.

Como siempre repetimos, Debian 11.4 conserva intactas todas las novedades de Debian 11, mientras que se encarga de recoger todas las correcciones acumuladas desde el lanzamiento de la imagen previa, y como correcciones se entiende tanto mejoras de estabilidad como, principalmente, parches de seguridad. Entre unos y otros, suman algo más de un centenar de cambios.

Algunos de esos cambios incluyen correcciones en el instalador del sistema, mejoras en el soporte de gráficos NVIDIA, o la restauración de la funcionalidad del cliente de escritorio de Telegram, entre muchas otras.

Por lo demás, Debian 11.4 llega con lo que llegó en su día, incluyendo múltiples actualizaciones, mejoras importantes en el soporte de componentes clave como systemd, Wayland y CUPS, según cubrimos en la noticia de su lanzamiento.

Así pues, Debian 11.4 se proponer como el medio recomendado para quienes deseen realizar una nueva instalación del sistema, con una excepción, y es que tal y como señalan en el anuncio oficial, no es necesario deshacerse de las imágenes viejas para reemplazarla con esta nueva, ya que con realizar una actualización del sistema es más que suficiente para estar al día.

Y no hay mucho más que contar. ¿Te apetece subirte a Debian Bullseye? Aquí tienes el trampolín. Además, salvo que tus necesidades de contar con un kernel muy reciente sean un obstáculo -que se puede salvar de manera sencilla, aunque se le va parte de la gracia al sistema-, no te preocupes por las aplicaciones, que gracias a sistemas como Flatpak, Snap y otros lo tienes más fácil que nunca.

Te dejamos con la descarga de Debian 11.4 ‘Bullseye’ en el formato que más te interese:

  • DVD – Descarga directa: 32-bit, 64-bit | Torrent: 32-bit, 64-bit.
  • Medios en vivo – Descarga directa: 32-bit, 64-bit | Torrent: 32-bit, 64-bit.

Fuente: Muy Linux.

El aterrizaje de Rust en Linux podría producirse más temprano que tarde

publicado en: Linux | 0

La introducción de Rust en Linux es un tema que ha despertado gran interés, sobre todo porque es visto como una vía para modernizar el kernel en aspectos como el de la seguridad. En su momento Linus Torvalds mostró cierto escepticismo, pero la posición del creador del kernel ha ido evolucionando hacia una más receptiva, hasta el extremo de que la incorporación oficial de Rust podría estar cerca.

En la última Open Source Summit organizada por The Linux Foundation, Linus Torvalds mantuvo una charla pública con Dirk Hohndel, director de código abierto de Cardano. El creador de Linux siempre es noticia por lo que dice, ya sea por la polémica que genera o por mostrar la posible evolución del kernel en los próximos meses o años. En esta ocasión posiblemente lo más interesante hayan sido sus respuestas sobre la situación de Rust en Linux.

Sobre el lenguaje originario de Mozilla, que ahora opera de forma independiente, Linus Torvalds dijo que hay razones técnicas reales, como la seguridad de la memoria, por las que es bueno incorporar Rust al kernel. Y la gente ha estado trabajando mucho en ello. Así que realmente espero que funcione”. Esto comenzará con partes muy pequeñas y muy específicas del kernel. No estamos reescribiendo todo el kernel en Rust.

Las respuestas dadas por Torvalds se ajustan a las informaciones que hemos publicado con anterioridad. Ver Linux portado a Rust tiene pinta de ser una meta extremadamente difícil de lograr, más viendo que se trata de un componente compuesto por aproximadamente 30 millones de líneas de código. Por otro lado, Rust está dando poco a poco pequeños pasos que podrían situarlo en una posición importante dentro de Linux.

Dirk Hohndel también preguntó a Linus Torvalds sobre cómo irá el trabajo de los mantenedores con Rust, mencionando el reconocimiento de los patrones y la detección de las ideas tras los parches. El creador del kernel respondió lo siguiente: “No veo eso como un gran problema. Por ejemplo, en el subsistema de compilación, estoy acostumbrado a ver código Perl con macros, y son un desastre profano. Para mí, Perl es un lenguaje de solo escritura. Yo ni siquiera pretendo entender lo que está pasando, pero estoy perfectamente feliz de confiar en los mantenedores. Esa ha sido mi política durante mucho tiempo, que confío en que las personas harán lo correcto hasta que cometan errores”.

Aunque Torvalds sigue siendo el mandamás en el desarrollo del kernel, es obvio que no puede abarcar todo viendo su actual tamaño, así que es lógico que delegue en otras personas ciertas partes de la supervisión. Eso sí, él sigue teniendo la última palabra a la hora de dar el visto bueno a los cambios y a la publicación de nuevas versiones de Linux.

En la charla que mantuvo con Hohndel, Torvalds respondió que le resulta frustrante no poder confiar en la seguridad ofrecida por el hardware en alusión a los graves fallos que han ido apareciendo desde la publicación de Meltdown y la primera variante de Spectre. Aquí los desarrolladores del kernel tuvieron que hacer trabajo extra para corregir o mitigar fallos presentes en el silicio, aunque también dijo que “los tipos de problemas de seguridad que vemos en el lado del hardware se han vuelto más esotéricos a medida que pasa el tiempo”.

Otro aspecto mencionado es que la única preocupación apremiante que hay dentro del kernel suele ser la seguridad, a la vez que reconoció que, como ingeniero de software, nunca escribe documentación, y es que para Torvalds “la documentación es inútil en comparación con la realidad”.

El aterrizaje oficial de Rust podría producirse más temprano que tarde, más concretamente en Linux 5.20 según declaraciones de Linus Torvalds ante el veterano Steven Vaughan-Nichols: “Me gustaría ver la fusión de la infraestructura de Rust para comenzar en la próxima versión, pero ya veremos”.

Como vemos, la llegada de Rust a Linux empieza a tomar forma, pero eso no tiene por qué significar que vaya a llegar a la rama estable del kernel de forma inmediata, así que lo dejaremos en que es realista pensar que lo haga durante el transcurso de lo que resta de 2022.

Fuente: Muy Linux.

EndeavourOS ‘Artemis’ estrena instalador para ARM en fase beta

publicado en: Linux | 0

EndeavourOS ‘Artemis’ es la nueva imagen de instalación, que no versión, con la que este «facilitador» de Arch Linux se ofrece a todo aquel que esté pensando en subirse al carro de la distribución rolling-release por excelencia, pero sin complicarse ni un poco.

No es de extrañar, por lo tanto, que de un par de años a esta parte, EndeavourOS se haya convertido en una de las «distribuciones» más populares entre determinado tipo de usuarios, tal y como lo fue la desaparecida Antergos, a quien la presente ha tomado el relevo. Así, mientras que, una vez instalada, EndeavourOS es Arch Linux, es durante la instalación donde se marca la diferencia.

EndeavourOS, con nombre en clave Artemis en honor a la nueva misión de la NASA que tiene como objetivo volver a la Luna, es un lanzamiento regular de la distribución en el que se actualizan los paquetes que componen la imagen de instalación, y poco más, con una excepción importante, como es la integración del soporte de ARM.

En efecto, EndeavourOS ‘Artemis’ ya se puede instalar en dispositivos con arquitectura ARM a través del instalador de sistema oficial de la distribución, que no es otro que Calamares. Para más datos, se ha publicado un anuncio específico en el que se explican todos los detalles del proceso e implementación.

Cabe advertir, sin embargo, que el soporte de ARM en el nuevo instalador del sistema se encuentra en fase beta y por el momento solo ha sido probado en Raspberry PI y Odroid N2/N2+, por lo que conviene tenerlo en cuenta.

Otras novedades de EndeavourOS ‘Artemis’ incluyen actualizaciones importantes como la del instalador Calamares 3.2.60, el kernel Linux 5.18.5, X.Org 21.1.3, Mesa 22.1.2 o nvidia-dkms 515.48.07, aunque por su carácter de actualización continua, todo es instalar y esperar a que todo se vaya actualizando cuando corresponda.

Así, recuerda que si ya usas EndeavourOS no tienes que hacer nada, salvo instalar las actualizaciones que lleguen; pero si quieres instalar la distribución de cero, encontrarás las descargas de esta nueva versión en la página oficial del proyecto (escoge un servidor que te pille cerca para agilizar la descarga).

 

 

 

Fuente: Muy Linux.

CodeWhisperer, el rival de Amazon para GitHub Copilot

publicado en: Linux | 0

 

Amazon ha anunciado el lanzamiento de CodeWhisperer, una herramienta de asistencia para programadores apoyada en la inteligencia artificial. Si alguien está pensando en el reciente GitHub Copilot, no anda mal encaminado, ya que se trata de un rival directo que intenta aportar cosas propias y, al menos aparentemente, corregir uno de los aspectos más controvertidos de este tipo de herramientas.

CodeWhisperer, al igual que Copilot, está entrenada para asistir en la programación de lenguajes populares como Java, JavaScript y Python, apoyándose para ello en las miles de millones de líneas código disponibles de forma pública y en la propia base de Amazon, la documentación pública y el código publicado en foros.

Estando en fase previa como parte de la cadena de herramientas para IDE de Amazon Web Services (AWS IDE Toolkit), puede ser integrada en IDE y editores de código como IntelliJ IDEA, PyCharm, WebStorm, Visual Studio Code y AWS Cloud 9. En futuros lanzamiento se espera introducir el soporte para Lambda Console de AWS.

Entre sus características propias, la nueva herramienta de Amazon cuenta con CodeGuru, un revisor de código y perfilador de rendimiento apoyado en inteligencia artificial, además de DevOps Guru, una herramienta para encontrar problemas de operación con la que la compañía sentó las bases de CodeWhisperer. Al parecer fue probada por tan solo una pequeña cantidad de desarrolladores y de manera interna antes de su publicación oficial con el fin de mantenerla en secreto.

Uno de los aspectos más polémicos de Copilot fue el hecho de que podría estar violando derechos de autor e incumpliendo licencias de software, sobre todo la GPL, cuyas variantes más populares obligan a los desarrolladores a redistribuir el código de un producto derivado al menos bajo una licencia compatible. Que Copilot pueda tomar y sugerir código GPL que luego acabe en software privativo no es algo que haga mucha gracia, así que la Free Software Foundation no ha dudado en tomar cartas en el asunto y mostrar públicamente sus reservas.

Aquí parece que CodeWhisperer ha tomado una vía más transparente. Según Amazon, la mayoría del código que genera su nueva herramienta es nuevo, pero en caso de tomar un fragmento de otro, lo detectará y avisará de la licencia original, dejando bajo la responsabilidad del programador tomar o no dicho código. Esto debería, al menos en teoría, aclarar un poco más las cuestiones en torno a los derechos de autor y las ciertas licencias que exigen la redistribución del código, pero a saber cómo funciona el mecanismo a la hora de la verdad.

CodeWhisperer examina de manera constante el código generado por el programador y es presuntamente capaz de aprender de su estilo a la hora de escribir. Por otro lado, también debería de ser capaz de escanear y detectar problemas de seguridad en el código, además de que sobre el papel funciona bien para los programadores que trabajan fuera del ecosistema de AWS. Eso sí, el soporte para las API de AWS es first-class citizen, cosa normal viendo la procedencia de la herramienta.

Y aquí tenemos a CodeWhisperer. Veremos hasta dónde llegan estas herramientas de asistencia apoyadas en la inteligencia artificial, porque además de las suspicacias que despiertan en torno a los derechos de autor y ciertas licencias, está por ver en qué lugar acaban al final dentro de la programación.

Fuente: Muy Linux.

Ubuntu Software sigue siendo un desastre, un quiero y no puedo que lastra la experiencia de usuario

publicado en: Linux | 0

 

 

Alto. Calma. Respira hondo y termina de leer el artículo, que en el titular solo cabe la esencia condensada y tanto si te ha causado gracia, indiferencia o indignación, tiene su porqué. No todo es blanco o negro. De hecho, estoy usando de manera intermitente Ubuntu 22.04 LTS desde su lanzamiento y, salvo excepciones, me parece un gran lanzamiento: se ve fenomenal, va fenomenal… ¿Qué más se le puede pedir? Varias cosas, a decir verdad.

Pero no vengo ahora a entrar en todo lo que se puede pedir o dejar de pedir a Jammy Jellyfish. Ni siquiera me la instalé porque me apeteciera… o en realidad sí. Sin embargo, la apetencia pasa rápido por la incomodidad que supone estar usando un escritorio ajeno al habitual -tengo todo lo que necesito bien sincronizado, pero siempre falta algo- y lo que queda es el deber, que también se reparte en varios quehaceres.

Así, mientras que con unos días de uso me hubiese bastado para saciar mi curiosidad acerca de Ubuntu 22.04 LTS, la mantengo instalada, primero, para hacerme una idea sólida del estado de la que sigue siendo la distribución número uno de Linux en PC, al menos por el momento; y derivado de lo anterior, porque me sirve para actualizar los tutoriales que publicamos tras el lanzamiento de una nueva versión LTS de Ubuntu y que se han retrasado por el rediseño de MuyLinux, entre otras razones.

Esta, por el contrario, es una entrada de opinión que quizás no compartas, pero que tenía que sacar sí o sí. Y es que la medusa gelatinosa trae muchas cosas buenas, pero también algunas que no me han gustado nada y de todas con las que me he encontrado hasta la fecha, la gestión del software es la peor con diferencia. Y no, no va solo de Snap la historia, aunque tiene mucho que ver… a la fuerza, claro.

Es más, voy a dejar de opinar en los siguiente párrafos, para simplemente relatar la que, considero, es la peor experiencia con la gestión de software de cualquier otra versión de Ubuntu hasta la fecha. Al menos, que yo recuerde. Que alguien me corrija si me equivoco en algo.

Ahora sí, dejo ya de opinar y «comienzo a instalar Ubuntu 22.04 LTS»…

Como siempre, el proceso es rápido y sencillo; y, como siempre, lo primero nada más iniciar sesión por primera vez en el escritorio, es actualizar el sistema. ¿Usando el qué? Abriendo el menú de aplicaciones, hay dos que deberían servir: la típica de «Actualizaciones» y la tienda de aplicaciones de Ubuntu, o sea, Ubuntu Software, o sea, la Snap Store. Pero mejor me espero un poco a ver qué salta primero.

Y lo que salta primero es… el viejo asistente de «Actualizaciones», listo para cumplir con su labor con apenas un clic. Termina la actualización y me pide reiniciar. Reinicio y al volver a entrar en el escritorio, ejecuto de nuevo el mismo asistente para ver si queda algo por ahí. Y queda algo. Pero una vez actualizado, no me pide volver a reiniciar. Así que sigo con mis cosas. En concreto, abro la tienda de aplicaciones para instalar unas cuantas…

 Y me topo con que la pestaña de actualizaciones me indica que, sí, hay más actualizaciones esperando. ¿Cuáles? Las de los paquetes Snap: el de Firefox, el navegador web por defecto de Ubuntu; pero también el de la propia tienda de aplicaciones, la Snap Store, y las dependencias de ambos. Ignoro si de haber esperado más tiempo, Ubuntu Software hubiese ejecutado alguna notificaciones que me avisase, porque mantener el navegador actualizado me parece una tarea crítica.

En todo caso, es una gran chapuza que a estas alturas creía que ya estaría resuelta: ¿dos formas de actualizar, indispensables, independientes e incompatibles entre sí? ¿En serio? ¿Y esto lo hace el «Linux para seres humanos»? ¿De verdad? Pues tonto de mí, porque escribiendo estas líneas me acordaba de que algo así pasó también con Ubuntu 20.04 LTS, pero es que ni siquiera me refiero a lo mismo.

Da la casualidad -o tal vez no- de que, siempre en mi opinión, Ubuntu Software fue la gran chapuza de Ubuntu 20.04 LTS, una imposición inconsistente fundamentada en la apuesta que mantiene Canonical por implantar su servicio de distribución de software a cualquier coste, sea capaz de reemplazar con la calidad deseada la opción previa o no. Y no lo es. Al menos, por el momento.

Me quejaba en ese otro artículo de la falta de soporte de Flatpak, o de que Ubuntu Software priorizase las aplicaciones Snap por delante de las disponibles en los repositorios corrientes del sistema. Pero es que las inconsistencias son tan malas como esos «comportamientos». Porque, de hecho, sigue ocurriendo lo mismo: la prioridad en los paquetes ofrecidos es Snap y Flatpak ni está, ni se le espera.

Mientras que lo de priorizar su propio formato de paquetes se entiende sin explicarlo, de la ausencia de Flatpak se podría decir lo mismo, pero no, la postura oficial no se atreve a tanto, esto es, a renegar de su competencia más directa. Por el contrario, argumentos estúpidos es la única respuesta que hemos obtenido no ya de Canonical, sino de su mismísimo jefazo.

De hecho, si nos remontamos más atrás en el tiempo, recuerdo que Ubuntu Software comenzó su andadura como Snap sin siquiera ofrecer soporte para instalar aplicaciones en formato Deb, aunque lo arregló rápido.

Ni siquiera entro en errores como este

Lo que no se ha arreglado en este tiempo es lo demás. Así que podemos convenir en que aspectos como el priorizar Snap es algo razonable o cuando menos comprensible y que mi rechazo a este proceder es mera opinión. Pero que se nieguen a implementar soporte de Flatpak es una desventaja clara, porque le están negando a sus usuarios una abundante fuente de software; y lo de separar las actualizaciones en dos clientes es directamente aberrante, sobre todo para el recién llegado, uno de los públicos objetivos de Ubuntu.

Por si alguien se lo pregunta, yo no tengo nada en contra de Ubuntu o Snap per se, son todo crítica concretos que me parecen un sinsentido. Ya sabéis muchos que mi sistema de cabecera es KDE neon, que se basa en Ubuntu LTS, y va muy bien. En neon uso los repositorios corrientes de Ubuntu, varios PPA, Snap, Flatpak… y lo gestiono todo a través de Discover, actualizaciones incluidas. Da igual cuántas actualizaciones aparecen y de dónde vengan, porque con un clic lo soluciono.

¿Por qué Ubuntu no puede hacer lo mismo? Porque Canonical antepone sus intereses a los de sus usuarios. Así de simple. Porque igual que empaquetan prácticamente todo GNOME, podrían hacerlo con GNOME Software, donde es posible utilizar todas las fuentes de software en armonía… wait! ¡Que ya lo hacen! Ubuntu Software ya está incluido en los repositorios de Ubuntu, pero prefieren desarrollar y preinstalar Ubuntu Software porque… No sé por qué, más allá de las ansias de control o relevancia.

¿Quién se acuerda de los follones de Snap más allá de Ubuntu y de cómo Canonical se comprometió a mantener el soporte de Snap en GNOME Software? ¿Para qué lo hicieron? ¿Para que usuarios de otras distribuciones pudieran tener un fácil acceso a la Snap Store, pero negarles a los suyos el acceso a Flathub y demás fuentes de Flatpak? Luego se extrañarán de que por ahí no quieran saber nada de Snap, aunque no sea solo por eso, sino por su modelo centralizado.

Vuelvo a la cuestión que planteaba antes: ¿por qué Ubuntu ofrece dos formas de actualizar, indispensables, independientes e incompatibles entre sí? Es tal cual, ¿eh?: el asistente de actualizaciones y Ubuntu software se reparten las actualizaciones en formatos Deb y Snap, respectivamente, ambas contienen aplicaciones indispensables, que deben ser actualizadas cuanto antes mejor, y son incompatibles entre sí, porque lo que actualiza el uno, no lo puede actualizar el otro.

¿Es esto una chapuza o no lo es? Pero es que además es una chapuza a mala leche, cuando podrían solucionarlo reemplazando ese horror de Ubuntu Software con GNOME Software, que son absolutamente iguales, y matar dos pájaros de un tiro: una misma interfaz para actualizarlo todo, ponen Snap por defecto y dejan que Flatpak lo instalen los usuarios que lo conozcan. Todos contentos. Pero no, mejor que el usuario se coma una experiencia deficiente.

Por último, repito la pregunta cuya respuesta no he tenido la paciencia de esperar: ¿qué pasa si solo instalas las actualizaciones que aparecen en el asistente común? ¿Ubuntu Software lanza en algún momento una notificación o algo, si no entras no hay tutía? Lo menciono por lo ya mencionado, valga la redundancia: quien use Firefox, querrá tenerlo bien actualizado. Por seguridad, más que nada.

Por cierto, una aclaración: hablo todo el rato de Ubuntu Software, aunque también me refiero a ello como la Snap Store. Es lo mismo, en realidad. De cara al usuario se muestra como Ubuntu Software, pero el paquete se llama Snap Store, que es también como se llama la tienda global de Snap. Por si alguien se ha confundido.

GNOME Software también tiene lo suyo

A todo esto, uno de los tutoriales obligatorios será el de gestión de software, visto lo visto. la solución que más me ha agradado a mí es quitar de en medio a Ubuntu Software e instalar GNOME Software, así lo manejo todo desde ahí. Sin embargo, no deja de tener su aquel, porque aunque lo integra todo (Deb, Flatpak, Snap), su proceso de actualización es… muy pesado.

Ojo, porque esto también puede ser mi opinión, nada favorable con las actualizaciones fuera de línea o actualizaciones en diferido. Son más seguras, sí, pero me resultan un incordio total, tal y como lo conté cuando las adoptó Discover. Me las quitaba antes incluso de que se añadiera una opción para ello. No obstante, puede que haya quien las prefiera.

Dicho lo cual, que GNOME Software sea igualmente incapaz de actualizar todas las actualizaciones de una tacada, me deja frío. Que sí, puedes actualizar primero las que vengan en forma de Flatpak y Snap, pero luego tienes que volver a darle para el resto (ver los diferentes bloques en la imagen de más arriba). ¿Seriously?

 

 

Fuente: Muy Linux.