Los chicos de Fedora han estado trabajando con todo su entusiasmo y tiempo disponible para poder cumplir con el calendario de lanzamiento de la distribución pero, tal parece que este año sera otro año más en el que la fecha de lanzamiento de la distribución no sera cumplida, ademas de que también se dio a conocer información que para la próxima versión de la distribución que es Fedora 33 (en la cual ya sé esta empezando a trabajar) se realizara un pequeño cambio en el sistema que proporciona la resolución de nombres de red a aplicaciones de “nss-resolve” por “systemd-resolved”.

Para la implementación en Fedora 33, se planea que “systemd-resolved” reemplace a “nss-resolve” para resolver consultas DNS y Glibc se cambiará a nss-resolve desde el proyecto systemd en lugar del módulo NSS incorporado nss-dns.

systemd-resolved sustituirá a nss-resolve en Fedora 33

Este cambio se realiza debido a la decisión que se tomo de manera interna en Fedora que en lugar de optar por deshabilitar “systemd-resolved” (como se ha vendido haciendo desde ya hace tiempo) mejor se habilite.

Los desarrolladores comentan que systemd-resolve realiza funciones tales como mantener la configuración en el archivo resolv.conf basado en datos DHCP y una configuración DNS estática para interfaces de red, admite DNSSEC y LLMNR (Resolución de nombre de multidifusión local de enlace).

Entre las ventajas de cambiar a systemd-resolved está el soporte para DNS sobre TLS, la capacidad de habilitar el almacenamiento en caché local de consultas DNS y el soporte para vincular diferentes procesadores a diferentes interfaces de red (dependiendo de la interfaz de red, se selecciona un servidor DNS para acceder, por ejemplo, consultas DNS para interfaces VPN será enviado a través de VPN). No está planeado usar DNSSEC en Fedora (systemd-resolve se construirá con el DNSSEC = sin bandera).

Systemd-resolve ya se usa de manera predeterminada en Ubuntu a partir de la versión 16.10, pero la integración se realizará de manera diferente en Fedora, ya que para empezar Fedora actúa totalmente diferente a Ubuntu y ademas Ubuntu continúa usando nss-dns tradicionales de glibc, es decir glibc continúa manejando /etc/resolv.conf, mientras que Fedora espera reemplazar nss-dns con nss-resolve de systemd.

Para aquellos que no desean usar systemd-resolve, será posible deshabilitarlo y para ello se debe desactivar el servicio systemd-resolve.service y reiniciar NetworkManager, que creará el /etc/resolv.conf tradicional.

La versión final de Fedora 32 se retrasa una semana

Finalmente otro de los cambios que anunciaron los desarrolladores del proyecto de Fedora fue el aplazamiento del lanzamiento de la versión final de Fedora 32 por una semana debido al incumplimiento de los criterios de calidad.

El lanzamiento de Fedora 32 está previsto para el 28 de abril, en lugar del 21 de abril, como estaba previsto originalmente.

En las compilaciones de prueba finales que obligaron a los desarrolladores a aplazar el lanzamiento final se comentan al menos 3 problemas que se clasifican como bloqueo de la versión que permanecen sin corregir.

Los problemas que bloquean la versión incluyen: problemas con el reconocimiento de particiones LVM en modo de recuperación de fallos, congelación al intentar arrancar en sistemas con GPU NVIDIA Turing en modo “Arranque seguro” y la falta de la versión final del paquete f32-background en un repositorio estable.

Los desarrolladores esperan que estos fallos sean solucionados dentro del tiempo que estipularon para dar por sentada la fecha final (anteriormente mencionada), pero en caso de que no sea asi la fecha sera atrasada mas dias:

Debido a los errores de bloqueador abierto, Fedora 32 Final fue declarado “prohibido”. Nosotros nos reuniremos nuevamente a las 17:00 UTC del jueves 23 de abril para reevaluar, la situacion y dar a conocer el lanzamiento final de Fedora 32.

Si determinamos en ese momento que Fedora 32 está listo, se lanzará en la “fecha de lanzamiento prevista # 1” del 28 de abril.

Finalmente si quieres conocer más al respecto sobre los comunicados emitidos por los chicos de Fedora, puedes consultar los siguientes enlaces que proporcionamos.

Enlace sobre el cambio en Fedora 33.

Enlace sobre el atraso en la liberación de Fedora 32.

