El desarrollo de KDE Plasma 6 va tomando forma y parece ir viento en popa, así que Nate Graham, uno de los desarrolladores más prominentes, ha anunciado que desde el proyecto han tomado la decisión de publicar la futura versión mayor del escritorio en febrero de 2024, aunque la fecha exacta todavía no ha sido determinada y es de esperar que dejen la puerta abierta a posibles retrasos.

Desde KDE esperan que los cinco meses que restan para llegar a febrero de 2024 sean suficientes para dejar Plasma 6 lo suficientemente pulido como para considerarlo un lanzamiento en fase estable.

Nate Graham ha expuesto las últimas tareas que se han completado durante el transcurso del último mes, las cuales han abarcado el reemplazo de PlasmaCore.SortFilterModel por KItemModels.KSortFilterProxyModel, el reemplazo de Kirigami.Avatar por KirigamiAddons.Avatar y KirigamiAddons.AvatarButton para facilitar el uso y mejorar el comportamiento de los avatares, la introducción de una columna lateral dedicada para los módulos de configuración en las Preferencias del Sistema, además de que los motores de datos (DataEngines) se han convertido en wrappers que envuelven otras funciones y han sido trasladados a un nuevo paquete llamado Plasma5Support.

En lo que respecta a características específicas, se ha introducido ordenación personalizada de los resultados de KRunner, un módulo de configuración de impresoras reescrito en QML, el uso del doble clic por defecto, el hacer clic al tocar sobre un touchpad y que los iconos de todo el escritorio provengan exclusivamente del tema de iconos seleccionado para todo el sistema.

Otras cosas que ya se encuentran implementadas son los informes automáticos en DrKonqi y un flujo de informes mejorado, el módulo de configuración de inicio automático muestra detalles sobre las entradas y las distribuciones pueden personalizar la primera página del centro de bienvenida.

Un punto a tener muy en cuenta y que puede condicionar el cumplimiento del calendario de lanzamiento para KDE Plasma 6 son los fallos de software. En la actualidad la cantidad de bugs abiertos es de 75, lo cual representa una disminución frente al máximo de 87 que se llegó a registrar hace tres semanas. Pero independientemente de la cantidad, no sería descabellado esperar unos meses adicionales para ver si los responsables corrigen errores que a buen seguro serán detectados tras la publicación oficial como estable.

En lo que respecta a KDE Gear, se menciona que la rama master estará abierta para que el código en Qt 6 llegue a aquellas aplicaciones que estén listas para hacer el cambio, aunque desde el proyecto se recalca que no es necesario portar todas las aplicaciones a la nueva versión del cimiento tecnológico. Por otro lado, el primer lanzamiento de KDE Gear para KDE Plasma 6 será retrasado dos meses para dar el tiempo necesario y probar los cambios iniciales de Qt 6.

Se planea lanzar una versión alfa de Frameworks, Plasma y Gear para noviembre de 2023 y las betas y candidatas de lanzamiento se producirían entre diciembre de 2023 y enero de 2024, todo con la intención de que los tres componentes estén listos para su publicación como estable para el lanzamiento oficial de KDE Plasma 6 en febrero del año que viene.

Por último, aprovechamos para recordar la competición de fondos de escritorio que fue anunciada hace unas semanas. El ganador será el establecido por defecto en KDE Plasma 6.0, el estreno de la sexta versión mayor del escritorio. La fecha límite es el 14 de noviembre de 2024 a las 23:59 UTC y las condiciones y normas pueden ser consultadas en el Discuss de KDE.

Y siguiendo la estela de Mageia 9, hace poco ha aparecido OpenMadriva ROME 23.08, la nueva imagen de instalación de la rama de lanzamiento continuo de la otra heredera de Mandriva. Para los que anden perdidos, ROME hace referencia a Rolling OpenMandriva Edition.

Como suele ser habitual en cada renovación de la imagen de instalación de un sistema de lanzamiento continuo, lo que sobresale es la puesta al día de los componentes suministrados. Sin embargo, los más importantes son el kernel Linux y Mesa para hacer funcionar el hardware más reciente, tal y como pasa en Arch Linux y distribuciones derivadas o con un enfoque similar.

OpenMadriva ROME 23.08 preinstala Linux 6.4.11 como kernel y Mesa 23.2.0 para los controladores del espacio de usuario (OpenGL, Vulkan y OpenCL), así que en teoría nos encontramos con un medio de instalación que tendría que poderse ejecutar incluso en computadoras recientes. La naturaleza rolling release del sistema debería garantizar la puesta al día de esos componentes para mejorar el soporte, por ejemplo, de las recientes gráficas Radeon RX 7000 de AMD.

