WINE 9.2 llega con el motor Mono actualizado a la versión 9.0.0

WINE 9.2

El desarrollo de la próxima versión de este software para ejecutar aplicaciones de Windows en otros sistemas operativos dio comienzo hace dos semanas. En la noche del viernes de ayer en España, WineHQ lanzó WINE 9.2, y parece que se confirma definitivamente que han migrado a GitLab también para las notas de lanzamiento. Por todo lo demás, tenemos lo mismo de siempre: una nueva versión de desarrollo con decenas de cambios.

En total, la lista de novedades recoge 207 cambios, con una lista que se queda con 15 bugs corregidos. Entre lo más destacado, El motor Mono se ha actualizado a la versión 9.0.0, se han realizado varias correcciones en la bandeja del sistema y mejoras de excepciones en las plataformas ARM, a lo que se le suma el cuarto punto con las correcciones de errores habituales. Lo que viene es la lista con los 15 bugs corregidos.

Bugs corregidos en WINE 9.2

  • Quick3270 5.21: se bloquea al utilizar la función Conectar.
  • digikam 6.10 se bloquea al iniciarse.
  • vkGetDeviceProcAddr comportamiento no válido para las funciones de las extensiones no soportadas por el anfitrión Vulkan instancia.
  • digikam-7.1.0 se bloquea al iniciarse.
  • dlls/ws2_32/socket.c:839:17: error: ‘IP_ADD_SOURCE_MEMBERSHIP’ undeclared here.
  • __unDName falla al demanar un nombre.
  • El emulador Dolphin falla desde 5.0-17264.
  • LANCommander no arranca, imprime «código de error 0x8007046C» (ERROR_MAPPED_ALIGNMENT).
  • La clave de registro ShowSystray fue eliminada sin alternativa.
  • El cliente Elite Dangerous se queda atascado en una pantalla negra después de iniciarse.
  • Windows Sysinternals Process Explorer 17.05 muestra una interfaz de usuario incompleta (32 bits).
  • El instalador de Microsoft Webview 2 se queda colgado para siempre.
  • Epic Games Launcher 15.21.0 llama a una función no implementada cfgmgr32.dll.CM_Get_Device_Interface_PropertyW.
  • Kodu game lab se bloquea (con xnafx40_redist+dotnet48 preinstalado): Referencia de objeto no establecida a una instancia de un objeto.
  • user32:msg test_recursive_hook falla en Windows 7.

WINE 9.2 ya se puede descargar desde el botón que tenéis al final de este artículo. La próxima versión será WINE 9.3 y llegará el 23 de febrero con varias decenas de cambios más. Recordamos que, aunque estas versiones se ofrecen en algunas distribuciones Linux, son versiones de desarrollo.

.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/Usa1IvE
via IFTTT

Cyberus Technology libero el código del backend KVM de VirtualBox

VirtualBox KVM

VirtualBox KVM 

Hace poco se dio a conocer una noticia bastante importante, es que Cyberus Technology anuncio mediante una publicación de blog que su backend KVM para VirtualBox ahora es de código abierto y con ello en lugar de que VirtualBox utilice su propio módulo del kernel de Linux, VirtualBox ahora se puede utilizar con un backend KVM.

Para quienes desconocen de KVM (Kernel-based Virtual Machine) deben saber que es una tecnología de virtualización integrada en el núcleo del sistema operativo Linux. Funciona como un hipervisor, permitiendo la ejecución eficiente de múltiples máquinas virtuales en un sistema host Linux.

Visto de otra forma, al ser implementado como un módulo del kernel de Linux, KVM puede funcionar como un hipervisor, aprovechando las extensiones de virtualización que proporcionan las CPU modernas (Intel VT y AMD-V), extensiones de hardware que habilitan al procesador para ejecutar instrucciones específicas de virtualización de manera altamente eficiente.

Durante los últimos meses, el equipo de Cyberus Technology ha dedicado esfuerzos significativos para lograr la compatibilidad entre VirtualBox y KVM. La intención era fusionar las capacidades de administración multiplataforma y la interfaz de usuario intuitiva de VirtualBox con el potencial de KVM como hipervisor a nivel del kernel de Linux.

