Krita 5.2 ya ha sido anunciada como la nueva versión estable de la conocida aplicación de dibujo, la cual se ha convertido en uno de los grandes orgullos del software libre al haber conseguido tener cierta repercusión real dentro de su sector. Antes parte de la suite ofimática Calligra, sigue estando vinculada al proyecto KDE, aunque su desarrollo se realiza de manera independiente.

Krita 5.2 no es un lanzamiento tan rompedor como en anteriores ocasiones, y eso es debido a que los responsables han reconocido que han preferido “centrarse en abordar algunos de los mayores puntos débiles”. Dicho con otras palabras, el desarrollo de la nueva versión ha estado más centrada en mejorar y menos en introducir cosas novedosas.

Como primera novedad interesante nos encontramos con la reproducción sincronizada del audio y la simplificación de la exportación de vídeo. Para solucionar ciertos problemas de sincronización detectados, dos desarrolladores han rehecho gran parte de la reproducción de la animación para hacer uso del marco o framework MLT detrás de la escena.

MLT es un marco flexible y muy probado empleado por editores de vídeo como Kdenlive y Shotcut y está diseñado para tener en cuenta la sincronización cuadro a cuadro, lo que debería ayudar a los animadores que trabajan con Krita a la hora de sentirse seguros de que sus cuadros clave (keyframes) permanezcan alineados con la voz o la música, tanto dentro del proyecto como en el material exportado.

Con el fin de facilitar las cosas a los usuarios con menos conocimientos, Krita 5.2 incluye ahora una compilación básica de ffmpeg para soportar funciones relacionadas con el vídeo. Las anteriores versiones de la aplicación requerían de señalar manualmente un ejecutable funciona de ffmpeg, y si bien esto puede ser suficiente para un uso profesional, los usuarios con menos conocimientos pueden encontrarse ahí con un obstáculo importante. Eso sí, este soporte no funciona por ahora en Android.

El motor de diseño de texto de ha sido rehecho por completo para dar a los artistas un mayor control sobre el texto subyacente. Este nuevo motor soporta las mismas posibilidades que el anterior y permite acceder las funciones de OpenType y renderizar emojis. Obviamente, también hay texto en ruta, texto vertical, texto ajustado y texto en forma.

En lo que respecta a las herramientas, Krita 5.2 ha incluido un deshacer acumulativo revisado que permite fusionar operaciones de deshacer, los cual puede ser útil a la hora de pintar muchos trazos. La herramienta de relleno tiene un nuevo modo para rellenar áreas de color similar y la misma herramienta y la de relleno adjunto han ganado las posibilidades de “dejar de crecer en los píxeles más oscuros y/o opacos”, “rellenar todas las regiones hasta un color de límite específico” y una opción para usar el mismo modo de fusión que la herramienta de pincel o el suyo propio.

La herramienta de selección contigua también ha recibido la misma opción de ampliación de selección que la herramienta de relleno y la capacidad de establecer la opacidad de la decoración de la selección. Esto se suma al hecho de que la herramienta de decoración es consciente del DPI.

En lo que respecta a los elementos acoplables, hay uno nuevo llamado “Selector de color de amplia gama” que es similar al “Selector de color avanzado” ya presente, pero que permite seleccionar colores de gamas más amplias en lugar de solo sRGB. Los responsables anuncian que el actual selector avanzado será eliminado en un futuro. Otro acoplable que merece ser mencionado es el de pinceles, cuyo historial es ahora configurable.

A nivel de formatos, se ha cambiado la forma de funcionar de los modos de fusión de CMYK para que se alinee con la forma en que Photoshop maneja los modos de fusión en CMYK, simplificando así el intercambio de archivos PSD con clientes que requieren de PSD CMYK. Por otro lado, el soporte JPEG-XL tiene ahora una mejor compresión para brindarle a la biblioteca JXL más información sobre el espacio de color, un mejor manejo de los metatados, soporte para guardar y cargar capas rasterizadas y tiene implementado CMYK. Por otro lado, en WebP se ha mejorado la compresión y el código de características de transferencia ICC.

Fuente: Muy Linux.

