La edición de Fedora 40 es aun reciente y no tiene mucho de haber sido liberada, en esta versión se implementaron una gran cantidad de cambios importantes y entre ellos, uno de los que se destacó fue la introduccion oficial de la familia «Atomic Desktops», en con nuevos entornos de escritorio para la distribucion.

Y tal parece que la tendencia podría continuar, ya que ahora el FESCo (Fedora Engineering Steering Committee), encargado de la parte técnica del desarrollo de Fedora Linux, aprobó la creación de imágenes ISO oficiales que presentarán un entorno gráfico basado en el administrador compuesto Miracle, del cual ya hemos hablado aquí en el blog.

Miracle-wm se destaca por ofrecer soporte para el mosaico de ventanas, similar al administrador de ventanas i3, el administrador compuesto Hyprland y el entorno de usuario Sway y se menciona que la intención es crear un compositor que sea más llamativo y con más funciones que cualquiera de esos compositores, como swayfx.

Se menciona que el Spin de Fedora Miracle utilizará el protocolo Wayland y componentes específicos para la construcción de administradores compuestos basados en Mir. La edición Spin de Fedora con Miracle estará disponible a partir del lanzamiento de Fedora 41.

captura de miracle-wm

El propósito principal de esta nueva versión es ofrecer un entorno de usuario funcional y estético, inspirado en el diseño de ventana en mosaico del administrador de ventanas i3 y con un enfoque en efectos visuales vibrantes. Esta actualización tiene como objetivo principal la introducción de un entorno de alta calidad basado en Wayland, compatible con una amplia gama de dispositivos, incluyendo aquellos con procesadores ARM y x86 de bajo consumo.

Otro de los cambios que también se realizara en Fedora 41 y del cual ya mencionamos también, es la eliminación del paquete gnome-session-xsession, que se encarga de lanzar una sesión de GNOME basada en el servidor X. Y es que a partir de Fedora 41  las únicas sesiones admitidas de forma predeterminada en Fedora Workstation serán las basadas en Wayland, aunque los paquetes de sesiones X11 seguirán disponibles en los repositorios. Sin embargo, el paquete gnome-session-xsession está marcado como obsoleto, y los desarrolladores de GNOME tienen la intención de dejar de admitir X11 en el futuro.

Otra tarea prevista es la separación del paquete gnome-classic-session, que incluye extensiones y configuraciones para GNOME Shell para recrear la sesión clásica al estilo de GNOME 2. Este paquete seguirá instalándose de forma predeterminada, pero el soporte para X11 se ha movido a un paquete separado llamado gnome-classic-session-x11, mientras que el paquete principal mantendrá solo la compatibilidad con sesiones basadas en Wayland.

La razón principal para desaprobar el soporte de sesiones X11 en Fedora es la decisión de desaprobar el servidor X.Org en RHEL 9 y eliminarlo completamente en la futura versión principal de RHEL 10. Otros factores que contribuyen a la eliminación del soporte de X11 incluyen la introducción de soporte para Wayland en los controladores propietarios de NVIDIA y la sustitución de los controladores fbdev en Fedora 36 por el controlador simpledrm, que funciona correctamente con Wayland. La eliminación del soporte de sesiones X11 reducirá significativamente el esfuerzo de mantenimiento y liberará recursos para mejorar la calidad de la pila gráfica moderna.

Por otra parte, tampoco podemos olvidar que en Fedora 41 se aplicara el uso predeterminado del administrador de paquetes DNF5, el cual se ha venido retrasando desde hace ya varios lanzamientos y aunque aún no se ha alcanzado la paridad total en funcionalidad con las herramientas antiguas, los desarrolladores consideran que la distribución está lista para la migración, y que las funciones faltantes se pueden implementar más adelante. Por ejemplo, la funcionalidad de gestión del historial de transacciones detrás del comando «dnf history» aún no está disponible. También se está trabajando en la integración del soporte para el proceso en segundo plano dnf5daemon en el administrador de aplicaciones del software GNOME. El mecanismo para actualizar todo el sistema a la siguiente versión (comando de actualización del sistema) requiere pruebas adicionales.

En su momento, DNF reemplazó al administrador de paquetes Yum, que estaba escrito completamente en Python.  El proyecto DNF5 tiene como objetivo unificar las bibliotecas de bajo nivel existentes, reescribir los componentes restantes de administración de paquetes en Python en C++, y mover la funcionalidad básica a una biblioteca libdnf5 separada, creando un contenedor alrededor de esta biblioteca para mantener la API de Python.

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