El backend KVM de Cyberus Technology permite a VirtualBox ejecutar máquinas virtuales utilizando el hipervisor KVM de Linux en lugar del módulo de kernel personalizado utilizado por VirtualBox estándar. El uso de KVM conlleva una serie de beneficios.

Nuestros clientes utilizan la virtualización para aislar diferentes dominios de seguridad entre sí. Dependen de un mayor refuerzo del sistema anfitrión para mayor seguridad. Este tipo de endurecimiento es necesario para obtener la certificación de organismos gubernamentales y, como resultado, requisitos estrictos para nuestros clientes.

Y ahora el esfuerzo ha rendido sus frutos, pues la combinación de VirtualBox y KVM representa un avance significativo en el campo de la virtualización en entornos Linux. Esta integración no solo ofrece un rendimiento superior, sino que también mejora la seguridad y la flexibilidad de las máquinas virtuales.

Con la integración de KVM, VirtualBox ahora puede proporcionar un soporte mejorado para máquinas virtuales Windows que se ejecutan en sistemas Linux. Además, la combinación de VirtualBox y KVM permite a los usuarios aprovechar las características únicas de ambos frentes. Esta flexibilidad da lugar a nuevos escenarios de uso, como la ejecución simultánea de VirtualBox y QEMU en hosts Linux.

Entre las características más importantes de la implementación se destacan las siguientes:

  • Rendimiento Mejorado: La integración con KVM permite que las máquinas virtuales aprovechen al máximo las capacidades de aceleración del hardware, garantizando un rendimiento óptimo.
  • Seguridad Reforzada: KVM, al ser basado en el kernel, proporciona una capa adicional de seguridad. VirtualBox se beneficia de esta estructura sólida, creando un entorno más seguro para las aplicaciones virtualizadas.
  • Soporte Avanzado para Windows: La integración de KVM permite un mejor soporte para máquinas virtuales Windows en sistemas Linux, especialmente importante en entornos donde la seguridad es primordial.
  • Ejecución Paralela QEMU/KVM: VirtualBox KVM puede funcionar en paralelo con QEMU/KVM, proporcionando una mayor flexibilidad en el entorno de virtualización.
  • Eliminación del Controlador del Kernel de VirtualBox: La integración con KVM elimina la necesidad del controlador del kernel de VirtualBox, simplificando la instalación y la administración de la plataforma.
  • Aprovechamiento de Capacidades de Virtualización Modernas: VirtualBox KVM puede aprovechar automáticamente las funciones de virtualización modernas compatibles con KVM, como APICv, para una gestión más eficiente.

Para los interesados en la implementación, deben saber que actualmente, VirtualBox KVM debe compilarse a partir del código fuente proporcionado por Cyberus Technology y de momento la plataforma Intel x86-64 es oficialmente compatible, ya que el soporte AMD se considera experimental.

Por otra parte, vale la pena mencionar que el código está escrito en C y C++ y se distribuye bajo la licencia GPLv3. El código de la implementación lo puedes consultar en el siguiente enlace. 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/wIjtlkA
via IFTTT

La beta de Blender 4.1 añade el soporte para las APU AMD Ryzen basadas en RDNA3

Blender

Blender es la suite de creación 3D gratuita y de código abierto

Después de casi tres meses del lanzamiento de la actual versión estable de Blender 4.0, el equipo de desarrollo dio a conocer hace poco las próximas actualizaciones en las cuales ha estado trabajando, siendo las versiones 4.1 (en estado beta) y 4.2 (en estado alfa).

La actualización de la información de la beta de Blender 4.1, nos muestra un poco de las mejoras significativas en las cuales el equipo Blender ha estado trabajando a tan solo unos cuantos meses de haber lanzado la versión 4.0.

Y no es por de meritar el trabajo que mencionan en tan poco tiempo, sino al contrario, pues es de aplaudir la mención de un aumento del 5% en el rendimiento en Linux, además del soporte para renderizado utilizando APU AMD Ryzen basadas en la arquitectura RDNA3.

Principales avances en la beta de Blender 4.1

