Wine-Wayland 7.7 ha sido lanzado, un nuevo desarrollo con un conjunto de parches y el controlador winewayland.drv que permite usar la capa de compatibilidad WINE en entornos basados en el protocolo gráfico Wayland, sin usar los componentes XWayland y X11 como había que hacer con anterioridad. Esto brinda una gran capacidad para ejecutar todo tipo de software nativo de Microsoft Windows, y especialmente juegos que usan la API gráfica Vulkan y Direct3D 9, 11 y 12. La compatibilidad con Direct3D viene mediante DXVK que, como sabrás si nos lees, es el que traduce las llamadas de la API de Microsoft a Vulkan.

El kit Wine-Wayland también viene con parches y fsync para aumentar el rendimiento de los juegos que usan varios hilos de ejecución, así como código para soportar tecnologías como AMD FSR (FidelityFX Super Resolution), y reducir así la pérdida de calidad de los gráficos generados cuando se escalan a pantallas con alta resolución. Por otro lado, esta nueva versión se sincroniza con el código base Wine 7.7, por lo que tiene todas sus funciones y mejoras, así como actualizaciones de componentes como DXVK y VKD3D-Proton.

Por otro lado, esto no solo trae cosas positivas para los usuarios que hagan uso de esta capa de compatibilidad, también hay algunas cosas buenas para los desarrolladores de distribuciones. Wine-wayland permitirá su uso en entornos con Wayland sin necesidad de otros paquetes intermedios como los citados anteriormente. Esto significa que habrá mayor rendimiento y capacidad de respuesta al eliminar capas intermedias. Y no solo eso, también se dejan atrás los problemas de seguridad inherentes de X11, y se dispondrá de todas las nuevas funciones que se han incluido en Wayland para los entornos de escritorio más actuales.

Sin duda grandes esfuerzos de cara a eliminar la barrera de la compatibilidad y el problema de que los desarrolladores a veces solo miran hacia el lado de la empresa de Redmond…

Más información sobre Wine-Wayland, código fuente y descarga – Sitio de GitHub

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

Red Hat dio a conocer el lanzamiento de la nueva versión de su distribución «Red Hat Enterprise Linux 9» la cual, de acuerdo con el ciclo de soporte de 10 años para la distribución RHEL 9, se mantendrá hasta 2032 y que ademas las actualizaciones para RHEL 7 se seguirán publicando hasta el 30 de junio de 2024, RHEL 8 hasta el 31 de mayo de 2029.

La distribución Red Hat Enterprise Linux 9 se destaca por su paso a un proceso de desarrollo más abierto. A diferencia de las sucursales anteriores, la base del paquete CentOS Stream 9 se utiliza como base para construir la distribución.

Principales novedades de Red Hat Enterprise Linux 9

Esta nueva versión de la distribucion llega con el kernel de Linux 5.14, RPM 4.16 con soporte para control de integridad a través de fapolicyd, GNOME 40 y la biblioteca GTK 4, ademas de que se completó la migración de la distribución a Python 3, siendo en está nueva versión de RHEL la versión predeterminada de Python 3.9 y marcando el final de Python 2 ya que ha sido descontinuado.

De forma predeterminada, el menú de inicio de GRUB está oculto si RHEL es la única distribución instalada en el sistema y si el último inicio se realizó correctamente. Para mostrar el menú durante el arranque, simplemente se debe mantener presionada la tecla Shift o la tecla Esc o F8 varias veces. De los cambios en el gestor de arranque, también se observa la ubicación de los archivos de configuración de GRUB para todas las arquitecturas en el mismo directorio /boot/grub2/ (el archivo /boot/efi/EFI/redhat/grub.cfg ahora es un enlace simbólico a / boot/grub2/grub.cfg), esos. el mismo sistema instalado se puede iniciar usando EFI y BIOS.

De forma predeterminada, está habilitada una única jerarquía de cgroup unificada (cgroup v2). Cgroups v2 se puede usar, por ejemplo, para limitar el consumo de memoria, CPU y E/S. La diferencia clave entre cgroups v2 y v1 es el uso de una jerarquía de cgroups común para todos los tipos de recursos, en lugar de jerarquías separadas para asignación de CPU, administración de memoria y E/S. Las jerarquías separadas generaban dificultades para organizar la interacción entre los controladores y costos adicionales de los recursos del kernel al aplicar reglas para un proceso mencionado en diferentes jerarquías.

