Fuente: Muylinux

Ya tenemos entre nosotros a Java 17 (o más bien JDK 17), la última versión de la tecnología creada por Sun Microsystems y ahora propiedad de Oracle que ha dominado el sector de la computación durante buena parte del presente siglo. Esto significa que también está disponible OpenJDK 17, que es a fin de cuentas la base de la implementación comercial a pesar de los temores que surgieron en el año 2018.

Desde que Oracle decidió implementar la cadencia de seis meses, los lanzamientos de las nuevas versiones del JDK no incorporan tantas novedades como antes, pero eso no quiere decir que la versión 17 no traiga algunos cambios y novedades de interés, con macOS como la plataforma aparentemente más beneficiada.

Ya que hemos mencionado al sistema operativo de Apple para el escritorio, digamos qué ha traído Java 17 para él. En primer lugar nos encontramos con compilaciones oficiales para Apple Silicon, o lo que viene a ser lo mismo, el Apple M1 y otros modelos de procesadores del gigante de Cupertino basados en ARM. Apple siempre lo ha tenido más fácil que los demás para implementar grandes cambios, así que es de esperar que todas las aplicaciones y tecnologías relevantes lleguen a la arquitectura de procesadores propia de la compañía.

Siguiendo con macOS, el pipeline de renderización de gráficos ha pasado a hacer uso de Metal, la API gráfica propia y privativa de Apple, y se ha marcado como obsoleto el soporte de OpenGL. Esto es debido a que la corporación de la manzana mordida pretende eliminar el soporte de OpenGL de macOS, así que desde MuyLinux aprovechamos la ocasión para felicitarla, en sentido irónico, por su gran apuesta por las tecnologías abiertas y multiplataforma.

Otra novedad de JDK 17 es la restauración de la semántica de coma flotante siempre estricta, que permite realizar dichas operaciones consistentes “en lugar de tener tanto una semántica de punto flotante estricta (estrictafp) como una semántica de punto flotante predeterminada sutilmente diferente”. Por otro lado, los generadores de números pseudoaleatorios han sido mejorados mediante nuevos tipos de interfaces e implementaciones.

Hace quince años o más el uso de los applets de Java en los navegadores web era bastante común, pero con el paso de los años los navegadores empezaron a dejar de soportarlos por la cantidad de problemas de seguridad que acarrearon y a que sus funciones fueron cubiertas mediante HTML5, CSS3 y JavaScript. Java 17 ha puesto los cimientos para la eliminación definitiva de la API de los applets para la web.

Continuando con más novedades de Java 17, nos encontramos con el encapsulado fuerte de todos los elementos internos del JDK excepto algunas API críticas como ‘sun.misc.Unsafe’. El mecanismo de Invocación de Método Remoto (RMI) ha sido eliminado y se han incorporado clases e interfaces selladas para restringir qué otras clases o interfaces pueden extenderlas o implementarlas.

Se ha eliminado el compilador experimental de compilación anticipada (AOT) y compilación en tiempo de ejecución (JIT) debido a que no ha sido muy usado y su mantenimiento es costoso. Oracle ha recomendado conservar “la interfaz del compilador JVM experimental de nivel Java (JVMCI) para que los desarrolladores puedan seguir utilizando versiones del compilador creadas externamente para la compilación JIT”.

Otros cambios introducidos en JDK 17 son la consideración del gestor de seguridad (Security Manager) como obsoleto para preparar su eliminación y los filtros de deserialización específicos del contexto. En la primera fase de incubación nos encontramos con la API de memoria y función ajena, mientras que en segunda fase de incubación está la API de vectores “para expresar cálculos vectoriales que se compilan de manera confiable en tiempo de ejecución para obtener instrucciones vectoriales óptimas en arquitecturas de CPU compatibles, logrando así un rendimiento superior a los cálculos escalares equivalentes”.

Todos los detalles sobre Java 17 pueden ser consultados a partir de la correspondiente página en la web de OpenJDK. La versión software libre del JDK puede ser obtenida desde el sitio web de Java (alternativamente y extraoficialmente desde AdoptOpenJDK, sobre todo para los usuarios de Windows y macOS) y la comercial desde la web de Oracle. Recomendamos recurrir a OpenJDK en caso de tener dudas sobre las restricciones de la versión comercial.

Fuente: Muylinux

Como usuario, fan y defensor de Linux, he chocado muchas veces con la opinión de la comunidad. Uno de los principales puntos en los que suelo chocar con los demás es la experiencia con los gráficos, un aspecto que a la mayoría no le importa debido a que ha dado por buena una pila mediocre en la que la mayoría los drivers eran muy mejorables hasta hace poco y en la que el diseño de Xorg hace imposible la eliminación del tearing. Aquí es donde entra uno de los temas más candentes, Wayland, ya que el protocolo ha generado a su alrededor un agrio debate entre sus defensores y detractores.