En las notas de lanzamiento en la página de desarrolladores de Blender, se destacan ya los diversos cambios que se han realizado hasta el momento en esta beta de Blender 4.1 y entre las características notables se encuentra el soporte para OpenImageDenoise, una biblioteca abierta para filtros de eliminación de ruido de alto rendimiento en imágenes renderizadas mediante Ray Tracing. Esta funcionalidad es compatible con sistemas NVIDIA GeForce GTX 1600 y todas las series RTX, chips AMD basados en las arquitecturas RDNA2 y RDNA3, procesadores Intel Arc y la serie M de Apple (requiere MacOS 13 o posterior).

Además, Blender 4.1 Cycles ahora admite la renderización utilizando los chips gráficos integrados basados en RDNA3 de AMD, como los presentes en los modelos Ryzen 7000G y Ryzen 8000G y que se ha introducido la capacidad de desactivar la corrección del mapa de relieve, y se ha mejorado el rendimiento en un 5% en Linux y sus derivados.

Otra de las mejoras notables es en el modelado con el cambio en la opción «Suavizado automático». Ahora, en lugar de esta opción, se ha introducido un recurso de grupo de nodos modificadores. Esto significa que el estado base de las mallas es equivalente a tener activado «Auto Smooth» con un ángulo de 180 grados en versiones anteriores.

Por otra parte, se han agregado nuevos íconos para representar la división, unión e intercambio de áreas, se ha mejorado la indicación y retroalimentación del cursor del selector de color, se han realizado mejoras en el dibujo del marcador de animación y el redondeo de esquinas para menús y bloques emergentes y los editores de métodos de entrada (IME) ahora son compatibles con Wayland.

De las demás mejoras en Blender 4.1:

  • Se agrega una configuración de «simplificación» de renderizado que permite desactivar el cálculo de esquinas de la cara y normales personalizadas en la ventana gráfica.
  • Las teclas de forma ahora pueden bloquearse para protegerlas de ediciones accidentales en modo de escultura o edición.
  • Las normales de las esquinas de las caras se almacenan en caché y se recalculan en menos casos.
  • La creación de mapas de topología de malla utilizados en nodos de geometría y cálculo de normales está paralelizada y es hasta 5 veces más rápida.
  • Se ha mejorado la calidad del menú y las sombras de los bloques emergentes.
  • Ahora, el Image Editor permite rotar imágenes en incrementos de 90 grados.
  • El Image Vectorscope tiene una apariencia actualizada y la capacidad de mostrar un alcance de luma o teñido.
  • El operador Desagrupar ahora desagrupa todos los nodos del grupo seleccionados en lugar de solo el activo.
  • Se ha mejorado la selección de sockets al crear enlaces de nodos para reducir la cantidad de clics erróneos.
  • Se puede hacer doble clic en la colección Outliner para seleccionar todos los niños.
  • Ahora se pueden aplicar modificadores desde el esquema.
  • El modo Caminar ahora admite subida/bajada relativa.
  • Se ha mejorado el resaltado de borde de malla y el contraste para superposiciones de texto.
  • Se ha añadido texto sombreado para los atributos del Visor de nodos de geometría.

Para los interesados en poder dar un vistazo a las versiones alfa y beta ya están disponibles para pruebas descargando el software desde el siguiente enlace. Cabe mencionar que se espera que la versión final de Blender 4.1 se lance el 19 de marzo, mientras que la versión 4.2 de Blender su lanzamiento está previsto para el 16 de julio.

Si estás interesado en poder conocer más al respecto, pues consultar los detalles en el siguiente enlace.

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

Fedora Atomic Desktops, la nueva familia de spins inmutables de Fedora

Fedora Atomic Desktops

Justo hoy hablábamos de un sistema inmutable, el Ubuntu Core Desktop, para confirmar que no llegará este abril y puede que tampoco durante 2024. Por su parte, Fedora ha anunciado Fedora Atomic Desktops, una nueva familia de spins que pretende aprovechar el tirón de Silverblue para ofrecer un grupo de opciones inmutables de la popular distribución Linux. En redes sociales, como Mastodon, usan la palabra «newish», lo que no es más que otra manera de decir que es nuevo… más o menos.