Se mejoró significativamente el rendimiento de SELinux y se redujo el consumo de memoria. Se eliminó el soporte para configurar «SELINUX=deshabilitado» para deshabilitar SELinux en /etc/selinux/config (la configuración especificada ahora solo deshabilita la carga de políticas y, de hecho, deshabilitar la funcionalidad de SELinux ahora requiere pasar «selinux=0» al kernel).

Tambien se destaca que se agregó soporte para sincronización horaria precisa basada en el protocolo NTS (Network Time Security), que utiliza elementos de una infraestructura de clave pública (PKI) y permite el uso de TLS y cifrado autenticado AEAD (Cifrado autenticado con datos asociados) para la protección criptográfica del cliente -interacción del servidor sobre el protocolo NTP (Network Time Protocol). El servidor chrony NTP se ha actualizado a la versión 4.1.

Ademas de ello se destaca que se proporcionó soporte experimental (Vista previa de la tecnología) para KTLS (implementación de TLS a nivel de kernel), Intel SGX (Extensiones de protección de software), DAX (Acceso directo) para ext4 y XFS, soporte para AMD SEV y SEV-ES en el hipervisor KVM.

De los demás cambios que se destacan:

• Se agregó soporte experimental para VPN WireGuard .
• De forma predeterminada, el inicio de sesión SSH como root está deshabilitado.
• Se eliminó el paquete de scripts de red, se debe usar NetworkManager para configurar las conexiones de red.
• Se ha conservado la compatibilidad con el formato de configuración de ifcfg, pero NetworkManager tiene un formato predeterminado basado en el archivo de claves.
• Paquetes de servidor actualizados Apache HTTP Server 2.4.48, nginx 1.20, Varnish Cache 6.5, Squid 5.1.
  DBMS actualizado MariaDB 10.5, MySQL 8.0, PostgreSQL 13, Redis 6.2.
• SSSD (System Security Services Daemon), se aumentó el detalle de los registros.
• Se ha ampliado la compatibilidad con IMA

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

Obtener Red Hat Enterprise Linux

Las imágenes de instalación listas para usar pronto estarán disponibles para los usuarios registrados del Portal de clientes de Red Hat (también puede usar imágenes iso de CentOS Stream 9 para evaluar la funcionalidad).

La versión está diseñada para las arquitecturas x86_64, s390x (IBM System z), ppc64le y Aarch64 (ARM64). Las fuentes de los paquetes de Red Hat Enterprise Linux 9 rpm se encuentran en el repositorio CentOS Git.

from Linux Adictos https://ift.tt/6x3EAo5
via IFTTT

Hace pocos dias, Miguel Ojeda, encargado del desarrollo y envió de estas propuestas y autor del proyecto Rust-for-Linux dio a conocer la séptima propuesta de los componentes para el desarrollo de controladores de dispositivos Rust para que los desarrolladores del kernel de Linux los consideren.

Esta es la séptima edición de los parches y a lo cual aun el soporte de Rust se considera experimental, pero ya está incluido en la rama linux-next y es lo suficientemente maduro como para comenzar a trabajar en la creación de capas de abstracción sobre los subsistemas del kernel, así como en la escritura de controladores y módulos. El desarrollo está financiado por Google y el ISRG (Internet Security Research Group), que es el fundador del proyecto Let’s Encrypt y promueve HTTPS y el desarrollo de tecnologías para aumentar la seguridad de Internet.

Los cambios propuestos hacen posible el uso de Rust como segundo lenguaje para desarrollar controladores y módulos del kernel. El soporte de Rust se presenta como una opción que no está habilitada de forma predeterminada y no da como resultado la inclusión de Rust entre las dependencias de compilación requeridas para el kernel. El uso de Rust para desarrollar controladores le permitirá crear controladores mejores y más seguros con un esfuerzo mínimo, sin problemas como acceder a un área de memoria después de liberarla, desreferenciar punteros nulos y desbordamientos de búfer.

Principales novedades en la séptima propuesta

En esta nueva propuesta se destaca que el kit de herramientas y una variante de la biblioteca alloc, que eliminó la posible generación de estado de «panic» en los errores, se actualizó a la versión Rust 1.60 y que con lo cual se estabiliza el soporte para el modo «may_uninit_extra» utilizado en los parches del kernel.

Ademas de ello, se destaca que se agregó la capacidad de ejecutar pruebas desde la documentación (pruebas que se usan simultáneamente como ejemplos en la documentación), al convertir las pruebas en tiempo de compilación vinculadas a la API del kernel en pruebas KUnit que se ejecutan en el momento del arranque del kernel. Se requiere que las pruebas no produzcan una advertencia de linter de Clippy, al igual que el código central de Rust.

