Uma recomendação dada no “No-Go” para o Fedora 30 na quinta colocava em risco o lançamento. Porém, os desenvolvedores e testadores fizeram um excelente trabalho nas últimas 24 horas. Elese deram forma ao Fedora para lançá-lo na próxima semana na terça-feira. Assim, todo o esforço valeu a pena e o Fedora 30 foi liberado para lançamento na próxima terça.
Os bugs bloqueadores foram resolvidos e o estado do Fedora 30 parece bem. Na reunião realizada ainda na sexta-feira, eles declararam o Fedora 30 como “GO” para lançamento na terça-feira, 30 de abril.
O Fedora 30 é a mais recente atualização para esta popular distribuição Linux patrocinada pela Red Hat. Dessa forma, o lançamento ocorrerá uma semana antes do Red Hat Summit 2019 em Boston, onde a empresa pode anunciar o muito aguardado Red Hat Enterprise Linux 8.0.
O Fedora 30 possui muitos pacotes novos e atualizados liderado pelo GNOME 3.32 e o kernel do Linux 5.0 complementado por uma série de mudanças originais grandes e pequenas. Algumas das outras atualizações de pacote com o Fedora 30 incluem o GNU Bash 5.0, o Glibc 2.29, o Ruby 2.6, o Golang 1.12, o PHP 7.3, o Vagrant 2.2, o OpenJDK 12, o LXQt 0.14, e muitos outros pacotes atualizados.
Portanto, o Fedora 30 está pronto para ser lançado dia 30 de abril, próxima terça-feira.
Fedora procura usar o driver FBDEV baseado em VESA, desativando VESA e OpenChrome antigos
O desenvolvedor principal da Red Hat e desenvolvedor do X.Org, Adam Jackson, está analisando a reformulação do caminho do código de exibição do VESA para o Fedora. O plano implicaria na remoção de um antigo “código esboçado” do X.Org Server. Da mesma forma, a mudança para o UVESAFB como o driver FBDEV baseado em VESA. Contudo, significaria descartar o suporte para o driver OpenChrome entre outras mudanças.
O plano de Jackson envolve a mudança para o UVESAFB. Ele é o driver de buffer de quadro VESA para hardware gráfico antigo/sem suporte que não possua um driver DRM/KMS adequado. O UVESAFB depende dos helpers v86d do espaço do usuário para emular o código x86. Assim, evita o código dentro do próprio servidor X.Org. O UVESAFB existe há muito tempo, mas não é usado pelo Fedora.
Ao migrar para o UVESAFB, eles poderiam reduzir ainda mais os privilégios de seu suporte ao X.Org Server.
Outro benefício é que há compositores de Wayland capazes de rodar diretamente em dispositivos FBDEV. Eles ajudariam nesses casos em comparação com o retorno ao DDX da VESA, onde não existe tal suporte.
Esta é uma mudança arriscada, particularmente para sistemas vintage. Porém, para a grande maioria dos usuários rodando em NVIDIA/Radeon/Intel, a mudança não será visível. No entanto, vão perceber uma configuração mais segura do servidor xorg em seu sistema.
Os interessados em mais detalhes sobre estes projetos de planos para o Fedora 31 podem ver os detalhes preliminares na lista de desenvolvimento do Fedora.
