LeftoverLocals, una vulnerabilidad en GPUS que permite el robo de datos 

vulnerabilidad

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco, los investigadores de Trail of Bits (una firma de seguridad) dieron a conocer mediante una publicación de blog que detectaron un problema en las GPU de AMD, Apple, Qualcomm e Imagination, que hace posible que alguien obtenga datos de la memoria de la tarjeta gráfica, incluso si fueron creados por un programa diferente.

Bautizada como LeftoverLocals, esta vulnerabilidad afecta a las unidades de procesamiento de gráficos y con lo cual un atacante puede robar una cantidad significativa de datos.

Sobre LeftoverLocals

Catalogada ya bajo «CVE-2023-4969» y con una puntación de «8», hacen de LeftoverLocals, es una vulnerabilidad sumamente peligrosa, ya que permite la recuperación de datos de la memoria local de la GPU, que persisten después de que se haya ejecutado otro proceso y podrían contener información sensible.

Lo que hace de LeftoverLocals una vulnerabilidad peligrosa, es que afecta a una variedad de dispositivos ampliamente utilizados, muchos de los cuales seguían sin parchear y que puede ser explotada en entornos multiusuario, donde controladores para diferentes usuarios se ejecutan en la misma GPU, además de que podría ser explotada por malware para monitorear la actividad de los procesos que se ejecutan en la GPU, identificando datos procesados por el kernel de la GPU.

LeftoverLocals surge debido a un aislamiento insuficiente de la memoria local de la GPU y la incapacidad de limpiar dicha memoria después de la ejecución de procesos en la GPU. Esto permite que un proceso malicioso identifique datos residuales en la memoria local después de que otro proceso se ha ejecutado o lea datos de un proceso actualmente en ejecución.

Se menciona que, la esencia de LeftoverLocals radica en memoria local en una GPU que actúa como una caché para almacenar cálculos intermedios y puede variar en tamaño desde decenas de kilobytes hasta varios megabytes para cada unidad informática. El ataque implica ejecutar un controlador (kernel) en la GPU que copia periódicamente el contenido de la memoria local disponible en la memoria global (VRAM). Dado que la memoria local no se borra al cambiar entre procesadores en la GPU y se comparte entre diferentes procesos dentro de la misma unidad de cálculo de la GPU, puede contener datos residuales de otros procesos.

Con la finalidad de probar la vulnerabilidad, los investigadores de Trail of Bits han desarrollado algunos prototipos de exploits para diferentes GPU, utilizando las API OpenCL, Vulkan y Metal para acceder a la GPU. Aunque llevar a cabo un ataque desde un navegador a través de WebGPU es difícil debido a las comprobaciones dinámicas de límites de matriz agregadas por WebGPU, los investigadores han demostrado cómo la vulnerabilidad puede utilizarse para determinar datos de salida de otros usuarios y crear canales de comunicación ocultos entre diferentes procesos.

Ademas de ello, se menciona que la cantidad de datos filtrados depende del marco específico de la GPU y del tamaño de su memoria local. Por ejemplo, la relativamente grande AMD Radeon RX 7900 XT pierde alrededor de 5.5 MB o alrededor de 181 MB por cada consulta LLM, según los investigadores.

Dado que las GPU se utilizan cada vez más para acelerar las aplicaciones de inteligencia artificial y aprendizaje automático, los investigadores advirtieron que fallas como LeftoverLocals podrían convertirse en un objetivo importante.

«En general, la introducción del aprendizaje automático plantea nuevas superficies de ataque que los modelos de amenazas tradicionales no tienen en cuenta y que pueden conducir a un acceso implícito y explícito a datos, parámetros del modelo o resultados resultantes, aumentando la superficie de ataque general del sistema», señala el informe. escribieron los investigadores.

Trail of Bits señaló que se han implementado soluciones para esta vulnerabilidad en algunos dispositivos de Apple, y se espera una actualización de controladores de AMD en marzo, por su parte Qualcomm ha informado que ha solucionado el problema para la GPU Adreno a630 en la actualización de firmware 2.07, mientras que Imagination ha proporcionado una solución en el nuevo DDK 23.3 lanzado en diciembre.

Por otra parte, se menciona que no se ven afectadas las GPU de NVIDIA, Intel y ARM. En los controladores OpenCL de código abierto de Mesa para GPU AMD, la memoria se borra después de cada inicio del kernel, pero este método se considera ineficaz en algunos casos.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/7UbRWYv
via IFTTT

Esta es, en mi opinión, la mejor manera de instalar aplicaciones web si usas un navegador basado en Chromium en Linux

Aplicaciones web gracias a Bash

Hace unos días publicamos un artículo en el que comparábamos tres maneras diferentes de usar aplicaciones web. Por un lado, desde el navegador tal cual; por otro, instalando la aplicación y usándola en una ventana separada; y por último haciendo uso de Webapp Manager, lo que creo que es lo mejor con diferencia. Hoy os traigo una opción diferente, una que se basa en parte en la XApp de Linux Mint.

Las aplicaciones instaladas desde el navegador pesan un poco más que lo que crea Webapps Manager. Tienen una ventaja, y es que se puede acceder a las extensiones fácilmente y funcionan todas, como por ejemplo un ecualizador que yo no he hecho funcionar -tampoco he buscado mucho- en las aplicaciones 100% separadas. Pero, por lo general, lo que crea Webapps Manager está a un nivel superior. Lo que pasa es que, por lo menos para los navegadores basados en Chromium más populares, lo único que hace es crear un archivo .desktop con una orden que le dice al navegador que lance una aplicación en un perfil aislado. Conseguir eso es lo que vamos a explicar hoy aquí.

Aplicaciones web en perfil aislado y sin instalar nada

Lo malo de la aplicación de Linux Mint, por ponerle algún pero, es que instala el software principal y algunos módulos de Python extra. Es peccata minuta para el que usa muchas aplicaciones web y además quiere elegir el navegador base, pero si nos es suficiente con Chrome, Brave, Vivaldi o Edge, todo lo que instalemos está de más.

Como decíamos, el secreto está en examinar qué hacen esas aplicaciones, analizar el archivo .desktop y crear uno parecido. Esto, que se puede hacer manualmente a partir del primer archivo que nos crea Webapp Manager, copiando y editando lo necesario, podemos automatizarlo usando Bash. El código sería el siguiente:

#!/bin/bash
echo "SSBash

