Dois Fedora Spins vão se livrar do X.Org

Dois Fedora Spins vão se livrar do X.Org
fedora logo

Os spins Fedora Sericea e Sway estão de olho na possibilidade de serem lançados sem os pacotes xorg-x11 por serem os primeiros spins de desktop sem X.Org no mundo Fedora Linux. O Fedora Sway que faz uso do compositor i3 de Wayland e Fedora Sericea é uma variante imutável dele. Assim, pelo menos duas versões Dois Fedora Spins vçao se livrar do X.Org

Fedora Sway e Sericea ainda dependiam do X.Org para o gerenciador de exibição SDDM X11, mas desde que o suporte Wayland do SDDM se uniu e o saudador Wayland é experimental no SDDM 0.20 que finalmente foi lançado, eles estão de olho na possibilidade de ir totalmente em Wayland.

Dois Fedora Spins vão se livrar do X.Org

Dois Fedora Spins vão se livrar do X.Org

O plano de eliminar os pacotes xorg-x11 desses spins do Fedora está agora sob avaliação pelo Fedora Engineering and Steering Committee (FESCo). Veja a página Fedora Wiki para mais detalhes sobre esta proposta de mudança para a versão de outono do Fedora 39.

Fedora pode facilitar a mudança para o systemd-boot e criar um sistema livre de GRUB

Uma proposta de mudança que espera ocorrer para o Fedora 39 tornaria mais fácil ter um sistema opcionalmente livre de GRUB, executando uma instalação limpa com systemd-boot para inicializar em plataformas EFI.Atualmente, o padrão do Fedora é usar um shim e o gerenciador de inicialização GRUB para inicializar em sistemas EFI. No entanto, o systemd-boot já está empacotado no Fedora e existem algumas maneiras de mudar manualmente para usar a solução de inicialização do systemd. A proposta F39 elaborada pelo engenheiro da Arm, Jeremy Linton, permitiria uma instalação mais fácil do Fedora com o systemd-boot. Assim, o Fedora pode facilitar a mudança para o systemd-boot e criar um sistema livre de GRUB.

Algumas alterações para o Fedora 39 em discussão

Há uma proposta em andamento para o Fedora 39 aumentar seu vm.max_map_count padrão para satisfazer alguns jogos do Windows rodando no Linux por meio do Steam Play da Valve. Uma proposta revisada foi agora aprovada pelo Comitê de Engenharia e Direção do Fedora. Até este ponto, o Fedora usou o valor vm.max_map_count padrão de 65.530, enquanto o Steam OS da Valve usa um valor de 2147483642 (MAX_INT – 5). Portanto, a expectativa é de que o Fedora 39 vai aumentar seu vm.max_map_count para satisfazer alguns jogos do Steam Play.

A maioria dos softwares funciona bem com o limite do número máximo de mapas de memória para um processo em 65k, mas alguns jogos do Windows como DayZ, Hogwarts Legacy e Counter-Strike 2 precisam de mais do que isso para rodar normalmente no Steam Play.Originalmente, a proposta do Fedora 39 também era usar uma contagem máxima de mapa de memória de 2147483642, mas havia preocupações levantadas se fosse muito altoque o kernel pode ser sobrecarregado com muitos mapeamentos e, por sua vez, levar o manipulador de falta de memória a encerrar outros processos.

Uma das recentes propostas de mudança para o Fedora 39 em desenvolvimento é enviar o mkosi-initrd do systemd como uma alternativa moderna e superior ao Dracut para a construção de initrds. Sendo assim, o Fedora 39 vai enviar mkosi-initrd como uma alternativa moderna ao Dracut.

Inicialmente mkosi-initrd é definido para ser tratado como um construtor alternativo ao Dracot para construir initrds, mas seu escopo inicial pode ser limitado. A intenção com mkosi-initrd é limpar o processo de construção complicado e ineficiente usado atualmente pelo Dracut. 

Acesse a versão completa
Sair da versão mobile