Otros componentes presentes son el escritorio KDE Plasma 5.27.7, KDE Frameworks 5.109 y KDE Gear 23.04.3, aunque se espera actualizar a KDE Gear 23.08 dentro de poco. Las principales aplicaciones servidas de manera predeterminada son Chromium 116 con el soporte de JPEG XL habilitado, LibreOffice 7.6.0.3, Krita 5.1.5 y DigiKam 8.1. Los responsables mencionan que las últimas compilaciones de la suite ofimática cuentan con la integración para Qt 6, así que deberían de funcionar sobre el futuro Plasma 6 sin problemas.

Otros componentes presentes son neovim 0.9.1, glibc 2.38 y un soporte de Flatpak que ahora está activado por defecto con el objetivo de proporcionar una vía alternativa para la obtención de aplicaciones, ya que desde OpenMandriva no tienen pensado aflojar el pistón con la paquetería tradicional. Como marco del sistema se proporciona systemd 253.8 y para compilar en un principio está LLVM/Clang 16.0.6. Recordamos que esta distribución está compilada enteramente con LLVM/Clang y no con GCC.

En lo que respecta a medios alternativos, es posible instalar OpenMadriva ROME 23.08 con GNOME 44.3 o LXQT 1.3.0. También existe una imagen Plasma ‘Slim’ con un KDE Plasma 5 mínimo y otras centradas en servidores y sin interfaz gráfica de usuario, las cuales van dirigidas principalmente a dispositivos ARM64 como Raspberry Pi 4, Raspberry Pi 400, Rock 5B, Rock Pi 4 y servidores Ampere. El soporte para RISC-V está en fase de desarrollo.

Todos los detalles sobre OpenMadriva ROME 23.08 están publicados en el anuncio oficial y las notas de lanzamiento, mientras que la imagen de instalación, con sus distintas variantes, es posible obtenerla a partir de la sección de descargas que tiene dedicada en el sitio web de la distribución.v

Fuente: Muy Linux.

Blender 3.6 LTS es el último lanzamiento de la archiconocida solución de modelado y renderización de gráficos tridimensionales, la cual ha ido ganando terreno a lo largo de su trayectoria hasta ser empleada en producciones relevantes. Como ya hemos dicho, es una versión LTS, así que contará con dos años de soporte y además trae algunas novedades importantes relacionadas con el trazado de rayos y otros aspectos como los nodos.

Empezamos con lo que posiblemente resulte lo más familiar para el público general: el trazado de rayos. Blender 3.6 LTS ha introducido soporte para acelerar dicha característica en gráficas de AMD e Intel. Para la primera marca se ha introducido el soporte de trazado de rayos proporcionado por HIP, la API impulsada por el gigante rojo que permite la creación de aplicaciones portables compatibles con Radeon y NVIDIA. Sin embargo, es importante tener en cuenta que esto de momento solo funciona en Windows debido a que el soporte de trazado de rayos de HIP todavía no ha llegado a Linux y aún presenta ciertas limitaciones.

En lo que respecta al trazado de rayos para Intel, este ha llegado para las gráficas dedicadas Arc y para centros de datos usando Embree 4. Al igual que con Radeon, también hay limitaciones, ya que, “durante su primer uso con un dispositivo oneAPI, los nodos de oclusión ambiental y bisel activarán una compilación de binarios de GPU que usará alrededor de 9GB de memoria y llevará varios minutos. Las mejoras en esto pueden provenir de futuros controladores de GPU”.

Aquellos que sigan el sector de las gráficas dedicadas sabrán que NVIDIA tiene una clara ventaja sobre sus rivales cuando se trata de procesar el trazado de rayos mediante hardware. Esta, junto a otras tecnologías, le han permitido al gigante verde establecer una clara posición dominante en sectores como la inteligencia artificial, los videojuegos de última generación y el uso del propio Blender a nivel profesional.

En lo que respecta al soporte inicial para los nodos de simulación, que son definidos mediante la “zona de simulación” y permiten crear simulaciones con las que es posible interactuar en tiempo real con tan solo reproducir los movimientos creados y moviendo los objetos. Además, se han añadido un nuevo índice del nodo más cercano y algunas mejoras de rendimiento en los nodos de geometría.

Otro aspecto destacable de Blender 3.6 LTS es que la carga de geometrías grandes en Cycles es mucho más rápida, por lo que el renderizado puede empezar más rápidamente después de aplicar cambios de geometría o en la vista renderizada. Por otro lado, la característica de árbol de luz es ahora mucho más rápida gracias a la introducción de soporte de multiproceso y de instancias.