Mesa 23.2 ya está disponible como la nueva versión estable de la pila encargada de proporcionar los drivers del espacio de usuario, los que soportan las API gráficas OpenGL, Vulkan y OpenCL. En esta ocasión, y posiblemente sin que sea una sorpresa a estas alturas, RADV se lleva el protagonismo al haber incorporado nuevas extensiones de Vulkan y correcciones de calado.

Ya que lo hemos mencionado, comenzamos con RADV, el driver comunitario de Vulkan para gráficas Radeon que es desarrollado principalmente por Valve con las miras puestas en la Steam Deck, aunque a la hora de la verdad las novedades y mejoras introducidas benefician a una gran variedad de modelos de gráficas de AMD.

Las extensiones incorporadas a RADV son VK_EXT_attachment_feedback_loop_dynamic_state, VK_EXT_dynamic_rendering_unused_attachments, VK_EXT_depth_bias_control, VK_EXT_pipeline_robustness, VK_EXT_fragment_shader_interlock en las gráficas GFX9, además de VK_KHR_fragment_shader_barycentric y VK_KHR_ray_tracing_pipeline en las gráficas RDNA 2. La última extensión mencionada es para el soporte trazado de rayos, que a partir de este lanzamiento debería de estar habilitado por defecto.

Además de algo tan áspero como las extensiones de Vulkan, RADV también ha incorporado en Mesa 23.2 correcciones para juegos y situaciones específicas, como una fuga de memoria en Dead by Daylight, una corrección para las sombras teñidas de rojo y rosa en Overwatch 2 cuando se usa una RTX 7900 XTX, artefactos detectados en Quake II RTX, colores distorsionados a la hora de usar el trazado de rayos en Cyberpunk 2077, un fallo de texturas con ACO en World War Z, una regresión en Unreal Engine 5.2 en las explosiones que se apoyan en Nanite con Direct3D 12, cuelgues a la hora de usar trazado de rayos en Elden Ring y problemas de artefactos al ejecutar Rise of the Tomb Raider sobre una GPU RDNA 3.

La segunda novedad más importantes de este lanzamiento es el soporte OpenGL 3.1 y OpenGL ES 3.0 sobre Asahi, o sea, el soporte de Linux desarrollado para hacer funcionar el sistema de código abierto sobre los procesadores de Apple basados en ARM y destinados a sus ordenadores personales (Apple Silicon).

El soporte de OpenGL servirá para soportar un escritorio y ciertas características aplicaciones, pero los responsables de Asahi Linux no deberían de demorarse demasiado a la hora de investigar cómo incluir soporte de Vulkan, una API que sigue sin ser el estándar del escritorio Linux, pero que poco a poco va avanzando y que en videojuegos ya se ha consolidado como la base.

Y aunque Intel no está siendo especialmente diligente a la hora de ponerle las pilas, no viene mal echar un vistazo a ANV, su driver de Vulkan oficial para Mesa. En este frente nos encontramos con correcciones para el videojuego The Spirit and The Mouse al ejecutarlo con una gráfica Arc A770, otra corrección para ChromeOS procedente de Google, para cuelgues detectados en Death Stranding, cuelgues de la GPU a la hora de hacer pruebas de MSAA con Angle, el trazado de rayos sobre las gráficas Arc A750 y Arc A770, un fallo de compilación para ARM64, una caída en el lanzamiento de Tom Clancy’s Rainbow Six Siege y un cuelgue de la GPU con Overwatch 2 si Graphics Pipeline Library (GPL) está habilitado.

Es importante tener en cuenta que ANV está muy verde todavía, así que usar una gráfica dedicada de Intel para videojuegos no es una buena idea en estos momentos. Parece que la compañía ha empezado a ponerse las pilas para mejorar su driver, pero todo apunta a que habrá que esperar muchos meses hasta tener resultados tangibles.

Mesa 23.2 encierra mucho más en su interior, como la posibilidad de compilar RadeonSI, el driver oficial de OpenGL para AMD Radeon, con ACO empleando el sistema de compilación Meson. También hay muchas correcciones y mejoras para freedreno, que es de OpenGL, está construido con ingeniería inversa y va dirigido a los aceleradores gráficos Adreno, además de una corrección para VA-API que podía provocar la caída de AMDGPU sobre una gráfica RX 6900 XT cuando se reproduce un vídeo corrupto.