Mi postura en torno a Wayland no es ningún secreto. Por un lado defiendo el protocolo porque me parece un avance en la dirección correcta en lo que respecta al despliegue de gráficos en GNU/Linux. Una vez se haya asentado, la pila será más simple al encargarse el compositor de muchas de las funciones de Xorg (Wayland es un protocolo que se implementa en el compositor).

Por otro lado es obvio que el diseño de Wayland se ha quedado corto en muchos aspectos, haciendo que sea difícil de implementar y trabajar y que se haya necesitado de soluciones externas para mitigar algunas de sus carencias, destacando aquí PipeWire.

KDE Plasma Vs GNOME en Wayland: Proyección frente consolidación

En lo que respecta a mi uso personal, Wayland se ha convertido en una de las razones de por qué mi distrohopping ha bajado muchos enteros. Desde hace tiempo uso Fedora Workstation, que destaca por el uso de GNOME en su configuración base y es uno de los sistemas de referencia del entorno.

No es ningún secreto que la sesión de Wayland sobre GNOME es la implementación más avanzada del protocolo vista en un escritorio, pero eso podría cambiar dentro de poco, lo que ha hecho que me pregunte si debería de volver a KDE Plasma.

Cierto es que la implementación de Wayland en Mutter (el compositor de GNOME) sigue estando más pulida que la de Kwin, pero es innegable que en este 2021 el compositor de KDE Plasma ha metido turbo a su adaptación del protocolo, lo que ha llamado poderosamente mi atención porque a mí lo que me encandila del mundo de la tecnología no es lo que existe, sino aquello que atesora un enorme potencial que a veces no todo el mundo ve. Esto ya lo viví en su momento con AMDGPU y lo vivo ahora con las gráficas dedicadas de Intel y la proyección de Wayland en Kwin.

La meteórica proyección de Wayland en KDE durante el presente año no solo se ha traducido en una mejora en la experiencia de usuario, sino también en características que están siendo implementadas antes en Kwin que en Mutter. Por ejemplo, la sesión sobre Wayland de KDE Plasma ya soporta FreeSync/tasa de refresco variable, mientras que el código para hacer lo mismo en GNOME todavía no ha sido fusionado.

Si bien la implementación de Wayland en Mutter sigue estando más pulida, el escenario podría cambiar radicalmente una vez que Kwin haya conseguido ponerse a la altura en ese sentido, ya que nos podríamos encontrar con que el compositor de KDE Plasma es más avanzado en cuanto a características.

Mi pesadilla con DMA-BUF en GNOME

Soy un asiduo usuario de Wayland. De hecho, uso Wayland para absolutamente todo menos la grabación de gameplays, cosa que no puedo hacer debido a que el soporte de DMA-BUF para Radeon no está consolidado en GNOME y a una regresión que afecta específicamente a Fedora 34 Workstation.

El tema de la implementación de DMA-BUF para Radeon en GNOME es algo que me tiene un poco quemado al ser una característica necesaria para la grabación de gameplays y otros contenidos que funcionan a pantalla completa. Debido a que el soporte todavía no está estable para Radeon, me veo obligado a hacer dichas grabaciones desde Xorg, y es una pena porque, como ya he dicho en otras ocasiones, es lo único que impide mi migración total (sí, hasta juego desde la sesión de Wayland).

De hecho, el uso de DMA-BUF es lo que despierta mi interés por las gráficas dedicadas de Intel, ya que el soporte de dicho búfer para esas GPU fue consolidado en GNOME 3.38. Por otro lado, GNOME 41 está a la vuelta de la esquina y el problema con Radeon sigue presente y no pinta que vaya a ser resuelto a corto plazo.

GNOME Vs KDE Plasma Vs gráficas dedicadas de Intel: ¡La carrera de los ratones!

A estas alturas creo que ha quedado claro que la posibilidad de que vuelva a KDE Plasma dependen de DMA-BUF y las posibilidades de grabar desde Wayland. No voy a negar que cada vez que veo “more Wayland patches” o algo similar en las noticias sobre KDE Plasma se me ponen los dientes largos, y es que la proyección de Wayland en Kwin está siendo tan grande que el año que viene podríamos ver un vuelco en su competencia con Mutter.

