Como cada dos semanas, y tras la v7.9, WineHQ lanzó anoche una nueva versión de desarrollo de su software para ejecutar aplicaciones de Windows en otros sistemas operativos, en esta ocasión WINE 7.10. Para algunos puede que sea una actualización poco importante, pero sí se incluye algo que mejora mucho la experiencia de usuario, hasta el punto de que permite usar algunas aplicaciones que de otra manera sería imposible o poco probable. Estamos hablando del motor Mono, lo que permite que se ejecuten apps que requieran .NET Framework.

Además, WineHQ menciona que se han corregido 56 bugs, lo que es cerca del doble de lo que suele corregir, y se han aplicado un total de 379 cambios. Una vez más, tenemos que recordar aquellas versiones en las que introdujeron más de 600, pero cerca de 400 está dentro de la media, por encima diría yo. De todo esto, lo más destacado según WineHQ es lo que tenemos a continuación.

Novedades más destacadas de WINE 7.10

Lo más destacado, sin duda, es que el motor Mono se ha actualizado a 7.3.0, pero el proyecto también menciona en su lista que el driver para macOS se ha pasado a PE, una colación Unicode compatible con Windows y soporte para Wow64 en Secur32, lista que se completa con el quinto punto en el que se mencionan correcciones varias.

WINE 7.10 está disponible desde este enlace, y no sé si seguir haciendo mención a la segunda opción porque nunca funciona. Ya, por curiosidad y haciendo un trabajo que no me corresponde, he accedido a ese servidor, he eliminado las últimas partes y he accedido a las de WINE 6.x, que sí funcionan. Por lo tanto, creo que publican el segundo enlace a modo de «placeholder», es decir, no funciona hoy, pero lo hará en el futuro. «Shit happens». En la página de descargas hay información sobre cómo instalar esta y otras versiones en sistemas operativos como Debian y Ubuntu, pero también se puede instalar en Android y macOS.

La próxima versión será un WINE 7.11 que llegará el 17 de junio. No sabemos cuántos cambios introducirán dentro de dos semanas, pero si deberían ser un par de cientos o más. Y por lo menos ya parece que sabemos lo que pasa con el segundo enlace, aunque la explicación no me satisfaga.

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

Hace algunas semanas compartimos aquí en el blog la noticia sobre el cambio del nombre del proyecto de MangoDB que permite reemplazar el DBMS orientado a documentos de MongoDB con PostgreSQL sin realizar cambios en el código de la aplicación.

El nuevo nombre del proyecto es FerretDB y recientemente se dio a conocer la liberación de la versión 0.3 del proyecto. La versión FerretDB 0.3 presenta el comando findAndModify, que modifica un documento pero devuelve su versión original, ademas de que se implementaron operadores de actualización de campo, entre otras cosas mas.

Para quienes aún desconocen de FerretDB, deben saber que este se implementa como un servidor proxy que traduce las llamadas a MongoDB en consultas SQL a PostgreSQL, lo que le permite usar PostgreSQL como almacenamiento real.

La necesidad de migración puede surgir en relación con la transición de MongoDB a una licencia SSPL no libre, que se basa en la licencia AGPLv3, pero no está abierta, ya que contiene un requisito discriminatorio para proporcionar bajo la licencia SSPL no solo la aplicación código en sí, sino también los códigos fuente de todos los componentes involucrados en la prestación del servicio en la nube.

El público objetivo principal de FerretDB son los usuarios que no utilizan las funciones avanzadas de MongoDB en sus aplicaciones, pero que desean utilizar una pila de software completamente abierta.

En la etapa actual de desarrollo, FerretDB aún admite solo una parte de las características de MongoDB que se usan con mayor frecuencia en las aplicaciones típicas. En el futuro, planean lograr una compatibilidad total con los controladores para MongoDB y brindar la capacidad de usar FerretDB como un reemplazo transparente para MongoDB.

MongoDB ocupa un nicho entre los sistemas rápidos y escalables que operan con datos clave/valor y los DBMS relacionales que son funcionales y fáciles de consultar.

MongoDB admite el almacenamiento de documentos en un formato similar a JSON, tiene un lenguaje bastante flexible para generar consultas, puede crear índices para varios atributos almacenados, proporciona almacenamiento eficiente de objetos binarios grandes, admite el registro de operaciones para cambiar y agregar datos a la base de datos, puede trabajar de acuerdo con el paradigma Map/Reduce, admite la replicación y la construcción de configuraciones tolerantes a fallas.

Debido a las diferencias en la semántica de las funciones json de PostgreSQL y MongoDB, hubo una discrepancia en el comportamiento al comparar y ordenar diferentes tipos. Para resolver este problema, ahora se extrae una muestra de datos redundantes de PostgreSQL y el filtrado del resultado se realiza en el lado de FerretDB, lo que hizo posible repetir el comportamiento de MongoDB en la mayoría de las situaciones.

Principales novedades de FerretDB 0.3

Tal y como se mencionó al inicio, la nueva versión de FerretDB 0.3 se destaca por introducir el comando findAndModify, que modifica un documento, pero devuelve su versión original.

Otros de los cambios que se destacan es que se ha mejorado el manejo del cero negativo, asi como tambien que se agregó el soporte para ordenar tipos de datos escalares.