Fuente: Muy Linux.

El desarrollo de Nouveau, el driver de código abierto presente en el​_ kernel Linux para las gráficas de NVIDIA, ha recibido un fuerte varapalo después de que Ben Skeggs haya renunciado a su puesto en Red Hat, ya que dicha decisión ha puesto fin a su contribución activa al controlador.

El desarrollo de Nouveau ha atravesado muchos momentos difíciles debido a que NVIDIA no lo ha puesto fácil para que sea una alternativa al menos decente a su driver privativo. De hecho, y a pesar de ser un proyecto veterano, la realidad es que el controlador de código abierto a duras penas es útil para una cantidad reducida de usuarios, y es que la mayoría se ve obligada a tener que tirar del driver oficial del gigante verde incluso para contextos de escritorio básico. Y es más, el soporte de Wayland posiblemente sea la única faceta en la que Nouveau va por delante, pero a cambio de ofrecer un rendimiento mucho más pobre.

​_Ben Skeggs ha sido el principal mantenedor de Nouveau durante más de una década y entre sus batallas está el hecho de conseguir que las series de gráficas posteriores a la GTX 900 funcionaran, cosa que requirió de imágenes de firmware firmadas para tener soporte de aceleración mediante la GPU (por hardware). Eso sí, conseguir aceleración por hardware no tiene por qué significar buen rendimiento y/o fiabilidad en ese frente.

Skeggs ha dejado constancia de su renuncia en diversos mensajes publicados en las listas de correo de freedesktop, un proyecto que trabaja en la interoperabilidad y la base tecnológica compartida entre X11, Wayland, Linux y otros sistemas tipo Unix y que aloja muchos desarrollos, entre ellos Xorg, Wayland, Mesa, GStreamer, PulseAudio, PipeWire y systemd.

Sobre la situación de Nouveau, Skeggs ha explicado en uno de los mensajes que siente que “con GSP-RM se está simplificando enormemente el soporte para el hardware futuro. Además, hay una comunidad que se está construyendo en torno a NVK y las cosas están en buenas manos. Este es el momento adecuado para tomarme un tiempo y explorar otras vías”. Para los que anden perdidos, GSP-RM es el firmware que emplea Nouveau para tener aceleración por hardware.

Nouveau se encuentra en la actualidad en​_ un momento importante de su historia, sobre todo porque apunta a ganar soporte de Vulkan en los próximos meses debido a que NVK ha sido fusionado en Mesa. Este es un paso importante no tanto para ejecutar videojuegos, sino más bien para garantizar que el controlador del kernel pueda soportar aplicaciones del futuro que se apoyen en Vulkan, una API que por ahora es prescindible en un escritorio Linux básico, pero que se ha asentado como el estándar en los videojuegos y en el futuro apunta a ser incorporada en soluciones profesionales como Blender. También hay esfuerzos para soportar OpenCL, pero a estos parece que todavía les queda mucho por delante para ofrecer algo maduro.

A pesar del pobre rendimiento que ofrece y de la escasísima contribución de NVIDIA, parece que la situación en torno a Nouveau no es tan oscura como en tiempos pasados, cuando la falta del firmware GSP-RM terminó haciendo casi imposible el ofrecer un soporte mínimamente decente para las gráficas más recientes, sobre todo a partir de Pascal (GTX 1000).

Fuente : Muy Linux.

VKD3D-Proton 2.10 ha sido publicada como la nueva versión del renderizador (o traductor) de Direct3D 12 a Vulkan y que, como bien indica su nombre, forma parte de la capa de compatibilidad Proton. Se trata de un proyecto que parte de una bifurcación del VKD3D original, procedente de Wine​_.

Microsoft ha intentado con DirectX 12 ir más allá de solo procesar gráficos mediante una GPU, sino también abarcar otros aspectos que permitan mejorar el desempeño de los videojuegos. De todo lo presente en la última versión de la tecnología del gigante de Redmond se puede destacar a DirectStorage, una característica que permite al procesador gráfico (GPU) llevar a cabo las tareas de descompresión de datos instalados en las unidades SSD sin pasar por el procesador.

