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’ 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.

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.

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.

macOS Ventura es la flamante versión del sistema operativo de Apple para PC y aunque no estará disponible hasta el próximo otoño, la compañía ya lo ha mostrado en sociedad y ha adelantado algunas de sus novedades, entre las que se cuenta el soporte para ejecutar aplicaciones de Linux.

La presentación de macOS Ventura se dio ayer, en el marco de la conferencia para desarrolladores WWDC 2022, que la que la firma de Cupertino aprovechó para enseñar lo próximo de otros de sus productos de cabecera, incluyendo los nuevos Macbook Pro y Macbook Air con los chips Apple M2, iOS y iPadOS 16 o watchOS 9, además del que nos ocupa, macOS 13, con nombre en clave macOS Ventura.

Pues bien. De las principales novedades de macOS Ventura dimos cuenta ayer en MC (también del resto de novedades que trajo la WWDC 2022: pincha en el enlace de más arriba para verlo todo), aunque justo la de la compatibilidad con aplicaciones de Linux, no estaba entre ellas. Cabe recordar que macOS Ventura se encuentra en fase beta y quedan muchas cosas por conocerse.

Sin embargo, según recogen en Phoronix macOS Ventura podrá ejecutar aplicaciones de Linux a través de Rosetta, el componente que desarrolló Apple para mantener la compatibilidad de las aplicaciones clásicas de macOS con los nuevos procesadores ARM de Apple Silicon. Mucho se ha habló de Rosetta al inicio de la transición, pero parece que Apple ha cumplido con unos mínimos y el invento ha cuajado.

Con macOS Ventura irán un paso más allá, utilizando el macOS Virtualization Framework para permitir la ejecución de binarios de Linux, sirviéndose para ello de máquinas virtuales de Linux basadas en ARM. La integración de Rosetta en este sentido se reducirá a eso, binarios o aplicaciones dentro del espacio de usuario, y no a distribuciones Linux al completo, al menos por ahora. ¿A qué nos suena esto?

En efecto, aunque hemos visto casos como el de ChromeOS con las aplicaciones de Linux, esto es diferente. No se trata de ampliar el ecosistema de aplicaciones de escritorio, que en macOS es bastante florido. Ofrecer la posibilidad de ejecutar aplicaciones de Linux en macOS Ventura tiene el mismo objetivo que Windows Subsystem for Linux: facilitarle la vida a los desarrolladores… ¿o alejar de ellos la tentación de pasarse a Linux para trabajar?

Sea como fuere, el cambio que propone Apple para macOS Ventura puede dar de que hablar, aunque ya hay quien le está poniendo peros al invento, no por la forma del mismo, sino por el fondo. Hector Martin publicaba ayer uno y dos hilos en Twitter hablando sobre el tema y esperando que la evolución de Rosetta no desincentive el trabajo en torno a los esfuerzos existentes para llevar Linux a Apple Silicon.

Según Martin, uno de esos desarrolladores encargados de llevar los M1 de Apple a Linux, así como uno de los responsables de Asahi Linux, la primera distribución Linux para Apple Silicon, hay dudas acerca de en qué tecnologías se apoya la nueva funcionalidad de Rosetta. Dudas que quizás se despejarán hoy, pues Apple tiene programada una charla en la que se tratará este asunto. Aparte está la documentación oficial de Rosetta.

También hay dudas, y estas son de diferente índole, en relación a los posibles problemas legales de usar Rosetta fuera de macOS Ventura y siguientes versiones, por lo que continuar con el trabajo previo de la comunidad en clave de código abierto alrededor de Apple Silicon, es esencial, sostiene Martin.

En qué quedará todo, lo veremos en un futuro. Mientras tanto ¿quién nos iba a decir que volveríamos a traer a macOS por estos lares? Con macOS Big Sur la excusa fue que el cambio de diseño creó tendencia; en esta ocasión, no obstante, la historia apunta hacia otros derroteros. A ver cuándo se invierte en nuestro -el de los usuarios de Linux- favor

