El fin de semana del 2 al 4 de febrero se ha celebrado el FOSDEM 2024, donde se han reunido muchos desarrolladores y gente relacionada al software libre y de código abierto. Allí se han tratado muchos temas y han adelantado información como la que asegura que Kubuntu pasará a usar Calamares, pero también se presentó por sorpresa una nueva consola o PC de mano, la Orange Pi Neo que usará el sistema operativo Manjaro.

Si termina siendo competencia de la Steam Deck está por ver. Valve se sacó de la manga algo que en realidad ya había existido, pero mejoró el concepto y está consiguiendo muchas ventas incluso a gente que jamás había tocado Linux. Más tarde llegaron otras como la Legion Go o la Rog Ally, con una potencia superior pero un desequilibrio que les hace perder en frentes como los de la autonomía. Manjaro no ha querido perder este tren y se ha aliado con Orange Pi para ofrecer la Orange Pi Neo con las siguientes especificaciones.

Especificaciones técnicas de la Orange Pi Neo

table{border-collapse: collapse; margin: auto;}td, th{padding: 5px}th{background-color: grey}td,th{border: 1px solid};

La Orange Pi Neo ya tiene página en la web de Manjaro, pero aún no aparece en su sección de hardware. Cuando lo haga sabremos también cuánto costará y cuándo estará disponible. Teniendo en cuenta los precios que se barajan en la tienda de Manjaro y lo que cuestan los SBC de Orange Pi, lo único que podemos decir es que no será barata, y creo que la Orange Pi Neo tendrá un precio más cercano al de la Rog Ally de ASUS que al de la Steam Deck de Valve.

Músculo tiene para ser una buena opción, pero, en mi opinión, está un poco en tierra de nadie. Por una parte, el sistema operativo será Manjaro, de escritorio, y en un principio no estará tan bien optimizado como SteamOS para una consola. Por otra parte, Manjaro es Linux, lo que le permitirá instalar Steam, Heroic y todos los emuladores que podamos necesitar, pero tampoco puede acceder al Game Pass de Microsoft.

Sistema operativo de escritorio 100%

Que la Orange Pi Neo tenga un sistema operativo de escritorio 100% también tiene sus cosas buenas y sus cosas malas. Lo mejor es que es un PC real que puede funcionar usando el teclado en pantalla y los paneles táctiles o conectarlo a un monitor y trabar con él como si fuera un ordenador fijo o de torre. Si queremos instalar software como GIMP o Visual Studio Code, podemos hacerlo desde repositorios oficiales de Manjaro o AUR (Arch User Repositiry). También es posible añadir soporte para paquetes flatpak y snap. La Steam Deck por defecto sólo permite instalar paquetes de Flathub, lo que nos permite instalar los dos programas mencionados pero ocupando mucho más espacio. También es cierto que existe una opción para hacer que no sea sólo de lectura.

Lo malo de los sistemas operativos de escritorio es que no están tan optimizados como SteamOS. Aunque se ejecutara Steam en modo Big Picture, el sistema operativo seguiría funcionando en segundo plano con el consumo de recursos correspondiente. Por otra parte, SteamOS en su modo consola actúa – salvando las distancias – como Kodi en la Raspberry Pi: hace una especie de puente al sistema operativo para que se ejecute sólo lo necesario para funcionar.

Sabremos más de la Orange Pi Neo en las próximas horas.

from Linux Adictos https://ift.tt/9XzNksa
via IFTTT

Mesa es una biblioteca gráfica de código abierto, desarrollada que proporciona una implementación genérica de OpenGL

Hace poco se dio a conocer el lanzamiento de la nueva versión de los controladores «Mesa 24.0» la cual es la primera versión de la rama Mesa 24.x la cual está catalogada como experimental y posterior a la estabilización de la rama se estará dando a conocer el lanzamiento de la versión estable.

Esta nueva versión de Mesa 24.0 ofrece soporte completo para la API de gráficos Vulkan 1.3 a través de diversos controladores, incluyendo anv para GPU Intel, radv para GPU AMD, NVK para GPU NVIDIA, tu para GPU Qualcomm, y en el rasterizador lvp y vn. Además, la compatibilidad con Vulkan 1.0 está implementada en los controladores v3dv (GPU Broadcom VideoCore VI de Raspberry Pi 4) y dzn (implementación de Vulkan sobre Direct3D 12).

Principales novedades de Mesa 24.0

En esta nueva versión de Mesa 24.0 se destaca la compatibilidad total con OpenGL 4.6 para una amplia gama de hardware, pues se han implementado algunas nuevas características y de las más notables se encuentra la compatibilidad con el controlador d3d12.