from Linux Adictos https://ift.tt/3blqXrp
via IFTTT

Roman Gilg, involucrado en el desarrollo de KDE, Wayland, Xwayland y X Server, presentó el proyecto KWinFT (KWin Fast Track), que desarrolla un administrador de ventanas compuesto flexible y fácil de usar para Wayland y X11, basado en la base de código KWin.

Además del administrador de ventanas, el proyecto también desarrolla una biblioteca wrapland con la implementación de enlaces sobre libwayland para Qt/C ++, que continúa el desarrollo de KWayland, pero se libera de la unión a Qt.

Sobre KwinFT

El objetivo del proyecto es reelaborar KWin y KWayland utilizando tecnologías modernas y prácticas de desarrollo que aceleren el desarrollo del proyecto, refactoricen el código, agreguen optimizaciones y simplifiquen la incorporación de innovaciones fundamentales, que son difíciles de integrar en KWin en su forma actual. KWinFT y Wrapland se pueden usar para reemplazar KWin y KWayland de manera transparente, pero no se limitan al marco impuesto a KWin por muchos productos, manteniendo una compatibilidad total con la cual es una prioridad que impide el avance de las innovaciones.

En KWinFT, los desarrolladores tienen las manos libres y pueden experimentar con nuevas características, buscando mantener la estabilidad mediante el uso de técnicas de desarrollo más modernas.

Por ejemplo, para verificar el código KWinFT, está involucrado un sistema de integración continua, que incluye la verificación utilizando diferentes linter, generación automática de ensamblaje y pruebas avanzadas. Con respecto al desarrollo de la funcionalidad, el enfoque principal de KWinFT será proporcionar un soporte completo y de alta calidad para el protocolo Wayland, incluida la reelaboración de las características arquitectónicas de KWin que complican la integración con Wayland.

Entre las innovaciones experimentales ya agregadas a KWinFT, se destacan las siguientes:

• El proceso de composición se rediseñó, lo que mejoró significativamente la representación del contenido bajo el control de X11 y Wayland. Además, se ha agregado un temporizador para minimizar los retrasos entre la creación y visualización de la imagen.
• Se implementó una extensión del protocolo “viewporter” de Wayland, que permite al cliente realizar acciones para escalar y recortar los bordes de la superficie en el lado del servidor. En combinación con la próxima versión principal de XWayland, la extensión le permitirá emular un cambio en la resolución de pantalla para juegos más antiguos.
• Soporte completo para la rotación y el reflejo de salida para sesiones basadas en Wayland.
• Wrapland proporciona una interfaz de programación de estilo Qt que proporciona acceso a las funciones de libwayland en una forma conveniente para su uso en proyectos C ++. Inicialmente, planearon desarrollar Wrapland como una bifurcación de KWayland, pero debido al estado insatisfactorio del código de KWayland, ahora se considera como un proyecto para el procesamiento completo de KWayland. La diferencia más importante entre Wrapland y KWayland es la eliminación de la unión a Qt y la posibilidad de usarlo por separado sin instalar Qt. En el futuro, Wrapland podrá usarse como una biblioteca universal con una API C ++, eliminando la necesidad de que los desarrolladores usen la API C libwayland.
• Los paquetes listos para usar están hechos para usuarios de Manjaro Linux. Para habilitar KWinFT, simplemente instale kwinft desde el repositorio, y para volver al KWin normal, instale el paquete kwin. El uso de Wrapland no se limita a KDE, por ejemplo, se ha preparado una implementación de cliente para el protocolo de control de salida utilizado en wlroots, que permite usar KScreen para configurar la salida en servidores compuestos basados ​​en wlroots (Sway, Wayfire).

Mientras tanto, las actualizaciones del proyecto KWin de baja latencia continúan siendo publicadas, que forma la junta editorial del administrador compuesto de KWin con parches para aumentar la capacidad de respuesta de la interfaz y solucionar algunos problemas relacionados con la velocidad de respuesta a las acciones del usuario, como el frenado de entrada.

Finalmente para quienes estén interesados en conocer más al respecto o revisar el código de KwinFT pueden dirigirse al siguiente enlace, donde ademas encontraran información sobre su instalación.

El código se distribuye bajo las licencias GPLv2 y LGPLv2.

from Linux Adictos https://ift.tt/3aoIA8F
via IFTTT