Tambien se destacan los nuevos operadores de actualización de campo implementados: $inc y $set, además de que se agregó soporte para ordenar tipos de datos escalares.

Por otra parte, se menciona que se han realizado diversas mejoras para el manejo de las versiones de PostgreSQL y MongoDB.

Ademas de ello, también se destaca que se solucionó la prueba incorrecta para el operador $mod, tambien que se emite la prueba en todos los sistemas operativos ARM64 y que se agregó más visibilidad para los niveles de registro de errores del enrutador/proxy.

De los demás cambios que se destacan de esta nueva versión:

• Actualizar CODEOWNERS
• Sincronizar controladores ficticios y pg
• Renombrar OP_*constantes a OpCode*constantes
• Mejorar gopkg.in/yaml.v3
• Bump gopkg.in/yaml.v3 en herramientas
• Hacer tipo Path
• Pánico en valores de pedidos inesperados
• Agregue algunos comentarios a las funciones y variables
• Eliminar código muerto

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

Hace ya algunos días se dio a conocer la noticia que el repositorio de desarrollo de la versión Ubuntu 22.10 se movió para usar el servidor de medios PipeWire predeterminado para el procesamiento de audio.

Con este cambio, los paquetes relacionados con PulseAudio se han eliminado de los paquetes desktop y desktop-minimal, y por compatibilidad, en lugar de bibliotecas para interactuar con PulseAudio, se ha agregado una capa pipewire-pulse que se ejecuta sobre PipeWire, lo que le permite mantener todos los existentes clientes de PulseAudio funcionando.

La persona quien confirmo el cambio fue Heather Ellsworth de Canonical, quien mediante una publicación comento sobre la decisión de migrar completamente a PipeWire en Ubuntu 22.10.

Se observa que en Ubuntu 22.04 se usaron ambos servidores en la distribución: PipeWire se usó para procesar video al grabar screencasts y proporcionar acceso a la pantalla, pero el audio continuó procesándose usando PulseAudio. En Ubuntu 22.10, solo permanecerá PipeWire.

Así es, a partir de hoy, Kinetic iso (pendiente, aún no actual ya que se acaban de realizar los cambios) se ha actualizado para ejecutar solo pipewire y no pulseaudio. Asi que@copong, puede esperar esto para kinetic.

Para Jammy, puede notar que tiene tanto pipewire como pulseaudio ejecutándose. Esto se debe a que aún se usa pulseaudio para el audio, pero se usa pipewire para el video. (Se necesita Pipewire para transmitir y compartir pantallas en Wayland).

Espero que esto aclare nuestros planes con respecto a pipewire/pulseaudio, pero avísenos si tiene más preguntas.

Hace dos años, ya se implementó un cambio similar en la distribución de Fedora 34, que permitió brindar capacidades profesionales de procesamiento de audio, eliminar la fragmentación y unificar la infraestructura de audio para diferentes aplicaciones.

Para quienes desconocen de PipeWire, deben saber que este ofrece un modelo de seguridad avanzado que le permite administrar el acceso por dispositivo y por transmisión, lo que facilita la transmisión de audio y video desde y hacia contenedores aislados.

PipeWire puede procesar cualquier flujo de medios y puede mezclar y redirigir no solo flujos de audio, sino también flujos de video, así como administrar fuentes de video (dispositivos de captura de video, cámaras web o contenido de pantalla que muestran las aplicaciones). PipeWire también puede actuar como un servidor de audio de baja latencia y brindar una funcionalidad que combina las capacidades de PulseAudio y JACK , lo que incluye tener en cuenta las necesidades de los sistemas de procesamiento de audio profesionales que PulseAudio no podría reclamar.

De las características clave que se pueden destacar:

• Capacidad de capturar y reproducir audio y video con demoras mínimas
• Herramientas para el procesamiento de video y sonido en tiempo real
• Arquitectura multiproceso que permite organizar el acceso compartido al contenido de varias aplicaciones
• Modelo de procesamiento basado en gráficos de nodos multimedia con soporte para bucles de retroalimentación y actualizaciones de gráficos atómicos. Está permitido conectar controladores tanto dentro del servidor como en complementos externos
• Interfaz eficiente para acceder a secuencias de video a través de descriptores de archivos y acceso de audio a través de un búfer de anillo compartido
• Capacidad para procesar datos multimedia de cualquier proceso
• La presencia de un complemento para GStreamer para simplificar la integración con las aplicaciones existentes
• El soporte para entornos aislados y sistema de paquetes Flatpak
• El soporte para complementos en formato SPA (Simple Plugin API) y la capacidad de crear complementos que funcionan en tiempo real duro
• Sistema flexible para negociar formatos multimedia usados ​​y asignación de búfer
• Capacidad de poder usar un solo proceso en segundo plano para enrutar audio y video.
• La capacidad de actuar como un servidor de sonido, un centro para proporcionar video a las aplicaciones (por ejemplo, para la API de screencast de gnome-shell) y un servidor para controlar el acceso a los dispositivos de hardware de captura de video.

Finalmente para quienes estén interesados en poder conocer más al respecto sobre la nota, pueden consultar el hilo de la discusión en el siguiente enlace.

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