Asimismo, en Mesa 24.0, se brinda soporte para OpenGL 4.5 en las GPU AMD (r600) y NVIDIA (nvc0), mientras que la compatibilidad con OpenGL 3.3 está presente en los controladores softpipe (rasterizador de software), asahi (GPU AGX utilizada en los chips Apple M1 y M2) y nv50 (NVIDIA NV50).

Otro de los aspectos destacados, es la implementación de la API Vulkan 1.3 junto con la adición de un nuevo controlador «pvr» para la GPU Imagination PowerVR, asi como también que el controlador Asahi para la GPU Apple AGX incluye soporte para sombreadores de geometría y es compatible con OpenGL 3.3 y el controlador RADV Vulkan para GPU AMD ha mejorado el rendimiento del trazado de rayos.

También se destacan las nuevas extensiones de Vulkan para la aceleración por hardware de la codificación de video en formatos h.264 y h.265 y características en varios controladores, incluidos RADV y Asahi.

Se han incorporado diversas extensiones al controlador NVK Vulkan para GPU NVIDIA: VK_KHR_vulkan_memory_model, VK_EXT_multi_draw, VK_EXT_subgroup_size_control, VK_KHR_fragment_shader_barycentric, VK_KHR_synchronization2, VK_KHR_shader_float_controls, VK_KHR_shader_atomic_int64 y VK_KHR_shader_subgroup_extended_types

Por otro lado, el controlador RADV Vulkan para GPU AMD ha sido actualizado con soporte para una serie de extensiones: VK_EXT_image_compression_control, VK_EXT_device_fault, VK_EXT_depth_clamp_zero_one, VK_KHR_calibrated_timestamps, VK_KHR_vertex_attribute_divisor, VK_KHR_maintenance6 y VK_KHR_ray_tracing_position_fetch

Por la parte de las correcciones de errores, Mesa 24.0 aborda una amplia gama de problemas y errores que han sido identificados en versiones anteriores y de las correcciones mas destacadas se incluyen:

• Solución para fallos en la reproducción de video con la aceleración de hardware Radeon RX6600 habilitada.
• Corrección de artefactos gráficos en texturas de agua en OpenGOAL.
• Solución para fallos en el codificador HEVC al usar VAAPI: EFC en VCN2.
• Solución para problemas de antialiasing en Blender con GPU AMD RDNA3.
• Corrección de fallas de compilación con MSVC durante el ciclo de desarrollo 23.3.
• Solución para errores durante el análisis SPIR-V de OpCopyLogical.
• Solución para problemas de salida de profundidad conservadora con RADV, entre otros.

Finalmente si estás interesado en conocer más al respecto sobre esta nueva versión de los controladores Mesa, puedes consultar los detalles en el siguiente enlace.

¿Cómo instalar los drivers de video Mesa en Linux?

Los paquetes de Mesa se encuentran en todas las distribuciones de Linux, por lo que su instalación puede realizarse ya sea descargando y compilando el código fuente (toda la información al respecto aquí) o de una forma relativamente sencilla, la cual depende de la disponibilidad dentro de los canales oficiales de tu distribución o de terceros.

Para los que son usuarios de Ubuntu, Linux Mint y derivados pueden añadir el siguiente repositorio en donde los controladores son actualizados de manera rápida.

sudo add-apt-repository ppa:kisak/kisak-mesa -y

Ahora vamos a actualizar nuestro listado de paquetes y repositorios con:

sudo apt update

Y finalmente podemos instalar los drivers con:

sudo apt upgrade

Para el caso de los que son usuarios de Arch Linux y derivados estos los instalamos con el siguiente comando:

sudo pacman -S mesa mesa-demos mesa-libgl lib32-mesa lib32-mesa-libgl

Para quienes sean usuarios de Fedora 32 pueden utilizar este repositorio, por lo que deben de habilitar corp con:

sudo dnf copr enable grigorig/mesa-stable

sudo dnf update

Finalmente, para los que son usuarios de openSUSE, pueden instalar o actualizar tecleando:

sudo zypper in mesa

from Linux Adictos https://ift.tt/HojF6xw
via IFTTT

Desde que Linus Torvalds incluyó Rust en la versión 6.1 del Kernel de Linux, el lenguaje ha estado ganando terreno gradualmente y son cada vez más los desarrolladores que se unen a este movimiento.

Sin embargo, algunos de los desarrolladores del Kernel de Linux resaltan que los avances cada vez más supondrán más trabajo y desafíos, ya que dentro de sus comentarios dan a entender que es posible que surja un estancamiento.

Cabe aclarar que no mencionamos que la implementación llegue a un punto muerto, sino que dados los comentarios de diversos desarrolladores y como ya mencionamos, en el estado actual, ha comenzado a surgir la necesidad de disminuir el ritmo de trabajo, o al menos eso es lo que nos sugiere el siguiente artículo de LWN.net.