¿Qué quieres hacer?
1. Crear aplicación web
2. Eliminar app existente
3. Salir"
read opcion
if [ "$opcion" == "1" ]; then
    echo "Nombre de la aplicación:"
    read nombre_app
    id_app=$(echo "$nombre_app" | tr -d ' ')
    echo "Comentario:"
    read comentario
    echo "Categoría":
    read categoria
    echo "URL de la aplicación web (sin https/http):"
    read url
    echo "Ruta al icono de la app":
    read icono
    echo "Navegador:
     1. Chrome
     2. Chromium
     3. Brave
     4. Edge
     5. Vivaldi
     6. Chrome (flatpak)
     7. Chromium (flatpak)
     8. Brave (flatpak)
     9. Edge (flatpak)
    10. Vivaldi (flatpak)
    11. ungoogled-chromium (flatpak)"
    read navegador_elegido

    case $navegador_elegido in
        1) navegador="Chrome" && ejecutable="google-chrome-stable --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        2) navegador="Chromium" && ejecutable="chromium --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        3) navegador="Brave" && ejecutable="brave --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        4) navegador="Edge" && ejecutable="microsoft-edge --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        5) navegador="Vivaldi" && ejecutable="vivaldi-stable --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        6) navegador="Chrome-flatpak" && ejecutable="flatpak run com.google.Chrome --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        7) navegador="Chromium-flatpak" && ejecutable="flatpak run org.chromium.Chromium --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        8) navegador="Brave-flatpak" && ejecutable="flatpak run com.brave.Browser --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        9) navegador="Edge-flatpak" && ejecutable="flatpak run com.microsoft.Edge --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        10) navegador="Vivaldi-flatpak" && ejecutable="flatpak run com.vivaldi.Vivaldi --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        11) navegador="ungoogled-chromium-flatpak" && ejecutable="flatpak run com.github.Eloston.UngoogledChromium --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        *) echo "Opción no válida. Seleccionando Chrome por defecto." && navegador="Chrome";;
    esac

    cadena_aleatoria=$(head /dev/urandom | tr -dc a-z0-9 | head -c 30 ; echo '')
    acceso_directo=$navegador-$id_app-$cadena_aleatoria.desktop
    touch $acceso_directo
    mkdir -p "$HOME/.config/SSBash/$navegador-$id_app/img/"
    cp $icono "$HOME/.config/SSBash/$navegador-$id_app/img/"
    nombre_imagen=$(basename "$icono")
    echo "[Desktop Entry]
    Version=1.0
    Name=$nombre_app
    Comment=$comentario
    Exec=$ejecutable
    Icon=$HOME/.config/SSBash/$navegador-$id_app/img/$nombre_imagen
    Terminal=false
    Type=Application
    Categories=$categoria
    StartupNotify=true
    StartupWMClass=WebApp-$id_app" >> "$acceso_directo"

    chmod +x $acceso_directo
    mv $acceso_directo ~/.local/share/applications/

    echo "
    La aplicación '$nombre_app' debería haberse instalado.  Por favor,
    comprueba el archivo desktop en ~/.local/share/applications/
    y, tras ejecutarlo, que existe el perfil en ~/.config/SSBash/."
elif [ "$opcion" == "2" ]; then
    if [ -n "$(ls -A "$HOME/.config/SSBash/")" ]; then
        echo "¿Qué aplicación web quieres eliminar?" && ls $HOME/.config/SSBash/
        read app_eliminar
        if [ -n "$app_eliminar" ] && [ -e "$HOME/.config/SSBash/$app_eliminar" ]; then
            desktop_eliminar=$(echo "$app_eliminar" | tr -d ' ')
            rm -rf $HOME/.config/SSBash/"$app_eliminar"/
            rm $HOME/.local/share/applications/$desktop_eliminar*
            echo "La aplicación con id '$app_eliminar' ha sido eliminada."
        else
            echo "La apliación con id '$app_eliminar' no está en la lista."
        fi
    else
        echo "No hay aplicaciones web instaladas."
    fi
elif [ "$opcion" == "3" ]; then
    echo "Hasta la próxima."
else
    echo "Opción no válida".
fi

Explicando el código

El script o programa son menos de 100 líneas, y en él incluso se pueden eliminar las aplicaciones creadas. Es un poco rudimentario, pero hace lo que queremos. Se ejecuta con «bash nombre-del-archivo» -en donde hayamos pegado el código anterior- y todo pasa en el terminal. Se pueden editar las líneas de los navegadores y añadir otros basados en Chromium.

Empieza mostrando un nombre, y cada uno puede poner lo que más le guste. Como este tipo de aplicaciones son SSB por Site-Specific Browser y lo usado es Bash, pues SSBash no suena mal. Luego nos consulta si queremos crear una aplicación web o eliminar alguna de las que ya tenemos. Si le decimos que queremos crearla, nos pedirá el nombre de la aplicación, un comentario para los paneles que los soporten, a qué categoría pertenece, la URL del servicio, ruta al icono y luego un navegador web.

Creando una webapp con SSBash