VKD3D-Proton 2.10 puede hacer uso de la extensión de Vulkan NV_memory_decompression para implementar la compresión de GDeflate acelerada por hardware en DirectStorage. Por otro lado, los responsables del renderizador comentan que han trabajado alrededor de un bug en el driver de NVIDIA cuando se usa el sombreador de respaldo de GDeflate. El sombreador de respaldo también funciona a partir de este lanzamiento en RADV (el driver de Vulkan para gráficas Radeon presente en Mesa).

Otra novedad es que, con la implementación de la extensión de Vulkan NV_device_generated_commands_compute, es posible implementar de manera eficiente el uso que hace Starfield de ExecuteIndirect, lo que debería de mejorar el desempeño del último triple A de Bethesda, aunque por ahora esto solo funciona con el driver RADV. Antes se empleaba otro arreglo para el mismo problema, pero ofrecía un rendimiento más lento.

Otras cosas que han sido implementadas en VKD3D-Proton 2.10 son el soporte para la versión 1.2 de Support Root Signature, la implementación de Shader Model 6.7 (si bien Vulkan no cumple con la implementación como tal, funciona tanto con NVIDIA como RADV), la implementación de CreateSampler2, la implementación de la característica RelaxedFormatCasting procedente de Enhanced Barriers y un soporte correcto para A8_UNORM usando la extensión de Vulkan VK_KHR_maintenance5.

Otras extensiones de Vulkan que están soportadas a partir de este lanzamiento son VK_EXT_dynamic_rendering_unused_attachments, VK_KHR_maintenance5 y VK_NV_device_generated_commands_compute, mientras que a nivel de rendimiento están las compilaciones de la estructura de aceleración por lotes, una característica que mejora el rendimiento al menos en RADV, y la mencionada mejora del rendimiento de ExecuteIndirect con VK_NV_device_generated_commands_compute, que obviamente se puede aplicar a otras aplicaciones que hagan uso de DirectX 12.​_​_

Por último están las correcciones, de las que se pueden destacar aquellas que han arreglado lo siguiente: un mal rendimiento de Resizable BAR (ReBAR) en Age of Wonders 4, un problema de corrupción de memoria en Starfield, la inhabilitación de ReBAR en Halo Infinite para arreglar el pobre rendimiento de la CPU, un problema de cuelgue de la GPU en juegos de Capcom como Street Fighter 6 y Resident Evil 2 remake, otro cuelgue de GPU que afecta a Armored Core VI en la pelea de Balteus del capítulo 1, fallos de glitches que afectan a Monster Hunter Rise y Resident Evil 4 remake, un fallo en torno a los montones de consultas de marcas de tiempo en el driver de NVIDIA que puede provocar falsos cuelgues de la GPU, además de una rotura en Unreal Engine 5 cuando los sombreadores en malla están expuestos, pero no las coordenadas baricéntricas.

Con la consolidación de DirectX 12 como API para la construcción de videojuegos, VKD​_​_3D-Proton irá ganando protagonismo en el futuro, mientras que DXVK, que se encarga de traducir las versiones 9, 10 y 11 de Direct3D, quedará como un soporte para títulos que ya han sido comercializados. Si Valve quiere que la Steam Deck tenga futuro, deberá de invertir bastante en la mejora de VKD3D-Proton.

Un dato curioso es que tanto DirectX 12 como Vulkan son derivadas de Mantle, una API creada por AMD y que fue “donada” a Microsoft y Khronos Group respectivamente. En consecuencia y como señala la wiki de WineHQ, DirectX 12 y Vulkan tienen muchas similitudes, lo que sobre el papel debería facilitar la compatibilidad, pero no hay que olvidar que la tecnología de Microsoft es privativa y la de Khronos Group una especificación abierta.

Y hasta aquí lo más importante de VKD3D-Proton 2.10. Los que quieran conocer todos los detalles pueden consultar el anuncio de lanzamiento publicado en el repositorio GitHub del proyecto, mientras que el renderizador, si no se quiere lidiar con él, lo suyo es esperar a que llegue a Proton.

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.