The Linux Foundation y edX han presentado los resultados de la última encuesta sobre el estado de la demanda de profesionales especializados en Open Source (que abarca sysdamins, DevOps, profesionales de la nube, desarrolladores, etc). En esta ocasión, porque ya hemos publicado sobre los resultados de años anteriores, han participado 200 directores de contratación técnica y 750 profesionales de código abierto.

La demanda de talento especializado en Open Source parece seguir al alza, ya que el 92% de los directores de contratación técnica respondieron que tienen problemas para encontrar talento suficiente y muchos de ellos han confesado tener problemas para retener el personal sénior de código abierto que ahora tiene contratado. Esto deja entrever no solo una alta demanda, sino también unos salarios altos para los trabajadores.

Otro dato interesante es que el 50% de los empleadores encuestados afirmaron que habían aumentado las contrataciones en el presente año 2021, lo que añade todavía más presión a las empresas a la hora de contratar talento relacionado con el código abierto. Dicho de otra forma, que la competencia entre las empresas para contratar trabajadores especializados en Open Source es feroz.

Profundizando en sectores específicos, parece que la demanda de DevOps para aplicaciones nativas en la nube ha aumentado. De hecho, las habilidades relacionadas con las aplicaciones nativas en la nube encabezan la lista de las más necesarias al haber respondido el 46% de los directores de contratación que buscan personas con conocimientos de Kubernetes. De la encuesta se desprende un cambio de tendencia al ser las habilidades sobre tecnologías en la nube y no específicamente Linux lo más demandado por los directores de contratación.

La demanda de talento de tecnologías de la nube se ha disparado de un año para otro, tanto que en este momento supera con claridad a Linux con un porcentaje del 41% frente al 32%. La fuerte demanda de personas con conocimientos de Kubernetes trae una consecuencia lógica: que dicha demanda está forzosamente ligada al talento y los conocimientos en torno a los contenedores.

La encuesta también muestra que los DevOps se han convertido en el estándar dentro del desarrollo de software, ya que el 88% de los profesionales respondieron que usan prácticas de DevOps en su puesto de trabajo, lo que supone un incremento del 50% en comparación con los resultados obtenidos hace 3 años.

Fuente: Muylinux

Las comparativas de rendimiento entre Linux y Windows son un viejo tema de debate que nos acompaña desde siempre. Más allá de que ambos son hasta cierto punto hijos de las bases que sentó Unix para el funcionamiento de los sistemas operativos modernos, resulta obvio que son tecnologías muy diferentes.

Michael Larabel, jefazo de Phoronix y principal desarrollador de la suite de benchmarks del mismo nombre, se ha molestado en comparar el rendimiento del futuro Ubuntu 21.10 con el de Windows 10 y la última compilación de Windows 11, que empezará a ser lanzado el 5 de octubre del presente año.

En lo que respecta al hardware empleado, la configuración básica está compuesta de un procesador AMD Ryzen 9 5900X, una NVIDIA GeForce RTX 3090 con 24GB de VRAM con el driver 471.68 en Windows y el driver 470.63.01 en Ubuntu, 16GB de RAM a 3.600MHz y unidades SSD de Western Digital para el almacenamiento, todo eso montado sobre una placa ASUS ROG Crosshair VIII Hero. En cuanto a software, es importante mencionar el uso de Linux 5.13.0-14-generic en Ubuntu 21.10. Avisamos que no vamos a reproducir los resultados de todas las pruebas, los cuales están disponibles desde la correspondiente entrada publicada en Phoronix.

La primera comparativa de la que nos hacemos es eco es la realizada con GravityMark 1.2 para medir el rendimiento con OpenGL y Vulkan en las resoluciones 1080p y 4K. En este caso Windows 11 se lleva la victoria en las cuatro pruebas quedando muy ligeramente por encima de su predecesor, mientras que Ubuntu se muestra algo rezagado, sobre todo cuando se usa Vulkan (recordamos que se han empleado los drivers privativos y oficiales de NVIDIA).

Fuente: Muylinux

A pesar de que el escritorio Linux ha mejorado mucho durante el transcurso de la década pasada, este todavía arrastra algunas carencias importantes frente a Windows, como la falta de soporte de HDR. Por suerte, esto podría cambiar en un futuro no muy lejano, ya que Red Hat ha anunciado que quiere contratar a un ingeniero para introducir el soporte de HDR en Fedora y RHEL.

En la oferta de trabajo se puede leer que “el equipo de ingeniería de Red Hat Workstation está buscando a un ingeniero de software sénior con experiencia para trabajar en el soporte de escritorio, el compositor y la GPU para formatos y pantallas de alto rango dinámico (HDR) para Linux. En este puesto, trabajará en el equipo de Habilitación de Tecnologías de Nueva Plataforma de Red Hat Enterprise Linux (RHEL), manteniendo y mejorando la pila de GPU dentro de RHEL y Fedora y contribuyendo al desarrollo upstream de gráficos”.

Obviamente, decir Red Hat y Fedora deja entrever otras cosas, como que el trabajo para soportar el HDR se centrará en el entorno de escritorio GNOME, porque como bien sabrán quienes siguen la actualidad de este mundillo, Red Hat, Fedora y GNOME forman el triángulo más popular del espectro de Linux.

Con un Xorg que fue sentenciado hace un año por Red Hat, otro punto que se puede extraer de la oferta es que el futuro soporte de HDR para GNOME se centrará en Wayland, protocolo que, pese a quien le pese, es el futuro del despliegue de gráficos en Linux. De hecho, en el apartado de responsabilidades se puede leer lo siguiente: “Contribuir a las mejoras de funciones y la corrección de errores en los principales subsistemas como el kernel de Linux, Wayland y GNOME para soportar la implementación de HDR en Linux”.

La implementación del soporte de HDR en Linux es un viejo sueño que, al menos con la pila estándar y Xorg, no se ha materializado. La situación no es en apariencia sencilla de solucionar debido a la disparidad que hay entre los componentes, que encima abarcan los distintos drivers existentes para las gráficas y la diversidad de los compositores. El hecho de que el uso pantallas HDR no esté muy extendido entre los desarrolladores de Open Source tampoco ayuda.

La complejidad que conlleva el soportar HDR llevó a los responsables de Wayland a proponer una biblioteca estandarizada para el análisis de los blobs de EDID (Datos de Identificación de Pantalla Extendidos), ya que cada compositor estaba soportando dicha característica de una forma diferente. El análisis de los blobs de EDID se está volviendo importante para características como el HDR y otras avanzadas relacionadas con el color.

Viendo las circunstancias que rodean a esta oferta de trabajo, todo hace indicar que Fedora será la primera distribución en tener soporte de HDR a través de GNOME, algo que a estas alturas ya no tendría que sorprender al ser la distribución comunitaria de Red Hat la gran impulsora de tecnologías ligadas a Linux.

Fuente: Muylinux

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