La base de la historia o el actor protagonista es Silverblue. En los últimos meses ha ganado en popularidad, y debido a ello otras spins han dado un paso al frente y han ofrecido una versión que implementa rpm-ostree. Según explican, se ha llegado a un punto en el que es difícil hablar de ellos al mismo tiempo. Por lo tanto, la decisión ha sido fácil: crear una nueva marca que servirá para hablar sobre el tema y los futuros spins «Atomic».

Fedora Atomic Desktops incluye viejos conocidos

El proyecto Atomic empezó hace ya 10 años, pero no fue hasta 2018 que se lanzó Fedora Atomic Workstation, una implementación de cliente de escritorio que más tarde se convertía en Silverblue. En 2021 llegó Kinoite, y ya más recientemente Sericea y Onyx. El catálogo de los Fedora Atomic Spins quedaría así:

  • Fedora Silverblue.
  • Fedora Kinoite.
  • Fedora Sway Atomic (lo que era Fedora Sericea).
  • Fedora Budgie Atomic (lo que era Fedora Onyx).

El motivo de haber creado una marca es porque se espera que se sumen más spins a la lista. En la actualidad hay 4 más que aún no tienen variante Atomic, entre las que destaca Vauxite con Xfce. También esperan que entre en la familia otras con Pantheon (escritorio de elementary OS) o COSMIC (de Pop!_OS).

Es bueno tener una marca para facilitar las conversaciones; sin ella, es difícil referirse a algo en concreto. Por otra parte, se gana en precisión:

«En tercer lugar, este bonito término de marca es también una forma más precisa de hablar de cómo funciona rpm-ostree. Los spins atómicos de Fedora no son realmente inmutables. Hay formas de evitar los aspectos de sólo lectura de la implementación aunque es mucho más difícil. La naturaleza del sistema operativo, donde las actualizaciones sólo se implementan cuando se construyen exitosamente y se puede hacer rollback o rebase entre sistemas centrales anfitriones, se describe mejor por atomicidad que por inmutabilidad. Atómico es también como muchos de los colaboradores que trabajan en rpm-ostree prefieren hablar de ello. Rebranding proporciona una oportunidad para cambiar el lenguaje que rodea a esta tecnología«.

Los spins más populares mantienen su nombre

La marca Atomic acompañará a lo nuevo que vaya llegando, pero Silverblue y Kinoite mantienen su nombre. No tendría mucho sentido cambiárselo a algo que ya es reconocible, y haciéndolo sólo se generaría confusión. ¿Os imagináis que lo cambian y alguien encuentra este artículo o uno de los muchos vídeos que hay por la red? El caso de Onyx y Sericea es diferente. Son opciones mucho más nuevas y no habrá tanta confusión.

En el el futuro, los nuevos spins Atomic recibirán el nombre de Fedora «DE-nombre Atomic», y por poner unos ejemplos, podrían llegar algún momento no muy lejano Fedora Deepin Atomic o Fedora Cinnamon Atomic.

Qué es un sistema rpm-ostree

En un sistema rpm-ostree como los de la familia Fedora Atomic Desktops, el sistema de archivos raíz se compone de árboles de archivos inmutables generados a partir de paquetes RPM. Estos árboles de archivos son solo lectura y se pueden actualizar de forma atómica mediante la aplicación de un nuevo árbol. Esto permite actualizaciones consistentes y reversibles del sistema, lo que es útil para entornos de producción y contenedores. Dicho de otro modo, parte importante de su filosofía es la inmutabilidad.

Por supuesto, estos spins coexistirán con las versiones normales, es decir, las que gestionan el software con RPM. La más reciente es Fedora 39 y llegó el pasado noviembre.

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

Xfce actualiza los planes relacionados con agregar soporte para Wayland

Xfce

Logo de Xfce

Los desarrolladores de Xfce han actualizado su página con planes para agregar soporte para el protocolo Wayland. El plan ahora incluye la implementación inicial del soporte para Wayland en los componentes principales de la próxima versión importante de Xfce 4.20, manteniendo simultáneamente el soporte para X11, y es que anteriormente, hubo discusiones sobre mantener la compatibilidad con versiones anteriores de X11, pero ahora se ha decidido que el soporte para X11 no se suspenderá en el futuro.