O lo que es lo mismo, a ver cuándo podemos hablar de un avance sustancial de Darling, porque macOS tiene cantidad de aplicaciones exclusivas de gran nivel, muchas de las cuales no están disponibles ni siquiera para Windows. Darling, por cierto, es el equivalente a Wine, pero para ejecutar aplicaciones de Mac en Linux.

Fuente: Muy Linux.

GitHub Copilot es una de las tecnologías que más han dado que hablar en los últimos meses en el sector del desarrollo de software. Se trata de una inteligencia artificial creada con el fin de asistir a los programadores en su tarea y que durante un tiempo ha permanecido en fase de pruebas, pero que ahora está disponible, no de forma gratuita, para toda persona que emplee los siguientes editores e IDE: Visual Studio Code, Neovim, Visual Studio y JetBrains.

El uso de la inteligencia artificial está cada vez más extendido en el mundo tecnológico, con claro protagonismo de las grandes corporaciones o empresas que se encuentran debajo de estas, como es el caso de GitHub. El nombre de Copilot no deja mucho a la imaginación al exponer de forma clara que se trata de una tecnología que realiza la función “copiloto” para facilitar la tarea de escribir código a los programadores.

La empresa responsable ha dicho que, “con GitHub Copilot, por primera vez en la historia del software, los desarrolladores pueden aprovechar ampliamente la IA para escribir y completar el código. Al igual que el auge de los compiladores y el código abierto, creemos que la codificación asistida por IA cambiará fundamentalmente la naturaleza del desarrollo de software, brindando a los desarrolladores una nueva herramienta para escribir código de manera más fácil y rápida para que puedan ser más felices en sus vidas”.

GitHub Copilot ha sido diseñado específicamente como una extensión del editor para asistir al programador. Para ello “extrae el conocimiento colectivo de los desarrolladores de todo el mundo en una extensión de editor que sugiere código en tiempo real”, ayudando de esa manera al programador para que se mantenga centrado en la creación de “un software excelente”.

La inteligencia artificial que nos ocupa se encarga de realizar sugerencias para hacer que el código se ajuste al contexto y las convenciones de estilo del proyecto, abriendo la puerta a aplicar diversas opciones que pueden ser aceptadas, rechazadas o editadas. GitHub Copilot es capaz de sugerir métodos completos, código representativo, pruebas de unidades completas y algoritmos complejos. Todas esas capacidades no solo tendrían que ayudar a programadores expertos, sino también a la hora de adentrarse en lenguajes desconocidos o profundizar en aquellos que no se conocen en profundidad.

GitHub Copilot es capaz de asistir en la escritura de “docenas de lenguajes” de programación, entre los cuales están TypeScript, Google Go, Python, Ruby, Java y JavaScript. La empresa ha explicado que, con más de 1,2 millones de desarrolladores que participaron en el periodo de prueba, “las personas que comenzaron a usar GitHub Copilot rápidamente dijeron que se convirtió en una parte indispensable de sus flujos de trabajo diarios. En los archivos donde está habilitado, GitHub Copilot escribe casi el 40 % del código en lenguajes de codificación populares”.

Tras superar un periodo de pruebas de 60 días, hay que pagar 4 dólares al mes o 44 dólares al año por el plan Equipo (Team) o 21 dólares al mes o 231 dólares al año por el plan Empresarial (Enterprise). De manera alternativa los estudiantes y los mantenedores de populares proyectos publicados como código abierto pueden usarlo de forma gratuita, pero el acceso a este plan está restringido al cumplimiento de una serie de requisitos.

GitHub Copilot se basa en el modelo de inteligencia artificial OpenAI Codex, el cual está desarrollado por OpenAI y ha despertado la preocupación de la Free Software Foundation debido a que los fragmentos de código generados por Copilot y Codex podrían violar derechos de autor y los términos de la GPL a la hora de redistribuir trabajos derivados bajo una licencia equivalente.

La fundación encargada de definir y defender el software libre ha planteado posibles problemas sobre si la capacitación a través de repositorios públicos puede considerarse como uso justo o no, qué métodos tienen los desarrolladores para descubrir si su código ha sido reutilizado violando las licencias, si los modelos de aprendizaje automático capacitados son código fuente modificable o una compilación de datos de capacitación, además de si los modelos de aprendizaje automático podrían tener ellos mismos derechos de autor o a través de quién.

