Os engenheiros que moldam o Fedora Project reuniram‑se em 22 de julho de 2025 para uma sessão decisiva do FESCo (Fedora Engineering Steering Committee). Em pouco mais de uma hora, o colegiado aprovou todas as propostas de mudança analisadas para o ciclo do Fedora 43, sinalizando uma virada firme rumo a instalações mais modernas, inicialização mais rápida e um ecossistema de desenvolvimento ainda mais robusto. Entre as deliberações, destacam‑se a remoção oficial do suporte a UEFI em MBR (Master Boot Record) (mudança UEFI em MBR) no Anaconda installer, a adoção da compressão zstd para o initrd por padrão (compressão do initrd com zstd) e grandes saltos em toolchains – Golang 1.25 (proposta Golang 1.25), LLVM 21 e a atualização completa da GNU Toolchain Update. Houve, ainda, a preservação de informações de depuração em bibliotecas estáticas, além de ajustes importantes para o universo Node.js.
Enquanto esses avanços seguem confirmados, a proposta de filtrar Flatpaks destinados aos Atomic Desktops (Filter Fedora Flatpaks for Atomic Desktops) foi adiada para debates adicionais, antecipando discussões acaloradas sobre a distribuição de software no Fedora. A seguir, destrinchamos cada decisão, seu impacto técnico e o que ela revela sobre o futuro da distribuição.
FESCo define o futuro do Fedora 43: decisões estratégicas para instalação e desempenho
O Fedora costuma servir de laboratório de inovação para todo o ecossistema Linux. Cada ciclo de desenvolvimento passa pelo crivo do FESCo, onde a comunidade técnica pesa estabilidade, modernidade e a visão de longo prazo. No encontro de 22 de julho, oito mudanças entraram em pauta, todas aprovadas por unanimidade ou maioria absoluta, demonstrando forte coesão entre mantenedores, usuários corporativos e contribuidores individuais.
Num primeiro olhar, dois temas dominam: (1) a modernização do processo de boot e instalação e (2) a consolidação das ferramentas de desenvolvimento. O FESCo não se limitou, entretanto, a questões puramente técnicas: o tempo dedicado à discussão sobre Flatpaks indica que a experiência de desktop — especialmente nos novos sabores imutáveis e atômicos — também é estratégica.
Adeus ao MBR em instalações UEFI: o Fedora abraça o GPT por padrão
A proposta “Anaconda Drop Support UEFI on MBR” formaliza algo que muitos administradores já vinham observando na prática: a combinação de UEFI com MBR é um resquício de compatibilidade que perdeu relevância. A recomendação industrial para sistemas UEFI modernos é utilizar GPT (GUID Partition Table), que oferece:
- Limites de tamanho muito superiores (partições além de 2 TB).
- Tabelas redundantes, aumentando a resiliência contra corrupção.
- Entradas para partições adicionais, sem as restrições numéricas do MBR.
Ao remover essa “perna extra” de código no instalador Anaconda, o Fedora simplifica testes, reduz código legado e incentiva usuários a migrar para layouts de disco mais robustos. Na prática, quem possui hardware antigo e realmente depende de UEFI‑em‑MBR permanecerá no Fedora 42 ou migrará para o modo BIOS‑Legado. Se este é o seu caso, confira como o projeto melhorou o boot do Fedora 42 em nosso artigo interno sobre o tema (melhorias no boot do Fedora 42).
Zstd para initrd: turbinando a velocidade de boot e otimizando o espaço em disco
O initrd é a engrenagem que carrega drivers essenciais logo após o firmware ceder o controle ao kernel. Hoje, ele costuma vir comprimido em gzip, mas benchmarks internos apontam que a troca por zstd:
- Encurta o tempo de descompressão durante o boot (menos CPU e I/O).
- Gera arquivos marginalmente menores, aliviando o footprint em sistemas de armazenamento restrito (ex.: IoT).
O Fedora já usa zstd no Btrfs e em compressões de RPM; trazer o algoritmo para o initrd mantém a consistência do stack. Variantes como Fedora CoreOS já colhem ganhos tangíveis há vários releases, reforçando a confiança do FESCo na migração. Para entender como a equipe vem reduzindo tamanho de imagens de instalação, vale ler também o teste com live media EROFS feito no ciclo anterior (live media EROFS).
Ferramentas e linguagens de desenvolvimento: atualizações que impulsionam a inovação
Se Fedora é sinônimo de vanguarda, isso passa por toolchains modernos. O ciclo do Fedora 43 dá um salto coordenado em compiladores, bibliotecas padrão e ecossistemas de runtime, garantindo que pacotes e containers mantenham‑se competitivos diante de upstreams que evoluem rápido.
Golang 1.25, LLVM 21 e GNU Toolchain: o Fedora na vanguarda da compilação
- Golang 1.25 (proposta Golang 1.25) traz otimizações no pacer de garbage collection, melhoria no linkador — com geração de binários mais enxutos — e suporte nativo à arquitetura LoongArch64. Como grande parte da infraestrutura Fedora é escrita em Go, adotar a versão mais recente garante correções de segurança e performance.
- LLVM 21 chega com avanços no Clang (melhor autovectorização), no lld (link‑time optimization mais agressiva) e em novas passagens do Polly — crucial para workloads de HPC.
- A GNU Toolchain Update sincroniza GCC, binutils, glibc e gdb às versões estáveis mais recentes. Isso elimina divergências entre compilador e biblioteca de runtime, reduzindo falsos‑positivos em verificações de compatibilidade ABI.
Para evitar que centenas de pacotes golang‑* sejam automaticamente retirados caso não compilem logo de cara com a nova versão, o FESCo aprovou uma exceção temporária. Mantenedores ganharão uma janela de correção sem sofrer remoção automática de repositórios.
Se você acompanha esse tema, vale relembrar como o Fedora 42 introduziu executáveis otimizados para diferentes capacidades do x86_64 e pavimentou o terreno para upgrades de toolchain ainda mais agressivos (executáveis otimizados no Fedora 42).
Node.js: metapacotes e paths que simplificam o desenvolvimento
O Fedora já oferece múltiplas versões do Node.js, mas isso gerava duplicação de dependências em pacotes que simplesmente precisavam de “alguma” versão suportada. O novo metapacote nodejs servirá de ponte simbólica para a release de longo prazo mais estável, poupando linhas de espec no RPM e reduzindo erros de resolução. Complementando o esforço, a proposta “nodejs node_modules path” uniformiza o local onde dependências são instaladas, mitigando confusões entre builds de biblioteca e de aplicativo.
Preservar Debuginfo em bibliotecas estáticas: mais facilidade para depuração e análise
Compilar com ‐g mas depois descartar debuginfo de bibliotecas estáticas sempre foi um paradoxo: retiramos peso do pacote, porém perdemos a habilidade de investigar problemas de produção. A nova política mantém os símbolos de depuração dentro dos SRPMs, sem inflar em excesso os pacotes binários. Para equipes que fazem profiling em edge devices ou em imagens de contêiner reduzidos, basta instalar o subpacote -debuginfo e prosseguir a análise sem reconstruções complexas.
Debates e o futuro do Fedora: Flatpaks para Atomic Desktops em discussão
Mal completou a rodada de aprovações, o FESCo esbarrou no tema que remodela a forma de distribuir aplicações gráficas: Flatpaks. A proposta “Filter Fedora Flatpaks for Atomic Desktops” sugere limitar o repositório padrão de Flatpaks apenas aos aplicativos testados e suportados pela equipe de Atomic Desktops, eliminando duplicidade com versões upstream e focando em qualidade.
Apesar de apoio inicial, houve “comentários extensos” da comunidade — preocupações com liberdade de escolha e sincronização com Flathub — e o item foi adiado. Uma votação baseada em dados (download rates, relatórios de bugs) está prevista para a próxima reunião semanal.
O conceito de Desktops Atômicos e a distribuição de software
Atomic Desktops como Fedora Silverblue e Fedora Kinoite adotam o RPM‑OSTree, oferecendo um sistema imutável que recebe updates atômicos e rollbacks triviais. Nesse paradigma, os aplicativos em Flatpak se tornam o elo flexível na equação: instalam‑se no espaço do usuário, isolam bibliotecas e não quebram o sistema base. Filtrá‑los significa privilegiar:
- Programas que sigam as Guidelines Fedora de integração (portais, theming).
- Builds que passem por QA automatizado, evitando “bandeiras vermelhas” no upstream Flathub.
- Manutenção de menor conjunto, porém com patches rápidos quando falhas críticas surgem.
O adiamento da decisão: uma análise das implicações para o ecossistema Fedora
Postergar a votação evita uma fragmentação às vésperas do freeze do Fedora 43. Caso o filtro seja aprovado, usuários poderão optar manualmente por repositórios externos, mas o padrão será minimalista e mais estável. Se rejeitado, continuaremos a ver o catálogo completo, com a carga adicional de manutenção e a incerteza sobre suporte de features específicas.
Governança open source em ação: o processo decisório da FESCo
O FESCo opera em transparência exemplar: propostas viram tickets no Pagure, enfrentam discussões públicas (listas de e‑mail, fóruns Discourse), recebem votos e, por fim, são registradas em reuniões semanais no Matrix. Qualquer contribuinte pode assistir aos logs, revisar decisões e propor emendas. Esse modelo, embora exija paciência — afinal, cada mudança passa por revisões exaustivas —, garante que o Fedora se mantenha alinhado a padrões de open source e às demandas de um público heterogêneo que vai de entusiastas de desktop a engenheiros de data center.
A importância das reuniões da FESCo para o desenvolvimento do Fedora
- Visão de longo prazo: sem consenso prévio, features potencialmente disruptivas (ex.: migração de Python 2 para 3, de iptables para nftables) teriam causado rupturas maiores.
- Equilíbrio entre inovação e estabilidade: a cadência semestral obriga decisões rápidas; a deliberação coletiva impede saltos sem rede.
- Transparência: logs públicos e votação nominal elevam a confiança da comunidade, fator essencial para atrair novos contribuidores.
Reuniões – muitas vezes rotineiras – podem parecer burocráticas, mas são nelas que requisitos técnicos se transformam em compromissos formais, garantindo previsibilidade a empresas que dependem do Fedora em produção.
Conclusão: Fedora 43 – um lançamento que promete modernidade, desempenho e segurança, moldado por decisões colaborativas
Ao aposentar o MBR em instalações UEFI, abraçar zstd no initrd e escalar suas toolchains, o Fedora sinaliza um ciclo focado em modernizar a base sem sacrificar compatibilidade. A janela dada aos pacotes golang‑* reflete sensibilidade às dificuldades de migração, enquanto as melhorias em Node.js e depuração evidenciam cuidado com a experiência de desenvolvedor.
O debate sobre Flatpaks mostra que a distribuição não teme discutir mudanças que afetam diretamente usuários finais, mesmo que isso exija mais tempo. Com a governança da FESCo afinada e uma comunidade vibrante, o Fedora 43 desponta como um release que consolidará a reputação do projeto: ser a distro na qual novidades chegam primeiro — mas nunca às custas da estabilidade.
