A edição Fedora 40 Ainda é recente e não foi lançado há muito tempo, nesta versão ée implementou um grande número de mudanças importante e dentre eles, um que se destacou foi o introdução oficial da família “Atomic Desktops”, com novos ambientes de desktop para a distribuição.
E parece que A tendência pode continuar, desde agora o FESCo (Fedora Engineering Steering Committee), responsável pela parte técnica do desenvolvimento do Fedora Linux, aprovou a criação de imagens ISO oficiais que apresentará um ambiente gráfico baseado no gerenciador composto Milagre, sobre o qual já falamos aqui no blog.
Milagre-wm se destaca por oferecer suporte para mosaicos de janelas, semelhante ao gerenciador de janelas i3, ao gerenciador de composição Hyprland e ao ambiente de usuário Sway e é mencionado que a intenção é criar um compositor que seja mais chamativo e rico em recursos do que qualquer um desses compositores, como o swayfx.
É mencionado que Fedora Miracle Spin usará o protocolo Wayland e componentes específicos para construção de gerenciadores compostos baseados em Mir. Fedora Spin Edition com Milagre Estará disponível a partir do lançamento do Fedora 41.
captura milagrosa-wm
O propósito principal desta nova versão é oferecer um ambiente de usuário funcional e estético, inspirado no design da janela em mosaico do gerenciador de janelas i3 e com foco em efeitos visuais vibrantes. Esta atualização tem como objetivo principal introduzir um ambiente de alta qualidade baseado em Wayland, compatível com uma ampla gama de dispositivos, incluindo aqueles com processadores ARM e x86 de baixo consumo.
Outra mudança que também foi feito no Fedora 41 e que também já mencionamos, é remoção de pacote gnome-session-xsession, que é responsável por lançar uma sessão GNOME baseado no servidor X. E a partir do Fedora 41, as únicas sessões suportadas por padrão no Fedora Workstation serão aquelas baseadas no Wayland, embora os pacotes de sessões do X11 continuem disponíveis nos repositórios. No entanto, o pacote gnome-session-xsession está marcado como obsoleto e os desenvolvedores do GNOME pretendem abandonar o suporte ao X11 no futuro.
Outra tarefa planejada é a separação do pacote gnome-classic-session, que inclui extensões e configurações para o GNOME Shell para recriar a sessão clássica do estilo GNOME 2. Este pacote ainda será instalado por padrão, mas o suporte para X11 foi movido para um pacote separado chamado. gnome-classic-session-x11, enquanto o pacote principal manterá suporte apenas para sessões baseadas em Wayland.
A principal razão para descontinuar o suporte à sessão X11 no Fedora é a decisão de descontinuar o servidor X.Org no RHEL 9 e removê-lo completamente no futuro lançamento principal do RHEL 10. Outros fatores que contribuem para a remoção da introdução do suporte para Wayland na NVIDIA drivers proprietários e substituição dos drivers fbdev no Fedora 11 pelo driver simpledrm, que funciona corretamente com Wayland. A remoção do suporte à sessão X36 reduzirá significativamente o esforço de manutenção e liberará recursos para melhorar a qualidade da pilha gráfica moderna.
Além disso, Também não podemos esquecer que no Fedora 41 será aplicado o uso padrão do gerenciador de pacotes DNF5, que foi adiado para vários lançamentos e embora a paridade completa de funcionalidade com as ferramentas antigas ainda não tenha sido alcançada, o os desenvolvedores consideram a distribuição pronta para migração, e que os recursos ausentes podem ser implementados posteriormente. Por exemplo, a funcionalidade de gerenciamento do histórico de transações por trás do comando “dnf history” ainda não está disponível. Também trabalhando na integração de suporte para processamento em segundo plano dnf5daemon no gerenciador de aplicativos de software GNOME. O mecanismo para atualizar todo o sistema para a próxima versão (comando de atualização do sistema) requer testes adicionais.
Na época, o DNF substituiu o gerenciador de pacotes Yum, que foi escrito inteiramente em Python. O projeto DNF5 visa unificar bibliotecas de baixo nível existentes, reescrever os componentes restantes de gerenciamento de pacotes Python em C++ e mover a funcionalidade principal para uma biblioteca. libdnf5 separadamente, criando um wrapper em torno desta biblioteca para conter a API Python.
Por fim, se estiver interessado em saber mais sobre o assunto, pode consultar os detalhes no link a seguir