Por otra parte se propone una implementación inicial del módulo «net» con funciones de red. El código Rust proporciona acceso a las estructuras de red del kernel como «Namespace» (basado en la estructura del kernel «struct net»), SkBuff (struct sk_buff), TcpListener, TcpStream (struct socket), Ipv4Addr (struct in_addr), SocketAddrV4 (struct sockaddr_in) y sus equivalentes IPv6.

El backend rustc_codegen_gcc, ha implementado la capacidad de arrancar el compilador rustc. La puesta en funcionamiento del compilador se refiere a la capacidad de rustc para usar un generador de código basado en GCC para construir el compilador rustc.

Además, la versión reciente de GCC 12.1 incluye correcciones a libgccjit necesarias para que rustc_codegen_gcc funcione correctamente. Se están realizando preparativos para proporcionar la capacidad de instalar rustc_codegen_gcc utilizando la utilidad rustup.

De los demás cambios que se destacan de esta nueva version:

• Soporte inicial implementado para métodos de programación asíncrona (async), implementado en forma de módulo kasync.
• Se agregó el módulo net::filter para manipular los filtros de paquetes de red. Ejemplo agregado rust_netfilter.rs con implementación de filtro en lenguaje Rust.
• Se agregó la implementación de un mutex simple smutex::Mutex que no requiere fijación.
• Se agregó un bloqueo NoWaitLock que nunca espera a que se libere y, si está ocupado por otro subproceso, genera un error al intentar adquirir el bloqueo en lugar de detener a la persona que llama.
• Se agregó un bloqueo RawSpinLock, identificado con raw_spinlock_t en el kernel, que se aplica a las secciones que no pueden estar inactivas.
• Se agregó el tipo ARef para las referencias de objetos a los que se les aplica el mecanismo de conteo de referencias (siempre refuntadas).
• Se observan avances en el desarrollo del frontend gccrs de GCC con la implementación del compilador del lenguaje Rust basado en GCC. Actualmente hay dos desarrolladores de tiempo completo trabajando en gccrs.

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/AFwLuX6
via IFTTT

Hace pocos dias se dio a conocer el lanzamiento de la nueva versión de Tor 0.4.7.7, utilizado para organizar el trabajo de la red Tor anónima.

Tor 0.4.7.7 es reconocida como la primera versión estable de la rama 0.4.7, que ha estado en desarrollo durante los últimos diez meses. La rama 0.4.7 se mantendrá como parte del ciclo de mantenimiento regular: las actualizaciones se suspenderán después de 9 meses o 3 meses después del lanzamiento de la rama 0.4.8.x.

Tor ha lanzado 0.4.7.7 , la primera versión estable de Tor con soporte para control de congestión. El control de congestión eliminará el límite de velocidad de Tor actual, así como también reducirá la latencia al minimizar la longitud de las colas en los relevos. Dará como resultado mejoras significativas en el rendimiento de Tor, así como una mayor utilización de nuestra capacidad de red

Principales novedades de Tor 0.4.7.7

En esta nueva versión que se presenta de Tor, se agregó una implementación del protocolo RTT Congestion Control que regula el tráfico enrutado a través de la red Tor (control de flujo en el lado del cliente, nodos de salida y servicios onion, pero sin correlación de demora en diferentes lados). El protocolo tiene como objetivo superar las limitaciones de ancho de banda actuales y reducir el tamaño de las colas de retransmisión. Hasta ahora, la velocidad de un solo flujo de descarga a través de los nodos de salida y los servicios onion estaban limitados a 1 MB/s, ya que la ventana de envío tiene un tamaño fijo de 1000 celdas por flujo y se pueden enviar 512 bytes de datos en cada celda (flujo) con un retraso en la cadena de 0,5 seg = 1000*512/0,5 = ~1 MB/seg).

Para predecir el ancho de banda disponible y determinar el tamaño total de la cola de paquetes, el nuevo protocolo utiliza una estimación del tiempo de ida y vuelta (RTT), que sirve como criterio para limitar el envío de datos.

La simulación mostró que el uso del nuevo protocolo en los nodos de salida y los servicios onion conducirá a una disminución de los retrasos en las colas, la eliminación de las restricciones en la tasa de flujo, un aumento en el rendimiento de la red Tor y un uso más óptimo del ancho de banda disponible. Del lado del cliente, el soporte de control de flujo se ofrecerá el 31 de mayo en la próxima versión importante del Navegador Tor, construido en la rama Tor 0.4.7.