Sea como fuere, GitHub Copilot ya es oficialmente una realidad para los programadores. Parece que durante la fase de pruebas ha tenido bastante aceptación, pero veremos cómo funciona después de ser publicado oficialmente como producto y los posibles conflictos que puede generar con desarrolladores y licencias, sobre todo cuando se trata de proyectos publicados bajo las variantes más populares de la GPL.

Fuente: Muy Linux.

Manjaro 21.3 “Ruah” ha visto la luz como la última versión de la gran derivada de Arch Linux orientada a usuarios finales y que es además de una de las mejores opciones para jugar, sobre todo si se emplea el controvertido driver oficial de NVIDIA.

Lo primero que sobresale de Manjaro 21.3 es la inclusión de Calamares 3.2 como instalador del sistema, el cual ha mejorado el soporte de LUKS. Por otro lado, el módulo de los usuarios tiene listas de nombres de inicio de sesión y de hosts prohibidos con el fin de evitar las configuraciones que puedan romper el sistema.

En cuanto a las distintas ediciones con escritorio precocinado, empezamos con la que incluye KDE Plasma, posiblemente la mejor llevada si contamos la personalización por parte de los responsables de la distribución y la puesta a disposición de características de última generación. Aquí nos encontramos con la versión 5.24 del entorno con todas sus novedades y posibilidades. Aparte del acabado estético, en Manjaro realizan una implementación bastante limpia, así que sobresalen el asistente para KRunner, el lector de huellas digitales, la posibilidad de modificar el color de acento y unos paneles de escritorio más fáciles de mover.

La edición con GNOME incorpora la actualizada versión 42.2, que destaca por profundizar en el nuevo paradigma, mejorar el desempeño e introducir libadwaita, cuyo tema oscuro es empleado por defecto en Manjaro 21.3. Los responsables de la distribución reconocen que “GTK 4 y libadwaita ofrecen capacidades de próxima generación para aplicaciones GNOME, y muchas aplicaciones GNOME han comenzado a usar estos componentes para GNOME 42. Como resultado, estas aplicaciones tienen un mejor rendimiento, un nuevo estilo de interfaz de usuario moderno y nuevos elementos de interfaz de usuario”.

Por su parte, la edición original, la que incluye Xfce, trae la versión 4.16 del entorno junto a las tradicionales personalizaciones implementadas por la distribución para que luzca realmente bien. En este frente destacan las mejoras en la composición y el soporte de GLX, a lo que se suma como novedades el soporte de escalado fraccional para pantallas HiDPI, la posibilidad de agregar relaciones de aspecto junto a las resoluciones y un Thunar que ha recibido una cantidad destacada de mejoras.

 

Manjaro 21.3 “Ruah” ha visto la luz como la última versión de la gran derivada de Arch Linux orientada a usuarios finales y que es además de una de las mejores opciones para jugar, sobre todo si se emplea el controvertido driver oficial de NVIDIA.

Lo primero que sobresale de Manjaro 21.3 es la inclusión de Calamares 3.2 como instalador del sistema, el cual ha mejorado el soporte de LUKS. Por otro lado, el módulo de los usuarios tiene listas de nombres de inicio de sesión y de hosts prohibidos con el fin de evitar las configuraciones que puedan romper el sistema.

En cuanto a las distintas ediciones con escritorio precocinado, empezamos con la que incluye KDE Plasma, posiblemente la mejor llevada si contamos la personalización por parte de los responsables de la distribución y la puesta a disposición de características de última generación. Aquí nos encontramos con la versión 5.24 del entorno con todas sus novedades y posibilidades. Aparte del acabado estético, en Manjaro realizan una implementación bastante limpia, así que sobresalen el asistente para KRunner, el lector de huellas digitales, la posibilidad de modificar el color de acento y unos paneles de escritorio más fáciles de mover.