He convertido a las gráficas dedicadas de Intel, a GNOME y a KDE Plasma en tres involuntarios competidores de una carrera para ver qué paso doy. Las gráficas dedicadas de Intel tienen la ventaja de garantizarme el buen soporte de Wayland (si Intel cumple las expectativas a nivel de drivers) y me harían ganar un soporte decente para la codificación por hardware, pero tienen el inconveniente de tener que tirar de la tarjeta de débito. GNOME sigue por ahí, y salvo el punto mencionado, su sesión de Wayland es bastante usable, pero su principal fuerte son sus aplicaciones para la organización personal, las cuales me son muy difíciles de sustituir. Por su parte, KDE Plasma tiene a su favor el empuje de Wayland en Kwin, pero habrá que ver si es capaz de cumplir con mis exigencias.

Veremos cómo termina esto, pero viendo cómo se las están gastando los mineros, me temo que el resultado será arriesgarme con la compra de una gráfica dedicada de Intel de salida, a pesar de que ANV, el driver de Vulkan para Intel incluido en Mesa, pinta que no estará del todo listo para la ejecución de videojuegos desde Linux cuando llegue el momento.

Pese a todo, mi posible regreso a KDE Plasma no sería a corto plazo, sino que será algo que me plantee cuando KDE neon haya migrado a la base de Ubuntu 22.04 LTS, con Manjaro KDE y el spin de Fedora con KDE como los otros aspirantes a gobernar mis ordenadores.

Hay pocas distribuciones Linux que den este tipo de sorpresas y Manjaro es una de ellas. Hablamos de cambiar los defaults habituales, por lo general tótems del software libre, por alternativas más discutibles e incluso privativas, como es el caso que nos ocupa: Manjaro Cinnamon pone a Vivaldi como navegador web predeterminado y aunque no deja de ser una anécdota por la nula importancia de este sabor concreto…

En efecto, es una decisión polémica por lo que supone: reemplazar software libre por software privativo, cuando no es algo imprescindible. Como sabéis, es muy común que las distribuciones Linux incluyan complementos privativos para ofrecer la funcionalidad básica o deseada, es decir, tanto para que determinados componentes de hardware funcionen, como para que lo hagan con las mejores garantías. Esto se hace por lo general a través de controladores.

Pero también es común que las grandes distros Linux faciliten la instalación de aplicaciones privativas populares, como Steam, Spotify, VSCode u otras tantas. Lo que resulta del todo inusual es encontrarse con una distribución que preinstale alguna de estas aplicaciones, mucho menos con una que reemplace una aplicación de software libre con una de software privativo, cuando la libre cumple con una exigencias de calidad contratadas.

El por qué se actúa así, es obvio: la mayoría de las grandes distribuciones aspiran a ofrecer solo software libre, pero anteponen la experiencia de usuario y por eso preinstalan o facilitan la instalación de software privativo. No lo hacen por gusto. Y luego está Manjaro.

Como recordaréis, Manjaro ya tuvo su polémica con este asunto hace un par de años, cuando cerró un acuerdo con FreeOffice para incluir su suite ofimática como opción por defecto. FreeOffice es una interesante alternativa a LibreOffice con una mejor compatibilidad con Microsoft Office, pero atendiendo a criterios como calidad y libertad, el cambio no tenía sentido. Manjaro lo hizo por dinero, pero el escándalo fue tal que terminaron reculando y dejando elegir al usuario qué usar durante el proceso de instalación.

Pues bien, si el cambio de LibreOffice por FreeOffice fue controvertido, el de Firefox por Vivaldi no lo es menos, habida cuenta de que se tropieza con la misma piedra: cambiar software libre por privativo, cuando el libre cumple con su función con todas las garantías. De hecho, el caso de Firefox es más sangrante, pues a diferencia del plus que supone ofrecer una mejor compatibilidad con Microsoft Office, con los navegadores no se da esa ventaja.

O sea, es cierto que los navegadores basados en Chromium ofrecen un mejor rendimiento que Firefox, y que su compatibilidad con los sitios de Google puede ser mejor, pero no se justifica en el mismo grado el cambio. Y no solo eso: a diferencia de lo sucedido con FreeOffice, Vivaldi no ha pagado nada -o no lo han dicho, aunque tampoco parece el caso- y el cambio se da únicamente en Manjaro Cinnamon, una de las ediciones comunitarias de la distribución, y no en las oficiales.

Por lo que cuentan en el blog de Vivaldi, donde le han dado más importancia de la que cabría esperar a este tema, Manjaro ya ofrece en sus repositorios a Vivaldi, además, con un tema personalizado incluido para que su integración con el escritorio sea óptima; y ahora dan el paso en Manjaro Cinnamon para hacer de este la opción predeterminada (en los comentarios de ese artículo se cuenta que FerenOS fue la primera distribución Linux en poner a Vivaldi como navegador por defecto).

¿Qué os parece la noticia?