Y es que hace ya varias semanas me encontré con este artículo en donde se trata de abordar el estado actual del uso de Rust en Linux y analizar si el experimento con este lenguaje de programación ha sido exitoso.

Se menciona que desde hace algunos años, Rust ha sido un tema que no ha dejado de tocarse en la «Kernel Maintainers Summit» y la celebrada en este 2023 no fue la excepción, ya que desde la implementación oficial de Rust como segundo lenguaje de programación en Linux, Miguel Ojeda, desarrollador de Rust-for-Linux, destacó el creciente interés en el uso de Rust para el desarrollo del kernel durante la sesión dedicada a este tema.

Miguel Ojeda menciona que el proyecto Rust-for-Linux ha experimentado un impulso significativo en el último año, ya que se ha sumado un ingeniero a tiempo completo y un desarrollador estudiantil y que diversas empresas se han sumado al respaldado del trabajo. Además, se está trabajando para integrar la herramienta Coccinelle con el código Rust. Sin embargo, no todo es color de rosa, ya que uno de los desafíos actuales es reclutar más revisores para el código que se está desarrollando.

En el artículo se menciona qué los problemas han comenzado a ser notorios en la cadena de herramientas, ya que el progreso del compilador Rust basado en GCC, conocido como gccrs, se ha ralentizado. Por otro lado, el generador de código GCC para rustc muestra avances prometedores y ha sido fusionado con el compilador, lo que permitirá expandir el soporte de Rust a arquitecturas que no son compatibles con LLVM.

Dentro del kernel, se están realizando avances en varios subsistemas, tal es el caso de la implementación en Rust del binder de Android que ha demostrado un rendimiento comparable a la implementación en C, con una cantidad mínima de código inseguro. Además, se está trabajando en vinculaciones de sistemas de archivos con el objetivo de lograr soporte de solo lectura en Rust, con la visión de implementar un sistema de archivos completamente seguro en Rust.

Dave Airlie, el mantenedor del subsistema DRM (gráficos), dijo que, si se sale con la suya, habrá un controlador Rust DRM fusionado en los próximos lanzamientos. Christoph Hellwig respondió que Airlie estaba dispuesta a «hacer la vida de todos un infierno» para poder jugar con su juguete favorito. Hellwig dijo que fusionar Rust obligaría a otros a lidiar con un segundo lenguaje, nuevas cadenas de herramientas y «envoltorios con semántica extraña». Dan Williams dijo que la situación actual «es lo que parece el éxito» y que la comunidad del kernel ya estaba comprometida con Rust.

Aunque se observa un creciente interés por parte de los mantenedores en adoptar Rust, surgen desafíos, ya que se ha debatido la necesidad de tener controladores de referencia en el kernel escritos en Rust para mostrar cómo pueden escribirse controladores en este lenguaje. Sin embargo, la duplicación de funcionalidad entre controladores en Rust y C ha generado desconfianza entre los mantenedores.

La discusión sobre la inclusión de Rust ha tomado diferentes direcciones, pues algunos mantenedores abogan por la fusión de controladores Rust autónomos, como el controlador de binder, para demostrar su viabilidad, mientras que por el otro lado de la moneda otros expresan preocupaciones sobre la complejidad de mantener un kernel con dos lenguajes de programación.

Airlie continuó diciendo que gran parte del trabajo de Rust está actualmente bloqueado en una especie de problema del huevo y la gallina. Las abstracciones no se pueden fusionar hasta que haya un usuario para ellas, pero el código que necesita esas abstracciones se bloquea esperando que el código llegue a múltiples subsistemas. Como resultado, los desarrolladores que trabajan en Rust están arrastrando grandes cantidades de parches que necesitan para que su código funcione. Romper ese obstáculo requerirá permitir la entrada de algunas abstracciones sin usuarios inmediatos.

A pesar de los desafíos, la comunidad del kernel reconoce el potencial de Rust para mejorar la seguridad y la estabilidad del código. Se plantea la posibilidad de fusionar controladores más ampliamente utilizados en Rust en el futuro, una vez que se resuelvan las preocupaciones sobre la capacidad de revisión y mantenimiento.

Ojeda estuvo de acuerdo en que este problema ha ralentizado el progreso, pero dijo que ha tratado de no presionar a los mantenedores para que fusionen el código rápidamente. En el caso de las redes, irónicamente, los desarrolladores de Rust tuvieron que pedir a los encargados de la red que ralentizaran la fusión del código Rust.

Finalmente cabe mencionar que el camino hacia la adopción generalizada de Rust en Linux presenta desafíos, el interés y el progreso en este espacio son evidentes. Con el tiempo, se espera que Rust juegue un papel importante en la mejora de Linux.

Fuente: https://lwn.net/

from Linux Adictos https://ift.tt/1uh8JkI
via IFTTT