Como última gran novedad, porque abarcarlo todo daría para una enciclopedia, se puede destacar las mallas de base humana (Human Base Meshes), que facilitan el esculpir figuras humanas con características como niveles de resolución múltiples para activos realistas, topología cuádruple para esculpir en multirresolución, mapas UV, bordes arrugados y modificadores de subdivisión para activos planos, volúmenes cerrados para remallado de vóxeles y conjuntos de la cara.

Todos los detalles sobre Blender 3.6 están publicados en el anuncio oficial y las notas de lanzamiento, mientras que la aplicación puede ser obtenida desde la sección de descargas del sitio web oficial del proyecto. Para Linux también existen los instaladores Flatpak y Snap para aquellos usuarios que no están dispuestos a lidiar con las dependencias de su sistema. Os dejamos con un vídeo en el que exponen todas las nuevas características de este lanzamiento.

Fuente: Muy Linux.

Red Hat ha anunciado un cambio importante con respecto a la distribución del código fuente de Red Hat Enterprise Linux (RHEL), el referente del Linux corporativo en el que se basan unas cuantas alternativas bastante populares a día de hoy, aunque no lo sean con el beneplácito de la compañía de sombrero rojo. Sin embargo, la noticia que nos ocupa dista mucho de ser el «desastre» que algunos medios recogen.

Según publican en el blog de Red Hat, «CentOS Stream será ahora el único repositorio para versiones públicas de código fuente relacionadas con RHEL«. Esto es, se cierran definitivamente los repositorios públicos de CentOS en los que se alojaba el código fuente de RHEL, a partir del cual se compilaban los binarios utilizados por los denominados como «clones» de la distribución, de CentOS a Oracle Linux o las más nuevas AlmaLinux, Rocky Linux, etc.

Así las cosas, cualquier proyecto que desee acceder a un repositorio público con el código de Red Hat, tendrá como única opción el de CentOS Stream, la evolución del CentOS tradicional tras la muerte de este, un sistema de tipo rolling-release que ya no toma el código de RHEL, sino al revés, sirve como base tecnológica sobre la que desarrollar la distribución estable de Red Hat. Ergo, CentOS Stream no es un clon a nivel binario de RHEL y, en consecuencia, no puede generar clones como tales.

Con todo, se está poniendo el foco en la dificultad añadida al acceso al código de RHEL, que solo estará disponible a partir de ahora para los suscriptores (clientes y socios), cuando tal vez no debería ser así. Es decir, el código fuente de RHEL siempre ha estados disponible en el mismo sitio; lo que hacía Red Hat con CentOS, siendo esta una distribución gratuita, es colgar el código fuente de RHEL, una vez limpio del copyright, en los repositorios de CentOS. Esto es lo que se acaba.

Por lo tanto, la dificultar que se presenta para los derivados a nivel binario de RHEL no es el acceso al código fuente de la distribución, pues cualquier suscriptor -incluso en el modelo gratuito- lo tiene garantizado, sino el trabajo posterior que supone preparar todos los paquetes para su distribución por terceros. Es esto lo que puede ocasionar problemas para derivados de RHEL que dispongan de la mano de obra justa, sobre todo para seguirle el paso a los lanzamientos de Red Hat.

Habrá que ver, pues, cómo evoluciona esta historia, si bien Red Hat haría bien en no menospreciar el poder de la comunidad como hizo matando a CentOS. Por otro lado, es habitual entre las distribuciones corporativas o con planes empresariales (sin ir más lejos, SUSE y Ubuntu lo hacen de manera similar) el modelo de distribución limitado que adopta ahora Red Hat. No tenía sentido seguir publicando el código fuente de RHEL en un repositorio público de CentOS, cuando este está muerto.

// Actualización //

AlmaLinux, una de las derivadas de RHEL más proactivas, ha dado a conocer su punto de vista de la situación. En un artículo publicado en su blog amplían el contexto ofrecido por Red Hat. En primer lugar, garantizan el mantenimiento de todas las versiones en curso, aunque tengan que hacerlo a partir del código de CentOS Stream y Oracle Linux, con el trabajo adicional que ello conlleva (solo para la edición para servidores, la de escritorio ya la mantenían por su cuenta).