Manjaro 21.3 con KDE Plasma 5.24.

La edición con GNOME incorpora la actualizada versión 42.2, que destaca por profundizar en el nuevo paradigma, mejorar el desempeño e introducir libadwaita, cuyo tema oscuro es empleado por defecto en Manjaro 21.3. Los responsables de la distribución reconocen que “GTK 4 y libadwaita ofrecen capacidades de próxima generación para aplicaciones GNOME, y muchas aplicaciones GNOME han comenzado a usar estos componentes para GNOME 42. Como resultado, estas aplicaciones tienen un mejor rendimiento, un nuevo estilo de interfaz de usuario moderno y nuevos elementos de interfaz de usuario”.

Por su parte, la edición original, la que incluye Xfce, trae la versión 4.16 del entorno junto a las tradicionales personalizaciones implementadas por la distribución para que luzca realmente bien. En este frente destacan las mejoras en la composición y el soporte de GLX, a lo que se suma como novedades el soporte de escalado fraccional para pantallas HiDPI, la posibilidad de agregar relaciones de aspecto junto a las resoluciones y un Thunar que ha recibido una cantidad destacada de mejoras.

Manjaro 21.3 con GNOME 42.2.

A niveles generales y como componentes esenciales que comparten todas las ediciones para escritorio, nos encontramos con Linux 5.15 LTS como kernel predeterminado (recordamos que Manjaro dispone de una sencilla herramienta gráfica que facilita mucho su reemplazo), Mesa 22.1 para el soporte estándar de los drivers del espacio de usuario (las API OpenGL y Vulkan) y Pacman 6.0.1 y Pamac 10.4.1 para la gestión de los paquetes y las aplicaciones. Sin embargo, ninguno de esos detalles importa en exceso debido a que el sistema se actualiza constantemente.

Todos los detalles sobre Manjaro 21.3 están disponibles en el anuncio oficial, mientras que el sistema puede obtenerse a partir de la correspondiente sección de descargas del sitio web oficial del proyecto. Manjaro ha ido mejorando con el paso del tiempo para erigirse en toda una institución los sectores de escritorio y gaming dentro de Linux. Su desarrollo y evolución seguirá siendo uno de los temas de interés de nuestro particular mundillo.

Fuente: Muy Linux.

Thunderbird para Android empieza a ser una realidad, pero posiblemente no por la vía que muchos esperábamos. Sí, los responsables del archiconocido cliente de correo confirmaron que la versión de la aplicación estaba en camino, pero el camino elegido para su llegada está sorprendiendo a propios y extraños.

Thunderbird para Android fue confirmado de forma más bien espontánea, después de que Jason Evangelho, el conocido divulgador sobre Linux que desde hace poco es gerente del marketing de Thunderbird, preguntara a su compañero Ryan Lee Sipes a través de Twitter si había algo sobre la llegada la aplicación. Ahí fue cuando empezamos a tener constancia de su existencia de manera oficial.

Sin embargo, quedó en el aire la vía por la que llegaría. En su momento especulamos sobre la posibilidad de que se basara en Fenix, la tecnología empleada desde hace un tiempo por Firefox para Android, pero la realidad es que Mozilla ha maniobrado para adoptar K-9 Mail, un cliente de correo exclusivo para el sistema operativo móvil de Google.

K-9 Mail es un cliente de correo electrónico para Android publicado como código abierto bajo la licencia Apache 2. Al parecer la incorporación de K-9 Mail a la estructura de de Thunderbird ha sido proceso que ha estado cocinándose durante años, ya que Ryan Lee Sipes inició en 2018 conversaciones con Christian Ketterer, principal mantenedor de K-9 Mail, para llevar a cabo posibles colaboraciones. Y todo parece haber ido incluso mejor de lo esperado, porque Thunderbird para Android no solo se basará en K-9 Mail, sino que esa última aplicación ha pasado a formar parte de Thunderbird junto a Christian Ketterer.