Lo única diferencia que hay entre navegadores es el comando que los lanza, pero las banderas son iguales en todos los casos: crea una aplicación con su clase y un perfil aislado; luego creará el archivo .desktop con una cadena de caracteres aleatoria para evitar coincidencias, lo que se considera una buena práctica; a continuación crea una carpeta para la imagen que será el icono, rellena el archivo .desktop con todo lo necesario, le da permiso de ejecución y lo mueve a la carpeta `~/.local/share/applications/, que es en donde suelen estar los accesos directos propios y de algún otro software como las AppImage. Al lanzar la aplicación por primera vez se completará la creación del perfil.

Algunas precauciones

Si elegimos la opción de eliminar, el software consulta lo que hay en la carpeta de configuración, nos lo muestra y, tras poner exactamente una de las opciones, eliminará el .desktop y la carpeta con el perfil aislado. Está comprobado que funciona, pero ni yo ni LXA nos responsabilizamos de las posibles pérdidas de datos -más que nada accesos directos- que puedan tener lugar. Si alguien no quiere correr ningún riesgo, se pueden eliminar borrando el archivo .desktop de ~/.local/share/applications/ y el perfil de ~/.config/SSBash/nombre-de-la-app. Otra opción es hacer una copia de seguridad del contenido de ~/.local/share/applications/ antes de eliminar una app, comprobar que funciona y luego ya usarlo como se diseñó.

Como decía, es un poco rudimentario y no se gestionan los posibles errores. En ocasiones, dependiendo de la imagen o donde está, es probable que se vea algún fallo, en cuyo caso recomiendo revisar qué hay en el archivo .desktop.

Dos datos que me parece que hay que saber: Opera no está soportado, pero se pueden añadir otros basados en Chromium y probar; y, para que esto sea lo más simple posible, los iconos no los descarga ni nada, hay que buscarlos, descargarlos e indicar la ruta a ellos. Tampoco incluye una opción para instalar aplicaciones como lo hace el navegador… porque eso ya lo hace el navegador.

¿Y las extensiones?

Es posible instalar extensiones en este tipo de aplicaciones web, pero algunas no funcionarán. Por ejemplo, esas del ecualizador que actúan sólo en las pestañas en donde los activamos. Sí funcionarán las extensiones que funcionen en todo el navegador.

Para instalarlas, lo que hay que hacer es abrir una ventana nueva del navegador, lo que se puede conseguir con Ctrl-T o haciendo clic secundario sobre cualquier enlace y abriendo en una pestaña nueva. Se abrirá el navegador en cuestión, y esto permitirá ir a la Chrome Web Store e instalar cualquier extensión. Una vez instaladas podemos cerrar esos navegadores «completos» y volver a usar la aplicación web con la extensión incluída.

Otra manera de tener aplicaciones web

Esta es otra manera de tener aplicaciones web. Y al ejecutarse en un perfil aislado, no se comparte ni historial ni extensiones ni nada, e incluso podemos forzar el cierre del navegador base y no pasa nada. Si alguien prefiere que las aplicaciones sean de Firefox, entonces es mejor usar Webapp Manager.

Lo único a tener en cuenta es que cada perfil/app ocupa un espacio y suele superar los 100mb. Por todo lo demás, creo que merece la pena.

.barra {display: flex;justify-content: flex-end;height: 25px; background-color: #333;border-radius: 5px 5px 0 0;}.rojo, .naranja, .verde{width: 12px;height: 12px; position: relative;border-radius: 50%;top: 7px; margin: 0 3px;}.rojo{background-color: rgb(248, 82, 82); margin-right: 7px;}.naranja{background-color: rgb(252, 186, 63);}.verde{background-color: rgb(17, 187, 17);}.terminal{background-color: black !important;color: white !important;border-radius: 5px !important;}pre{font-family:monospace !important; padding: 0 10px 10px; line-height: 1.5em; overflow: auto; background-color: black !important; color: #0ee80e !important}

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

¿Por qué chromeOS Flex no soporta aplicaciones de Android?

chromeOS Flex

Hace ya casi dos años desde que Google puso a disponibilidad de cualquiera que quisiera probarlo chromeOS Flex. Es como chromeOS, pero para otros ordenadores. Más o menos. O más menos que más. No soporta aplicaciones de Android, entre otras cosas, y hay gente que se pregunta por qué, y que si no sería mejor para la compañía incluirlo en la versión Flex.

La respuesta puede ser más corta o más larga. La corta es que hacen lo mismo que Apple: prefieren que el que quiera usar chromeOS tal y como se diseñó lo haga en un Chromebook, dispositivos que venden ellos. Entonces, ¿qué sentido tiene chromeOS Flex? Lo tiene, y es el mismo que el de los servicios de Google: obtener información de uso.

chromeOS Flex es una opción para dispositivos antiguos

La combinación perfecta para Google es cuando alguien les compra un Chromebook y le deja chromeOS instalado. De esta manera ganan un poco de dinero con la venta del aparato y mucho más con la información que reciben del uso que hacemos de ellos.

La otra opción que no quieren dejar pasar es la de la información. Vale, no les compramos un aparato a ellos ni a un fabricante que les aporta algún beneficio, pero no nos permite disfrutar de la experiencia completa de chromeOS. Entre lo que ofrece, el sistema operativo basado en aplicaciones y herramientas web, soporte para ejecutar aplicaciones de Linux (por lo general, Debian) y soporte para aplicaciones de Android. Si queremos resucitar un equipo antiguo sólo obtendremos al experiencia web, y ellos «sólo» recibirán datos de uso.

Quizá sea mejor una distribución ligera…

Digo que quizá lo sea por no afirmarlo con rotundidad. chromeOS no es que sea muy pesado, pero en comparación hay distribuciones ligeras que están mejor. Sería muy diferente si permitieran usar aplicaciones de Android, pero no es el caso en la versión Flex. Por lo tanto, si lo que vamos a obtener instalando chromeOS Flex es un sistema operativo con herramientas web y sin poder instalar programas de Linux ni apps de Android, creo que la decisión está clara.

Que uno quiera más o menos de Google es otra cuestión.

También es un tema aparte eso de coger chromeOS Flex y activarle el soporte que Google capa por defecto, pero eso es algo que probablemente hagamos en otro artículo (si comprobamos que es fácil y merece la pena).

A la cuestión que nos traía hoy por aquí, pues eso, Google no quiere ofrecer la experiencia completa si no puede llevarse el combo completo. ¿Tiene sentido? Probablemente, o de lo contrario lo harían de otra manera. ¿Para qué iba uno a comprar un Chromebook si puede instalar su sistema en cualquier otro aparato?

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

Nitrux 3.2.1 «se» ya fue liberada y estas son sus novedades

Nitrux

Nitrux continua con la migración hacia Maui Shell

Los desarrolladores de la distribución Linux «Nitrux» comenzaron el año lanzando una nueva versión estable del sistema, llegando este a su nueva versión «Nitrux 3.2.1» con nombre clave «se» que mencionan que hace referencia un «entorno más seguro», debido a la implementación en todo el sistema de la política de contraseñas utilizada en Calamares y otros cambios relacionados con la seguridad.

Para quienes desconocen de esta distribución, deben saber que está construida sobre la base del paquete Debian, las tecnologías KDE y el sistema de inicio OpenRC. Esta distribución se destaca por el desarrollo de su propio escritorio «NX», que es un complemento sobre el entorno KDE Plasma del usuario, además de que el proceso de instalación de aplicaciones está basado en el uso de paquetes AppImages.

Principales novedades de Nitrux 3.2.1 «se»

Esta nueva versión que se presenta de Nitrux 3.2.1 introduce varias mejoras significativas, incluyendo el kernel de Linux Liquorix 6.6.9-1 con mejoras en el soporte de hardware, controladores AMD Open Source para Vulkan® hasta la versión v-2023.Q4.2 y el entorno de escritorio KDE Plasma 5.27.10 LTS, KDE Frameworks 5.114 y KDE Gear 23.08.4. Estos componentes están construidos sobre el marco de aplicaciones Qt 5.15 LTS, que ofrece compatibilidad a largo plazo.

La instalación inicial del sistema ahora se beneficia de un instalador gráfico actualizado de Calamares. Entre las nuevas características se encuentra una casilla de verificación para deshabilitar la validación de seguridad de la contraseña predeterminada, así como una presentación de diapositivas renovada.

Por la parte de la paquetería del sistema, Nitrux 3.2.1 presenta diversas actualizaciones clave, entre las que se incluyen las versiones más recientes de Firefox 121, OpenRC 0.52.1 y AppArmor 4.0.0 alpha2. Además, se han implementado cambios significativos en el entorno de escritorio NX basado en KDE Plasma. Estas mejoras abarcan desde un efecto Cover Switch para cambiar de ventana hasta una nueva opción para reiniciar la sesión de KWin X11. También se han realizado ajustes para mejorar el inicio de sesión y ahorrar espacio en disco, se ha introducido una nueva sección de ayuda, se han actualizado temas, mejorado el escalado fraccional y se han añadido nuevas fuentes, fondos de escritorio, el lanzador de aplicaciones Plasma Drawer, así como las extensiones Plasma Gamemode y Active Blur.

Además de ello, también se destaca la integración de nuevos componentes, entre los que se incluyen el paquete rng-tools, el agente SPICE para Linux para acceso remoto a máquinas virtuales, pwgen para generación automática de contraseñas y un formulario PAM para comprobar el «fuerza” de la contraseña.

Nitrux 3.2.1 también presenta el módulo KCModule para tableta KDE Wacom, que implementa una GUI para los controladores Wacom Linux. Además, esta versión agrega nuevas fuentes del sistema (Switzer y CamingoCode) y un nuevo fondo predeterminado.

En cuanto a las mejoras de seguridad, se destaca que Nitrux 3.2.1 habilita el modo de aleatorización de direcciones MAC para redes en NetworkManager de forma predeterminada. Además, el estándar IPv6 Privacy Extensions (RFC 4941) se ha habilitado de forma predeterminada en NetworkManager y el kernel de Linux.

De los demás cambios que se destaca:

  • Se actualizaron los temas de KDE Plasma Nitrux, Nitrux Dark y Nitrux Mix para crear el diseño del escritorio correctamente utilizando Plasma Desktop Scripting (ECMA Script, también conocido como JavaScript).
  • Administrador de ventanas en mosaico (Tiling WM) llamado Polonium, que los usuarios pueden activar en la configuración.
  • Scripts de servicio para OpenRC para iniciar phodav y Avahi.
    Script de servicio para OpenRC para iniciar usbmuxd.
  • Se solucionaron los siguientes problemas:
    VirtualBox no puede iniciar ISO cuando usa EFI si fbx64.efi está presente en /EFI/BOOT
    La instalación falla en dispositivos Legacy BIOS
    Hay un problema de contraste con el esquema de color Nitrux Dark
    Algunas aplicaciones no se abren al hacer clic en el ícono del menú de aplicaciones
    Los plasmoides NX se congelan o bloquean el plasmashell cuando se agregan a un panel de plasma en la sesión de Wayland usando el hardware NVIDIA
    Algunos íconos están rotos

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

Descargar la nueva versión de Nitrux 3.2.1

Si quieren descargar esta nueva versión de Nitrux 3.2.1 deberán de dirigirse a la página web oficial del proyecto en donde podrán obtener el enlace de descarga de la imagen del sistema y la cual podrán grabar en un USB con ayuda de Etcher. Nitrux está disponible para su descarga inmediata desde el siguiente enlace. 

Para aquellos que ya se encuentran sobre una versión anterior de la distribución, pueden hacer la actualización a la nueva versión, tecleando los siguientes comandos:

sudo apt update

sudo apt install --only-upgrade nitrux-repositories-config amdgpu-firmware-extra

sudo apt install -o Dpkg::Options::="--force-overwrite" linux-firmware/trixie

sudo apt dist-upgrade

sudo apt autoremove

sudo reboot

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

Solus 4.5 ya fue liberado y estas son sus novedades

Solus

screenshot de Solus

Se ha dado a conocer el lanzamiento de la nueva versión de Solus 4.5 con nombre clave» Resilience «, Solus 4.5 introduce una nueva edición Xfce que reemplaza la edición MATE, se han implementado mejoras, correcciones de errores y más.

Para quienes desconocen de esta distribución de Linux, puedo decirles que en ella la gestión de paquetes se utiliza el administrador de paquetes eopkg (una bifurcación de PiSi de Pardus Linux), que proporciona las herramientas habituales para instalar / eliminar paquetes, buscar en el repositorio y gestionar repositorios. Los paquetes se pueden clasificar en componentes temáticos, que a su vez forman categorías y subcategorías.

Además, otro de los componentes que se destaca de esta distribución es su entorno de escritorio «Budgie» que se basa en tecnologías GNOME, pero utiliza sus propias implementaciones de GNOME Shell, panel, applets y sistema de notificación. Para administrar las ventanas, Budgie usa Budgie Window Manager (BWM), que es una modificación avanzada del complemento base de Mutter.

Principales novedades de Solus 4.5

En esta nueva versión, que se presenta de Solus 4.5, se destaca el desplazamiento de la edición Mate, por la nueva edicion XFCE con el entorno Xfce 4.18 personalizado. Para reproducir sonido y vídeo, la nueva versión utiliza el reproductor Parole de forma predeterminada, se incluyen Mousepad 0.6.1, Ristretto 0.13.1, Thunar 4.18.6 y Whiskermenu 2.8.0. Con ello se menciona que los desarrolladores trabajaran para ofrecer una transición perfecta para los usuarios existentes del escritorio MATE a Budgie o XFCE.

Otro punto a destacar de la versión Solus 4.5 es la implementación del instalador gráfico Calamares, que soporta el sistema de archivos Btrfs y permite crear propias particiones de disco. La transición a Calamares proporciona a los usuarios una nueva experiencia de instalación. Lo mismo ocurre con el servidor de medios Pipewire, que llega a reemplazar el uso de PulseAudio y JACK, para administrar transmisiones de medios y lo que permitirá mejoras de audio y un rendimiento de Bluetooth.

Por la parte de los componentes del sistema, Solus 4.5  presenta el kernel de Linux 6.6 con el programador de tareas BORE habilitado de forma predeterminada y optimizado para reducir la latencia del escritorio y aumentar la prioridad de los procesos interactivos.

En cuanto a la paquetería, se nos ofrece la última pila de gráficos Mesa 23.3, el navegador web Firefox 121, la suite LibreOffice 7.6, soporte ROCm para proporcionar aceleración de GPU para aplicaciones de GPU como Blender- Los desarrolladores de Solus dijeron que han trabajado duro para extender la compatibilidad de ROCm a la mayor cantidad de hardware posible, «incluidos algunos que no son oficialmente compatibles con AMD».

Para la versión con Budgie, se nos ofrece la versión 10.8.2 incluye el Budgie Trash Applet, ha experimentado cambios en la configuración del tema oscuro, rediseño del subprograma de la bandeja del sistema y modernización del menú de la aplicación.

En lo que respecta a otros entornos de escritorio, Solus 4.5 presenta GNOME 45.2 con algunas modificaciones. En lugar de Impatience, GNOME Shell utiliza el complemento Speedinator para optimizar las animaciones. El tema GTK predeterminado ha sido actualizado para utilizar adw-gtk3-dark, proporcionando una apariencia más fluida al ejecutar aplicaciones basadas en libadwaita con GTK3/4.

Por último y no menos importante, se menciona que la edición Plasma ha sido actualizada a las versiones de Plasma Desktop 5.27.10, KDE Gear 23.08.4, Qt 5.15.11 y sddm 0.20.0. Ahora, por defecto, se ha habilitado el doble clic para abrir archivos, y los nuevos directorios abiertos desde aplicaciones externas se mostrarán en una nueva pestaña de Dolphin.

Si estás interesado en conocer más al respecto de la nueva versión, puedes consultar los detalles en el siguiente enlace.

Descarga Solus 4.5

Si quieres obtener la nueva versión de Solus 4.5, solo debes dirigirte a su página web oficial y en su sección de descargas encontrarás los links para cada una de las diferentes versiones de entorno de escritorio de Solus.

El enlace es este. 

Se recomienda a los usuarios que ya utilizan la distribución que transfieran sus instalaciones de MATE a Budgie o la nueva edición Xfce, tal como mencionamos anteriormente, los desarrolladores estarán trabajando para ofrecer esta transición con la menor cantidad de problemas posibles a los usuarios.

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

El autor de Curl critica los informes de seguridad generados por IA

ai-security

IA utilizada para detectar problemas de seguridad

Hace pocos días, Daniel Stenberg (el autor de Curl) dio a conocer en su blog, una publicación en la cual expresa no solo como una crítica el uso de herramientas de inteligencia artificial, sino en forma de reclamo, las molestias que esto genera a él y a su equipo, los informes de seguridad generados por las herramientas de inteligencia artificial.

Y es que en su publicación, Daniel Stenberg menciona que durante muchos años el proceso de verificar todos los informes y descartar entre los problemas de seguridad “basura” y “reales”, no era algo que supusiera un esfuerzo adicional, pues menciona que «los informes basura normalmente también han sido muy fáciles y rápidos de detectar y descartar».

Con el reciente auge de la inteligencia artificial, se han revolucionado muchas tareas que anteriormente requerían muchas horas de intervención humana. Entre los casos más mencionados en este blog, hemos abordado los temas de IAs dedicadas a la programación, generación de imágenes, edición de video, como ChatGPT, Copilot, Bard, entre otras.

En el ámbito específico de la programación, Copilot generó numerosas críticas, siendo la principal preocupación la posibilidad de enfrentar demandas legales. Sin embargo, en el otro extremo de la balanza, la intervención de la inteligencia artificial ha transformado significativamente diversas áreas. Por ejemplo, en la detección de errores y problemas de seguridad en el código, las IAs han desempeñado un papel crucial. Muchas personas han adoptado estas herramientas para identificar posibles fallos y vulnerabilidades en el código, a menudo participando en programas de recompensas por la detección de problemas de seguridad.

Curl no escapó de esta tendencia, y Daniel Stenberg expresó en su blog que, después de varios meses de contener su opinión, finalmente explotó en desacuerdo con el uso de herramientas de inteligencia artificial. La razón detrás de su frustración fue la creciente cantidad de informes «basura» generados por el uso de estas herramientas.

En la publicación, se destaca que estos informes poseen una apariencia detallada, están redactados en un lenguaje normal y parecen ser de alta calidad. Sin embargo, sin un análisis cuidadoso, resultan ser engañosos, ya que reemplazan problemas reales con contenido de baja calidad que aparenta ser valioso.

El proyecto Curl, que ofrece recompensas por la identificación de nuevas vulnerabilidades, ha recibido un total de 415 informes sobre posibles problemas. De este conjunto, solo 64 fueron confirmados como vulnerabilidades reales, 77 describieron errores no relacionados con la seguridad y, sorprendentemente, 274 (66%) no contenían información útil, consumiendo el tiempo de los desarrolladores que podría haberse dedicado a algo útil.

Los desarrolladores se ven obligados a perder mucho tiempo analizando informes inútiles y verificando varias veces la información contenida allí, ya que la calidad externa del diseño crea confianza adicional en la información y existe la sensación de que el desarrollador no entendió algo.

Por otro lado, generar un informe de este tipo requiere un esfuerzo mínimo por parte del solicitante, que no se molesta en comprobar si hay un problema real, sino que simplemente copia a ciegas los datos recibidos de los asistentes de IA, esperando tener suerte en la lucha por recibir una recompensa.

Daniel Stenberg, comparte dos ejemplos de este tipo de informes basura:

  1. En el primer caso, justo antes de la divulgación planificada de la información sobre una vulnerabilidad crítica en octubre, se recibió un informe a través de HackerOne indicando que ya existía un parche público para resolver el problema. Sin embargo, el informe resultó ser «falso», ya que contenía datos sobre problemas similares y fragmentos de información detallada sobre vulnerabilidades pasadas, compilados por el asistente de inteligencia artificial de Google, Bard. Aunque la información parecía novedosa y relevante, carecía de conexión con la realidad.
  2. En el segundo caso, se recibió un informe sobre un desbordamiento de búfer en el manejo de WebSocket. Este informe provenía de un usuario que ya había informado sobre vulnerabilidades a varios proyectos a través de HackerOne. Para reproducir el problema, el informe proporcionaba instrucciones generales sobre cómo enviar una solicitud modificada y un ejemplo de corrección.

A pesar de verificar detalladamente tres veces el código, el desarrollador no encontró ningún problema. Sin embargo, dado que el informe estaba redactado de tal manera que generaba “cierta” confianza e incluso presentaba una solución propuesta, persistía la sensación de que algo no encajaba.

En un esfuerzo por aclarar cómo el usuario logró eludir la verificación de tamaño, se menciona que las explicaciones no contenían información adicional y solo analizaban causas comunes obvias de desbordamiento de búfer no relacionadas con el código de Curl. Las respuestas recordaban a la comunicación con un asistente de IA, y después de intentos inútiles para descubrir exactamente cómo se manifestaba el problema, Daniel Stenberg finalmente se convenció de que en realidad no existía ninguna vulnerabilidad y cerro el tema como no “aplicable”.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

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

El modo incógnito de Google, solo tiene de incógnito el nombre 

incógnito

Google fue demandado por engañar a los usuarios en su modo «incógnito»

Hace pocos días, se dio a conocer información sobre una demanda colectiva con la cual está lidiando Google y en la cual Google ha anunciado importantes cambios en la advertencia asociada al modo incógnito en su popular navegador web, Chrome.

Y es que ante la reciente demanda, Google ha llegado a un acuerdo para resolver litigios relacionados con violaciones de privacidad y realizar modificaciones que tienen como objetivo proporcionar a los usuarios una comprensión más clara de las limitaciones de privacidad en este modo «semiprivado».

Google fue acusado de violar las leyes federales de escuchas telefónicas de Estados Unidos y las leyes de privacidad de California. La demanda alega que Google podría utilizar datos analíticos de sus diferentes servicios, cookies del navegador y sus aplicaciones para rastrear la actividad del usuario cuando Chrome está habilitado en modo incógnito, así como cuando utiliza el modo de navegación privada en otros navegadores. Este tipo de seguimiento proporcionaba acceso incontrolado a información sobre amigos, pasatiempos, comidas favoritas, hábitos de compra y cosas vergonzosas que los usuarios no querían revelar y creían que estaban usando el modo incógnito para proteger su privacidad.

También se menciona que Google ha elegido el nombre engañoso «incógnito», que da la impresión de que el usuario recibe anonimato y protección contra la actividad de navegación, en lugar de simplemente no almacenar el historial de navegación y borrar datos relacionados con el sitio, como las cookies. La controversia destaca la importancia de la transparencia por parte de las grandes empresas tecnológicas en cuanto a las prácticas de privacidad, así como la necesidad de que los usuarios estén informados sobre las limitaciones reales del modo incógnito.

La demanda alega que Google rastrea a los usuarios de Chrome en sitios web propios y de terceros, incluso cuando se activa el modo incógnito, del cual Google sostiene que este modo está diseñado para evitar el almacenamiento local de datos, no para evitar el seguimiento en línea, la nueva advertencia busca aclarar aún más estas distinciones.

Google reconoce que, aunque otros usuarios en el mismo dispositivo no verán la actividad en modo incógnito, los sitios web y servicios, incluidos los de Google, aún pueden recopilar datos. La actividad, como descargas, favoritos y elementos de la lista de reproducción, se almacenará.

Este cambio en la advertencia destaca la importancia de educar a los usuarios sobre la privacidad en línea. Aunque el modo incógnito puede ofrecer cierta protección, no es suficiente para garantizar la privacidad completa en la web.

El acuerdo, aún pendiente de aprobación judicial, incluye cambios en la advertencia del modo incógnito, y Google deberá proporcionar información adicional en su sitio web y campañas publicitarias. Como parte de esta iniciativa, se ha implementado una advertencia en Chrome Canary, la versión nocturna para desarrolladores.

El resultado de esta demanda podría tener un impacto significativo en las regulaciones de privacidad en línea y en cómo las empresas abordan la comunicación de sus funciones de privacidad.

Los términos del acuerdo no fueron revelados, pero la demanda original se presentó en el 2020, y de manera inicial la demanda pretendida cubrir a “millones” de usuarios de Google desde el 1 de junio de 2016 y pedía al menos 5.000 dólares en daños y perjuicios por usuario por violaciones de las leyes federales de escuchas telefónicas y de privacidad de California.

Hasta el momento, solo se han resuelto algunos cambios que han sido acordados por las partes en conflicto, además de que aún deben ser aprobados por un juez federal en una audiencia programada para el 24 de febrero, ya que la audiencia fue aplazada en diciembre de 2023, para poner fin a la disputa.

Finalmente, cabe mencionar que ningún navegador ofrece el 100% de privacidad ni anonimato al usuario, lo que si, es que entre los diferentes navegadores existentes, podremos encontrar navegador web (como por ejemplo brave) que ofrecen capas adicionales de protección de los datos del usuario, pero esto no los vuelve 100%  eficientes en ello, pues incluso navegadores como Tor (para la dark web) tiene sus fallos.

Fuente: https://www.reuters.com/

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

NTPsec, una implementación mejorada de NTP

ntpsec

logo de ntpsec

NTPsec es un proyecto de código abierto que se centra en el desarrollo de una implementación segura y mejorada del Protocolo de Tiempo de Red (NTP), el cual es ampliamente utilizado para sincronizar los relojes de los sistemas informáticos en una red, asegurando una medición precisa y consistente del tiempo.

Este tipo de componentes, suelen ser los que la mayoría de los usuarios ignoramos (y me incluyo porque hasta hace algunos meses no había comprendido la importancia de este pequeño protocolo), ya que al ser algo que está detrás de nuestro día a día, es algo que pasa desapercibido.

En mi caso descubrí la importancia de NTP al querer realizar una «simple actualización» de mi sistema (Arco Linux) que deje durante varios meses sin abrir. Para no hacer el cuento largo, después de que se descargaron todas las actualizaciones y en teoría se debían instalar, simplemente no se instalaron, pues me aparecían un problema con las claves OpenPGP de los paquetes y por obvias razones de haber dejado el sistema durante meses, esto hiba a generar un grave problema.

Después de haber hecho 101 y una cosas e intentar de todo e incluso exorcizar a mi equipo, simplemente no podía resolver mi problema y la solución más próxima era volver a instalar el sistema desde cero, algo que no era de mi agrado.

Algo que note durante todo el proceso de intentar solucionar el problema, es que la hora de mi sistema era diferente a la de mi localidad e investigando un poco ese pequeño cambio horario generaba un problema al intentar importar las claves nuevas (tal y como lo menciona la bendita wiki de arch). Al leer esto, una palmada en mi frente fue lo primero que genero y procedí a intentar cambiar la hora e inmediatamente procedí a reiniciar para verificar si la fecha y hora del BIOS eran correctos, lo cual asi era. Posterior a ello volví a iniciar el sistema a disponerme a realizar el cambio como si de un proceso común en Windows o Android se tratara, y lo cual fue grave error de tener las costumbres antes de analizar.

Por más que intente resolver el problema de una forma u otra, lo que generaba el problema en mi sistema era el paquete ntp de mi instalación, por alguna razón que nunca pude resolver el paquete simplemente me estaba causando problemas. Aquí es donde encontré NTPsec la cual fue mi solución después de varias ahora de intentar solucionar mi problemática.

NTPsec es una implementación mejorada de NTP que cuenta con muchas mejoras de seguridad, pues cuenta con la implementación del estándar Network Time Security de IETF para una autenticación criptográfica sólida del servicio horario. En total, más del 74% del código base de NTP Classic se ha eliminado por completo, y se ha agregado menos del 5% de código nuevo al núcleo crítico para la seguridad y también hay un uso más consistente de la precisión de nanosegundos.

Entre las mejoras de seguridad, se eliminaron modos y funciones obsoletas, se adoptó el estándar RFC de Minimización de datos del cliente NTP y se incorporó la seguridad de tiempo de red. Además, se realizaron cambios en la sincronización horaria y mejoras en las herramientas del cliente, con nuevas utilidades como ntpmon y ntpviz para monitoreo en tiempo real y visualización de datos, respectivamente.

Explicando un poco esto, podemos entender un poco más la importancia de este «pequeño» componente que, para un usuario normal le dio varios dolores de cabeza y en entornos críticos no quiero imaginar el desastre que puede generar.

Dada una «no tan extensa» explicación de la importancia de NTP, la razón de contar mi pequeña “aventura” es porque hace poco fue lanzada la nueva versión de NTPsec 1.2.3 :

Entre las mejoras en la nueva versión se incluyen:

  • Alineación modificada de los paquetes del protocolo de control Mode 6, lo que podría afectar la compatibilidad con NTP clásico. El Mode 6 se utiliza para transmitir información sobre el estado del servidor y cambiar el comportamiento en tiempo real.
  • Se ha implementado el algoritmo de cifrado AES de forma predeterminada en ntpq.
  • Utilización del mecanismo Seccomp para bloquear nombres de llamadas al sistema incorrectas.
  • Se ha habilitado la recopilación de estadísticas con reinicio cada hora, con registros adicionales para NTS, NTS-KE y ms-sntp.
  • Inclusión de la opción «update» en buildprep.
  • Mejoras en la presentación de datos de retardo de paquetes en la salida JSON de ntpdig.
  • Se añadio soporte para la lista ecdhcurves.
  • Se corrigió la compilación en plataformas que -fstack-protector dependen de libssp, como musl.
  • Se corrigió el fallo de ntpdig al utilizar 2.ntp.pool.org con un host sin soporte IPv6.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

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

Nuevo «ataque» a los paquetes snap de Canonical, esta vez por parte de Valve

Paquetes snap rotos

Aunque mi compañero Diego los defiende, le gustan y recomienda, por lo menos algunos de ellos y como mínimo no ataca al tipo de paquete, creo que no me equivoco si afirmo que está muy poco acompañado en su postura. Canonical hizo oficial la disponibilidad de los paquetes snap en 2016 con Ubuntu 16.04 Xenial Xerus, nos prometió el cielo y yo sólo leo comentarios negativos de la comunidad Linux. En mi caso concreto, y me consta que no soy el único, he llegado a deshacerme de ellos completamente.

Lo que sí triunfa son los flatpak, y en Flathub, el repositorio más popular, encontramos prácticamente todo. Por poner algunos ejemplos, el navegador Vivaldi, Bottles o casi la totalidad de las aplicaciones del círculo de GNOME. Gustan más, y también parece ser que presentan menos problemas. En muchas ocasiones son los desarrolladores de los diferentes programas los que los suben, a diferencia de lo que pasa en Snapcraft que mucho lo reempaqueta Canonical. Esto mismo pasa con el paquete snap de Steam, y Valve desaconseja su uso tras los muchos reportes de bugs que está recibiendo.

Valve desaconseja el uso de los paquetes snap, por lo menos el de Steam

Hace mucho tiempo, para ser honesto no recuerdo cuándo ni dónde leí cierta información, pudo ser incluso aquí en LXA pero no lo encuentro en el archivo, se hablaba del buen trabajo que estaba haciendo Canonical con el paquete snap de Steam, hasta el punto de que se echaban ciertas pullitas a otras opciones. Ahora, algunos meses o años después, Valve está recibiendo cada vez más quejas de usuarios que reportan bugs con este paquete, por lo que recomiendan usar la versión .deb que ellos mismos empaquetan o por lo menos usar el paquete flatpak.

Ha sido Timothee Besset quien lo ha publicado en Mastodon (vía GamingOnLinux):

«Valve está recibiendo un número creciente de informes de errores por problemas causados por el reempaquetado de Canonical del cliente de Steam a través de snap.

La mejor manera de instalar Steam en Debian y sistemas operativos derivados es seguir las instrucciones en http://repo.steampowered.com/steam y utilizar el .deb oficial.

No estamos involucrados en el reempaquetado snap. Tiene muchos problemas.

Si no quieres el .deb, por favor considera al menos la versión flatpak».

La versión flatpak no está verificada, pero eso no significa que un proyecto no esté involucrado. Tampoco lo está Vivaldi Browser, y quien lo sube forma parte del equipo oficial. Lo que sí es seguro es que no tienen nada que ver con el reempaquetado del snap, y que éste está presentando muchos problemas que escapan a su control.

No es un ataque, pero…

Lo comentado por Timothee Besset no es un ataque directo y gratuito a los paquetes snap. Es sencillamente contar un hecho que está ocurriendo. Si los usuarios de Steam se quejan del mal funcionamiento del programa y el programa lo están editando de alguna manera terceros desarrolladores, poco o nada pueden hacer para identificar el problema y encontrar una solución.

Lo mejor para los usuarios de Debian/Ubuntu es usar el paquete .deb, que es lo nativo y sale directamente del horno de Valve. Después, el paquete flatpak. Para el resto de distribuciones, pues dependerá. Si no tienen problemas con el paquete snap, no deja de ser una opción, pero debería tomarse en consideración después del flatpak.

Y para los que no quieran ni lo uno ni lo otro, la opción que les que da es ver si su distribución Linux lo ofrece en sus repositorios oficiales. Yo desde aquí lo único que puedo hacer es recomendar lo mismo que Valve, y el paquete snap debería ser lo último por probar.

Los usuarios de una distribución basada en Debain/Ubuntu pueden descargar la última versión de Steam en formato .deb desde la página web oficial de Steam. En este otro enlace hay información para hacerlo manualmente. Los usuarios de otras distribuciones Linux pueden encontrar el tarball aquí.

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

WINE 9.0 llega con soporte inicial para Wayland y mejor Direct3D, entre otras novedades

WINE 9.0

Ya lo dijimos el viernes pasado, que la versión estable podría llegar en cualquier momento. Pero, por lo menos yo, no me esperaba que fuera tan pronto. WineHQ ha lanzado WINE 9.0, y lo ha hecho tras sólo 5 Release Candidates. Si hubiera tenido que apostar, y tras un periodo navideño en el que se saltaron una, yo habría puesto mi dinero en la casilla de principios de febrero, pero habría perdido.

Entre las novedades hay una que yo creo que destaca, aunque quizá ya os lo hayáis imaginado e incluso puede que estéis cansados del tema. WINE 9.0 incluye soporte inicial para Wayland, aunque en estos momentos es una función que está marcada como experimental. Y es que gran parte de los usuarios que usamos WINE lo hacemos en Linux, y es en los sistemas basados en el kernel en donde hay muchos proyectos que se dirigen a Wayland seriamente.

Novedades más destacadas de WINE 9.0

  • WoW64:
    • Todas las transiciones de código Windows a Unix pasan por la interfaz syscall de NT. Se trata de un hito importante que marca la finalización del el trabajo de rearquitectura de varios años para convertir los módulos al formato PE e introducir una frontera adecuada entre los mundos Windows y Unix.
    • Todos los módulos que llaman a una biblioteca Unix contienen thunks WoW64 para permitir la llamada a la biblioteca Unix de 64 bits desde 32 bits. biblioteca Unix de 64 bits desde código PE de 32 bits. Esto significa que es posible ejecutar aplicaciones Windows de 32 bits en una instalación Unix de 64 bits. Esto se denomina llamado el nuevo modo WoW64, opuesto al viejo modo WoW64 donde las aplicaciones de 32 bits se ejecutan dentro de un Unix de 32 bits.
    • El nuevo modo WoW64 aún no está habilitado por defecto. Puede activarse pasando la opción –enable-archs=i386,x86_64 a configurar. Se espera que esto funcione para la mayoría de las aplicaciones, pero todavía hay algunas limitaciones.
    • El nuevo modo WoW64 permite por fin ejecutar aplicaciones de 32 bits en versiones recientes de macOS que eliminaron el soporte para procesos Unix de 32 bits.
  • Driver Wayland:
    • Existe un controlador gráfico Wayland experimental. Todavía es un trabajo en curso, pero ya implementa muchas características, como la gestión básica de ventanas, múltiples monitores, escalado de alta DPI, eventos de movimiento relativo y soporte Vulkan.
    • El controlador Wayland aún no está activado por defecto. Puede habilitarse a través de la clave de registro «KCU\Software\Wine\Drivers» ejecutando
      wine reg.exe add HKCU\\Software\Wine\Drivers /v Graphics /d x11,wayland y asegurándose de que la variable de entorno DISPLAY está desactivada.
  • ARM64:
    • La finalización de la separación PE/Unix significa que es posible ejecutar binarios Windows existentes en ARM64.
    • El cargador soporta la carga de módulos ARM64X y ARM64EC.
    • Se ha implementado la interfaz de emulación x86 de 32 bits. No se proporciona ninguna biblioteca de emulación con Wine en este momento, pero se puede utilizar una biblioteca externa que exporte la interfaz, especificando su nombre en el directorio
      «HKLM\Software\Microsoft\Wow64\x86». El emulador FEX implementa esta interfaz cuando se construye como PE.
    • Existe soporte inicial para construir Wine para la arquitectura ARM64EC, utilizando una cadena de herramientas LLVM experimental. Una vez que la cadena de herramientas esté lista, se utilizará para realizar una compilación ARM64X adecuada y habilitar la emulación x86 de 64 bits.
  • Gráficos:
    • El controlador PostScript se ha reimplementado para trabajar a partir de archivos spool con formato Windows y evitar cualquier llamada directa desde el lado Unix.
    • La tematización de WinRT admite una opción de tema oscuro, con la correspondiente conmutación en WineCfg.
    • El controlador Vulkan soporta hasta la versión 1.3.272 de la especificación Vulkan.
    • Varias funciones de GdiPlus se han optimizado para mejorar el rendimiento gráfico.
  • Direct3D:
    • El flujo de comandos multihilo duerme en lugar de girar cuando no está procesando comandos de renderizado. Esto reduce el consumo de energía en programas que no ocupan todo el ancho de banda disponible del flujo de comandos. El consumo de energía debería ser comparable a cuando el flujo de comandos multihilo está desactivado.
      deshabilitado.
    • Los efectos de Direct3D 10 admiten muchas más instrucciones.
    • Se han realizado varias optimizaciones en el núcleo de WineD3D y en el backend de Vulkan.
    • El renderizador Vulkan valida correctamente que las características requeridas son soportadas por el dispositivo subyacente, e informa a la aplicación del nivel de característica Direct3D correspondiente.
    • Se han implementado D3DXFillTextureTX y D3DXFillCubeTextureTX.
    • El shader ARB de OpenGL admite el muestreo de sombras mediante ARB_fragment_program_shadow.
    • El compilador HLSL admite los indicadores de compilación de mayoría de matrices.
    • D3DXLoadMeshHierarchyFromX y las funciones relacionadas admiten la carga de datos de usuario a través de ID3DXLoadUserData.
  • Audio y vídeo:
    • Se implementa la base de varios de los módulos de DirectMusic. Se añaden muchas pruebas para validar el comportamiento del secuenciador dmime y del sintetizador MIDI dmsynth.
    • Se implementa la carga de fuentes de sonido DLS1 y DLS2, así como el formato SF2 para compatibilidad con las fuentes de sonido MIDI estándar de Linux.
    • La reproducción MIDI está implementada en dmsynth, con la integración del sintetizador software de la librería FluidSynth, y utilizando DirectSound para la salida de audio.
    • El desplazamiento Doppler está soportado en DirectSound.
    • Se ha implementado el decodificador de vídeo Indeo IV50 para Windows.
  • Otras mejoras en DirectShow, dispositivos de entradas, integración con el escritorio e Internet y redes, disponibles en la nota de lanzamiento.

WINE 9.0 es la nueva versión estable del software y se puede descargar desde el siguiente botón. A partir de ahora lanzarán alguna estable correctiva (9.0.1, 9.0.2…) y empezarán con las de desarrollo (9.1, 9.2), éstas ya para preparar el WINE 10 de 2025.

.boton {color: white; background-color: grey; padding: 20px; font-size: 2rem; text-decoration: none; border-radius: 10px; position: relative; top: 15px; border: 4px solid #555;}.boton:hover {box-shadow:1px 1px 2.5px black !important;}

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