Se agregó protección Vanguards-lite simplificada contra ataques de anonimización de servicios onion de corta duración, lo que reduce el riesgo de detectar nodos de guardia de un servicio onion o cliente onion cuando el servicio ha estado funcionando durante menos de un mes (para servicios de onion que se ejecutan más de un mes, se recomienda usar el complemento vanguards).

La esencia del método es que los clientes y servicios onion seleccionan automáticamente 4 nodos de protección de ejecución prolongada («relé de protección de capa 2») para usar en el medio de la cadena, y estos nodos se almacenan durante un tiempo aleatorio (en promedio, un semana).

Otro de los cambios que se destaca de la nueva versión es para los servidores de directorio, en los cuales se ha implementado la capacidad de asignar el indicador MiddleOnly a los retransmisores mediante un nuevo método de consenso. El nuevo método implica mover la lógica de establecer el indicador MiddleOnly del nivel del cliente al lado de los servidores de directorio. Para los relés marcados como MiddleOnly, los indicadores Exit, Guard, HSDir y V2Dir se eliminan automáticamente y se establece el indicador BadExit.

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

¿Como obtener Tor 0.4.7 ?

Para poder obtener esta nueva versión, basta con dirigirnos al sitio web oficial del proyecto y en su sección de descargas podremos obtener el código fuente para su compilación. Puedes obtener el código fuente desde el siguiente enlace.

Mientras que para el caso especial de usuarios de Arch Linux podremos obtenerlo desde el repositorio de AUR. Solo que en estos momentos no se ha actualizado el paquete, puedes monitorearlo desde el siguiente enlace y en cuanto este disponible puedes realizar la instalación tecleando el siguiente comando:

yay -S tor-git

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

Y después de varias versiones preliminares de las que la última fue la beta, hace unos instantes se ha hecho oficial el lanzamiento de Fedora 36. Llega con novedades importantes, pero sin lugar a dudas hay dos que destacan sobre el resto. La primera es que usa GNOME 42, algo que no sorprende ya que, a diferencia de otros, este proyecto siempre usa la última versión de GNOME. El otro punto en el que destaca es el núcleo.

Fedora 36 usa la última versión del kernel de Linux, en la actualidad Linux 5.17. Por lo tanto, y aunque sabemos que las comparaciones son odiosas, el núcleo de la 36ª versión de Fedora es dos versiones más nuevo que el de Ubuntu. Cierto es que lo que lanzó Canonical hace poco menos de tres semanas fue una versión LTS, y para en este tipo de lanzamientos suelen quedarse en una versión Long Term Support del kernel.

Novedades más destacadas de Fedora 36

• GNOME 42. Entre el resto de escritorios tenemos Plasma 5.24 LTS, Xfce 1.16, LXQt 1.0, Cinnamon 5.2 y MATE 1.26.
• Linux 5.17.
• Se promete soporte completo para aplicaciones GTK4.
• Wayland por defecto para usuarios de GNOME con hardware NVIDIA, algo que también prometió Ubuntu pero al final dieron marcha atrás por recomendación de NVIDIA.
• Noto Fonts es la nueva fuente por defecto.
• Permisos de administrador por defecto en el instalador Anaconda.
• Las bases de datos RPM pasan a estar ahora en /var (hasta ahora estaban en /usr).
• Soporte para contenedores OCI/Docker en la pila rpm-ostree, lo que mejora las actualizaciones.
• Nuevos paquetes principales, como:
  • GCC 12.
  • GNU C 2.35.
  • LLVM 14.
  • OpenSSL 3.0.
  • Autoconf 2.71.
  • Ruby 3.1.
  • Rubygem Cucumber 7.1.0.
  • Ruby on Rails 7.0.
  • Golang 1.18.
  • OpenJDK 17.
  • libffi 3.4.
  • OpenLDAP 2.6.1.
  • Ansible 5.
  • Django 4.0.
  • PHP 8.1.
  • PostgreSQL 14.
  • Podman 4.0.
  • MLT 7.4.
  • Stratis 3.0.0
• Más información en las notas de este lanzamiento.

Para nuevas instalaciones, las imágenes ISO de Fedora 36 se pueden descargar en este enlace. También se puede instalar desde el mismo sistema operativo con el centro de software de la versión oficial o cualquiera de sus «spins».

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