No obstante, descartan utilizar CentOS Stream como base por el motivo que señalábamos CentOS Stream no facilita la tarea. «Estamos comprometidos a seguir siendo un clon RHEL downstream y el uso de las fuentes CentOS Stream nos convertiría en el upstream de RHEL. Las fuentes de CentOS Stream, aunque son el upstream de RHEL, no siempre incluyen todos los parches y actualizaciones que se incluyen en los paquetes RHEL», explican.

Por último, responden a la pregunta que sobrevuela esta situación: ¿Está intentando Red Hat acabar con los clones de RHEL? «No podemos hablar de las intenciones de Red Hat, solo podemos señalar las cosas que han dicho públicamente. Hemos tenido una relación de trabajo increíble con Red Hat durante toda la trayectoria de AlmaLinux y esperamos ver que eso continúe», concluyen.

Fuente: Muy Linux.

Red Hat ha anunciado un cambio importante con respecto a la distribución del código fuente de Red Hat Enterprise Linux (RHEL), el referente del Linux corporativo en el que se basan unas cuantas alternativas bastante populares a día de hoy, aunque no lo sean con el beneplácito de la compañía de sombrero rojo. Sin embargo, la noticia que nos ocupa dista mucho de ser el «desastre» que algunos medios recogen.

Según publican en el blog de Red Hat, «CentOS Stream será ahora el único repositorio para versiones públicas de código fuente relacionadas con RHEL«. Esto es, se cierran definitivamente los repositorios públicos de CentOS en los que se alojaba el código fuente de RHEL, a partir del cual se compilaban los binarios utilizados por los denominados como «clones» de la distribución, de CentOS a Oracle Linux o las más nuevas AlmaLinux, Rocky Linux, etc.

Así las cosas, cualquier proyecto que desee acceder a un repositorio público con el código de Red Hat, tendrá como única opción el de CentOS Stream, la evolución del CentOS tradicional tras la muerte de este, un sistema de tipo rolling-release que ya no toma el código de RHEL, sino al revés, sirve como base tecnológica sobre la que desarrollar la distribución estable de Red Hat. Ergo, CentOS Stream no es un clon a nivel binario de RHEL y, en consecuencia, no puede generar clones como tales.

Con todo, se está poniendo el foco en la dificultad añadida al acceso al código de RHEL, que solo estará disponible a partir de ahora para los suscriptores (clientes y socios), cuando tal vez no debería ser así. Es decir, el código fuente de RHEL siempre ha estados disponible en el mismo sitio; lo que hacía Red Hat con CentOS, siendo esta una distribución gratuita, es colgar el código fuente de RHEL, una vez limpio del copyright, en los repositorios de CentOS. Esto es lo que se acaba.

Por lo tanto, la dificultar que se presenta para los derivados a nivel binario de RHEL no es el acceso al código fuente de la distribución, pues cualquier suscriptor -incluso en el modelo gratuito- lo tiene garantizado, sino el trabajo posterior que supone preparar todos los paquetes para su distribución por terceros. Es esto lo que puede ocasionar problemas para derivados de RHEL que dispongan de la mano de obra justa, sobre todo para seguirle el paso a los lanzamientos de Red Hat.

Habrá que ver, pues, cómo evoluciona esta historia, si bien Red Hat haría bien en no menospreciar el poder de la comunidad como hizo matando a CentOS. Por otro lado, es habitual entre las distribuciones corporativas o con planes empresariales (sin ir más lejos, SUSE y Ubuntu lo hacen de manera similar) el modelo de distribución limitado que adopta ahora Red Hat. No tenía sentido seguir publicando el código fuente de RHEL en un repositorio público de CentOS, cuando este está muerto.

Fuente: Muy Linux.

El soporte de HDR en Linux es un tema que poco a poco está preocupando cada vez más entre los desarrolladores de escritorios y compositores. Red Hat fue q​_uien abrió el melón con la intención de introducir la característica en la sesión de GNOME sobre Wayland, luego llegó Weston con su soporte inicial, el hackfest organizado por Red Hat y ahora es KDE quien empieza a mostrar sus planes para soportar el HDR.

Al igual que en los demás frentes, el plan es introducir el soporte de HDR en KDE a través de la sesión de Wayland proporcionada por el compositor Kwin. El último capítulo del recorrido para que Kwin tenga soporte de HDR ha sido narrado por Xaver Hugl, posiblemente la persona de KDE que más está contribuyendo a Wayland. De hecho, la introducción del “soporte de tearing” en el protocolo lleva su firma.

Xaver Hugl ha publicado en su blog personal una entrada llamada “HDR y gestión de color en Kwin”, en la cual ha explicado qué es el HDR y la gestión del color, el antiguo enfoque empleado por KDE para lidiar con los espectros de color y el nuevo enfoque q​_ue se pretende introducir con Wayland, muy posiblemente con las miras puestas en Plasma 6 viendo las fechas en las que estamos.