En la actualización de información realizada, los desarrolladores de Xfce mencionan que la sesión basada en Wayland en Xfce 4.20 abordará el conjunto mínimo requerido de capacidades, con la intención de agregar gradualmente la funcionalidad que falta en futuras versiones. También se planea continuar perfeccionando el trabajo en un entorno basado en el protocolo Wayland en aplicaciones de usuario que ya han sido portadas.

Planes generales
Para Xfce 4.20, el plan es agregar soporte preliminar a Wayland a los componentes principales sin perder el soporte X11. Esto no significa que para el próximo lanzamiento importante una sesión de Xfce en Wayland ofrecerá todas las funciones existentes, pero esperamos que sea mínimamente utilizable. También tenemos la intención de seguir perfeccionando nuestras aplicaciones para que funcionen aceptablemente en Wayland (aquellas que ya funcionan o que se pueden hacer funcionar con poco esfuerzo).

Entre las directrices acordadas entre los desarrolladores de Xfce para realizar la transición a Wayland, se destacan las siguientes:

  1. Independencia de XWayland: Los componentes deben ser independientes de XWayland.
  2. Sin Configuraciones X: Se deben evitar las configuraciones específicas de X.
  3. Uso de wlroots sobre libmutter: Se prefiere wlroots sobre libmutter para el compositor.
  4. Compatibilidad con X11: Se debe mantener la compatibilidad con X11 en el futuro previsible.

Aunque no se ha establecido claramente en qué versión se completará la transición a Wayland, hay una serie de tareas importantes a abordar, pues se señala que el proyecto no cuenta con los recursos necesarios para mantener su propio administrador de composición para Wayland y se descarta la posibilidad de utilizar un enlace a XWayland para este propósito. La decisión previa de emplear la biblioteca wlroots en el entorno Wayland en lugar de libmutter, desarrollada por los creadores del entorno de usuario Sway y que proporciona funciones básicas para organizar el trabajo de un administrador de composición basado en Wayland, sigue en pie.

Por la parte del escritorio, xfdesktop y el panel xfce4, se menciona que estas ya han sido portados a Wayland utilizando wlroots y continuarán siendo desarrollados como componentes lanzados de forma independiente, además de que el panel xfce4 ha sido probado con servidores compuestos Labwc y Wayfire, mientras que por la parte de los complementos de xfce4-panel la mayoría de ellos ya cuentan con el soporte para Wayland, pero se trabajara para que el panel sea un compositor Wayland hasta cierto punto, esto debido a que ya no puede usar GtkSocket/GtkPlug para ejecutar complementos como externos, ahora estos deben ejecutarse internamente (es decir como un solo proceso) por lo que la falla de un complemento hace que el panel falle.

Para abstraer el trabajo en Wayland y X11, se utiliza la biblioteca libxfce4windowing, que proporciona una capa de abstracción del subsistema de gráficos donde se implementan componentes de administración de ventanas (pantallas, ventanas, escritorios virtuales, etc.) que no están vinculados a un sistema de ventanas específico. La compatibilidad con X11 se implementa utilizando libwnck.

Ademas de ello se menciona que se ha llevado a cabo la portabilidad de los siguientes componentes a Wayland:

  • exo
  • libxfce4ui
  • libxfce4util
  • thunar
  • xfce4-appfinder
  • xfce4-settings
  • xfconf
  • xfce4-power-manager
  • tumbler
  • garcon
  • thunar-volman
  • xfce4-dev-tools

Sin embargo, la compatibilidad con Wayland aún no está disponible en el administrador de sesiones xfce4-session y en el administrador de ventanas xfwm4, aunque existe un port xfwm4 no oficial para trabajar con Wayland.

Las aplicaciones que han agregado soporte para Wayland incluyen: xfce4-terminal, mousepad, xfce4-notifyd, xfce4-taskmanager, xfce4-mixer, ristretto, catfish, xfburn, parole, xfmpc, xfce4-dict, gigolo y xfce4-panel-profiles.

Aunque no se espera que una sesión de Xfce en Wayland ofrezca todas las funciones existentes, se espera que sea mínimamente utilizable. Además, se planea continuar perfeccionando las aplicaciones para que funcionen aceptablemente en Wayland.

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