Todo lo expuesto hasta aquí deja entrever que K-9 Mail será convertido en Thunderbird para Android en un futuro, pero el proceso, al menos según la información que hemos obtenido, no será de golpe, sino que irá poco a poco. Los responsables de Thunderbird dotarán de K-9 Mail de recursos tanto económicos como de desarrollo para que mejore a nivel de características y vaya alineándose mejor con las versiones de Thunderbid para escritorio tanto a nivel de funciones como de diseño. Viendo que la incorporación de la sincronización ha sido planeada para 2023, la cosa apunta a ir para largo.

En consecuencia, K-9 Mail seguirá estando disponible como tal para su descarga desde la Play Store de Google y F-Droid, pero los usuarios posiblemente empiecen a ver una evolución más acelerada a través de la incorporación de más características y cambios de diseño, hasta que después de un tiempo vean que la aplicación ya no se llama K-9 Mail, sino Thunderbird.

Christian Ketterer ha dicho que espera aportar su experiencia y sus conocimientos en el desarrollo para plataformas móviles, mientras que Ryan Lee Sipes ha dicho que K-9 Mail “se alinea perfectamente con los valores de Thunderbird de usar estándares abiertos, respetar al usuario y permitir a los usuarios avanzados una personalización inigualable”.

En el aire ha quedado un previsible cambio de licencia que veremos si se lleva a cabo. K-9 Mail, como ya hemos dicho, está publicado bajo la licencia Apache 2, pero Thunderbird emplea la MPL 2, una licencia propia de Mozilla. Lo lógico es pensar que en Thuderbird apuesten por la licencia de la corporación a la que pertenecen, pero a saber qué se está cocinando por dentro.

Para algunos posiblemente la llegada de Thunderbird a Android sea un motivo de alegría, pero por otro no deja de ser otra señal de que Mozilla ha sido muy lenta reaccionando a los cambios tecnológicos y en el mercado producidos durante la última década

Fuente: Muy Linux.

Flatseal 1.8 es la última versión del gestor de permisos para Flatpak, el cual permite establecer los recursos a los que pueden acceder las aplicaciones en ese formato tanto a nivel de sistema operativo como de ficheros a través de una configuración pormenorizada.

Sin hacer mucho ruido, Flatseal se ha erigido como uno de los grandes pilares de Flatpak y en todo un imprescindible en caso de tener una gran cantidad de aplicaciones en ese formato o ver que alguna no se comporta como quiere el usuario.

La versión 1.8 del gestor de permisos introduce una novedad importante: la capacidad de revisar y modificar las anulaciones globales (global overrides). Esto quiere decir que a partir de ahora Flatseal permite modificar las configuraciones que afectan al conjunto de las aplicaciones en formato Flatpak. Hasta ahora las anulaciones globales tenían que gestionarse desde la línea comandos, así que esta incorporación es muy importante para los usuarios sin profundos conocimientos de computación.

Otra novedad de Flatseal 1.8 es muy pequeñita, pero extremadamente útil, ya que el gestor de permisos indica ahora qué partes de la configuración predeterminada de una aplicación o las anulaciones globales han sido modificadas.

A veces el usuario puede encontrarse con que ha modificado un permiso y deja el asunto desatendido durante meses, por lo que no recuerda si esa es la configuración por defecto o si es fruto de alguna modificación. El pequeño aviso que ha sido introducido será de gran ayuda para esas personas que no están pendientes de los permisos que van modificando.

Otros cambios introducidos en Flatseal 1.8 son el soporte para los sistemas de colores y el cambio al entorno de ejecución (runtime) de GNOME 42. Se han corregido los problemas con los modos prohibidos en los permisos eliminados del sistema de ficheros y con la creación del directorio de anulaciones en distribuciones que no son Flatpak. La traducción al polaco ha sido corregida y se han añadido los idiomas búlgaro, danés y chino.

Y hasta aquí todo lo importante de Flatseal 1.8. Todos los detalles del lanzamiento están publicados en la lista de cambios y en la entrada publicada por Martín Abente Lahaye, creador y principal desarrollador del gestor, en los blogs de GNOME. La aplicación está disponible en Flathub y sí, oficialmente se distribuye en formato Flatpak.

Fuente: Muy Linux.