Ciñéndonos a los aspectos más importantes, ya que la entrada de Xaver Hugl es bastante extensa, el desarrollador explica que “el espacio de color más común se denomina ‘sRGB’ y lo utilizan la mayoría de los contenidos y pantallas.”

“Esta forma de manejar los colores es relativamente simple y útil, pero también presenta algunos problemas importantes. Las pantallas no se adhieren y a menudo no pueden adherirse al espacio de color sRGB. Debido a restricciones de fabricación, una pantalla puede tener un rojo un poco más ‘rojizo’, otra puede tener un azul menos ‘azulado’, por lo que el mismo contenido inevitablemente se verá diferente en distintas pantallas”.

Hugl señala que no es conveniente limitarse a sRGB debido a que, al final, solo es capaz de mostrar “un pequeño subconjunto de todos los colores visibles”, lo que puede derivar en algunos problemas como algunos colores que se ven sobresaturados o que el contenido creado para una pantalla capaz de mostrar un mayor rango de colores se vea mal. Con el fin de corregir eso, aquí es donde entra la gestión del color. Otro aspecto interesante es que “sRGB define un rango de brillo de 0 a 80 nits, que está muy por debajo de los miles de nits que pueden soportar algunas pantallas HDR”.

KDE Plasma 5 emplea colord para establecer un perfil de color ICC para una pantalla, que se encarga de “la colorimetría de la pantalla y contiene curvas de corrección de color que ajustan el balance de blancos y la función de transferencia electro-óptica (EOTF)”. Sobre X11, protocolo implementado en Xorg, esto funciona en pantallas que soportan un amplio espectro de color y con aplicaciones que usan el perfil, pero las aplicaciones que ignoran dicho perfil terminan por verse mal y además está limitado en la práctica a 8 bits por canal de color. Sí, Xorg puede usar 10 bits por canal de color, pero eso puede romper ciertas aplicaciones.

​_

Wayland, por su parte, puede ser usado sobre el papel de la misma manera, pero el protocolo no cuenta con ninguna API que permita emplear el perfil empleado por la pantalla, por lo que en consecuencia ninguna aplicación usa realmente el perfil. El resultado de esto es que, si se quiere usar una amplia gama de colores, no queda otra que usar X11, con todos los errores que arroja en la reproducción del color y su carencia de soporte para HDR.

Ante las limitaciones de X11, el nuevo enfoque introducido a través de Wayland es que el compositor haga las conversiones necesarias de forma automática para mostrar los colores correctamente cuando las aplicaciones etiquetan su contenido con un espectro de color y algunos metadatos adicionales, utilizando para ello shaders o apoyándose en la GPU. De esta manera se obtienen una mayor gama de colores y un mayor rango dinámico en las aplicaciones que los soportan, sin que el usuario tenga que preocuparse por esas otras aplicaciones que no lo hacen.

Xaver Hugl expone que Wayland todavía no está totalmente listo, pero reconoce que se han producido muchos avances a nivel del propio protocolo, el kernel y los compositores para modernizar la pila encargada del despliegue de los gráficos en Linux. Por otro lado, el hackfest de HDR organizado por Red Hat y celebrado el ciudad checa de Brno le ha permitido conocer a otras personas involucradas en ese tema y ha podido discutir sobre otros como la gestión del color y la tasa de refresco variable (Variable Refresh Rate o VRR).

Sobre la situación del HDR en Kwin, este todavía no se encuentra implementado realmente y su desarrollo parece estar en una fase muy inicial, pero como siempre con estas cosas, todo camino se empieza a recorrer dando el primer paso. El desarrollador explica que ha empezado a pulir el código de Kwin, ha corregido muchos efectos del compositor para que sean capaces de hacer las conversiones de color y ha introducido soporte básico para la gestión del color y HDR.

El soporte de HDR y el abarcar un mayor rango del espectro de color puede ayudar en aspectos como la experiencia con los videojuegos, con los contenidos multimedia e incluso a la hora de trabajar con aplicaciones como Krita, pero Hugl avisa que queda mucho trabajo por delante en Kwin para empezar a tener resultados reales, y a eso hay que sumar que tampoco se atreve a pronosticar cuando el protocolo Wayland estará plenamente listo.

El trabajo para dotar a Linux de soporte de HDR está en marcha, pero todo parece indicar que el camino, como siempre por estos lares, será recorrido con lentitud.

Fuente : Muy Linux.