A mí, como usuario de Vivaldi, no me gusta. Si quiero Vivaldi me lo instalo yo, pero no me metas software privativo en la imagen de instalación a menos que sea imprescindible, que no lo es. Y si reniegas de Firefox, que razones hay unas cuantas para hacerlo, vete por una alternativa libre, como son Chromium o Brave. Que sí, que Vivaldi está muy chulo, es fiable y tal, pero no es de código abierto y no hay excusas que valgan, por más que se crean que sí las hay.

Fuente: Muylinux

La implementación de Wayland por parte de NVIDIA ha sido una de las mayores batallas tecnológicas que se hayan visto en Linux. El gigante del procesamiento gráfico no daba su brazo a torcer al mantener su apuesta por EGLStreams como búfer para Wayland, mientras que el resto, incluidos Intel y AMD, apostaron por el estándar GBM.

Después de muchos años de tiras y aflojas, el futuro regreso de Intel al mercado de las gráficas dedicadas, la precipitada defunción de Xorg y sobre todo el fracaso del propio EGLStreams forzaron a NVIDIA a rectificar para adoptar GBM, más viendo las altas probabilidades de que Wayland sea establecido por defecto en la próxima LTS de Ubuntu.

NVIDIA todavía tiene trabajo por delante para ponerse al día con su soporte de Wayland, que en teoría debería de permitir que su driver oficial funcione correctamente con las sesiones de Wayland ya existentes, sin necesidad de introducir modificaciones en los compositores (o al menos no tan radicales como los que requería EGLStreams).

James Jones, ingeniero de NVIDIA, ha anunciado que el driver de la compañía ya funciona por defecto en Sway usando GBM. La consecución de este hito ha necesitado de introducir las funciones de ‘gbm_bo_create_with_modifiers2’ y de ‘gbm_surface_create_with_modifiers2’ en el backend de GBM de Mesa debido a que las funciones de ‘gbm_*_create_with_modifiers’ carecían de soporte para flags.

Sway es un gestor de ventanas y compositor de Wayland inspirado en i3 que decidió en el lanzamiento de su versión 1.0 abandonar el soporte de EGLStreams. Drew DeVault, creador de Sway, repitió una archiconocida frase de Linus Torvalds y anunció que el compositor dejaría de soportar el driver oficial de NVIDIA. Por otro lado, el compositor es uno de los mejores exponentes de Wayland, y hay quien lo considera como la mejor implementación del protocolo.

La claudicación de NVIDIA ante los estándares de Wayland ha necesitado de introducir en Mesa un backend alternativo de GBM para soportar el driver de la compañía, que actualmente también se encuentra trabajando en el soporte de DMA-BUF y en otras mejoras relacionadas con Wayland.

La versión 470 del driver del gigante verde ha puesto los cimientos para soportar Wayland, pero hay otros componentes que deben ser parcheados para que todo funcione como se espera (o sea, con las sesiones de Wayland existentes).

NVIDIA, a la caza de Radeon

NVIDIA siempre ha tenido muchos intereses en torno a Linux, pero estos siempre han estado ligados a los servidores, la supercomputación y la inteligencia artificial. Mientras tanto, y hasta hace poco, la corporación no veía a Linux como un sistema de escritorio que pudiese ser usado como Windows y macOS, pero parece que eso está empezando a cambiar, ya que, aparte del soporte de Wayland, la llegada de DLSS a Proton fue la respuesta al anuncio de FidelityFX Super Resolution (FSR).

El soporte de DMA-BUF es uno de los aspectos más interesantes debido a que dicha característica es imprescindible para la grabación de gameplays desde una sesión de Wayland. De momento todo apunta a que no va a estar habilitada por defecto en GNOME 41 para las gráficas Radeon, por lo que se mantendría oficialmente como algo exclusivo de Intel. NVIDIA tiene ahí un frente para explotar una debilidad típica de Radeon que también se da en Windows: las tecnologías asociadas o relacionadas.

Las gráficas Radeon ofrecen una “potencia bruta” comparable a la de NVIDIA, incluso en Linux, pero cuando se trata de tecnologías, NVIDIA siempre va al menos un paso por delante. Las soluciones de codificación por hardware de NVIDIA para Linux son muy superiores a las de AMD, con DLSS y en trazado de rayos el gigante verde parece ir una generación por delante de FSR y la implementación del trazado de rayos de Radeon, y así sucesivamente.

El hecho de que NVIDIA vaya por delante en tecnologías es un buen punto a su favor, por lo que después de que se haya amoldado a los estándares de Wayland y tras sumarse Intel al mercado de las gráficas dedicadas, es muy probable que veamos a Radeon volviendo a ocupar el tercer puesto, aunque en unas circunstancias muchísimo mejores que las que había en los tiempos de Catalyst/FGLRX.

Fuente: Muylinux