O universo do hardware ARM é vasto, diversificado e, sejamos honestos, um pouco caótico em comparação com a padronização que encontramos no mundo dos PCs x86_64. Para projetos como o Fedora, isso sempre representou um desafio monumental: como garantir uma experiência de qualidade em uma infinidade de placas, laptops e dispositivos com arquitetura AArch64? A solução histórica era manter listas de hardware explicitamente suportado. O problema? Essas listas se tornaram obsoletas, difíceis de manter e não refletiam mais a realidade do ecossistema.
Foi nesse cenário que a equipe de Qualidade (QA) do Projeto Fedora iniciou uma discussão crucial, levantando uma bandeira vermelha: o modelo atual era insustentável. Com recursos limitados de pessoal e hardware, testar manualmente dezenas de dispositivos diferentes a cada lançamento era simplesmente impraticável. A existência de múltiplas listas de hardware desatualizadas espalhadas pela wiki do projeto só adicionava mais confusão, criando um processo de validação que, nas palavras da própria equipe, parecia “morto e frustrante”.
Era evidente que uma mudança precisava acontecer. Mas qual seria o caminho? Reduzir drasticamente o escopo ou repensar completamente a filosofia de suporte?
O debate: Foco em testes vs. suporte amplo
A proposta inicial da equipe de QA, liderada por figuras como Adam Will, era pragmática: unificar e reduzir as definições de hardware, focando os esforços de teste e validação em um único dispositivo popular e acessível – o Raspberry Pi 4. A lógica era simples: concentrar recursos onde a maioria dos usuários de fato está, garantindo que pelo menos uma plataforma de referência funcione de maneira impecável.
No entanto, essa abordagem gerou um debate intenso dentro da comunidade de desenvolvedores. Peter Robinson, um dos principais mantenedores do Fedora para ARM, apresentou uma contraproposta fundamental. Para ele, limitar o suporte oficial ao hardware que a equipe de QA possui em sua bancada seria um erro. Ele argumentou que o Fedora não faz isso para a arquitetura x86_64 – um bug em um laptop popular ou em uma placa de rede amplamente utilizada pode se tornar um release-blocking (bloqueador de lançamento) mesmo que a equipe de testes não possua aquele hardware específico.
A força dos dados
Para contextualizar a discussão, Adam Will mergulhou nos dados de relatórios de bugs. Os números foram reveladores: em 2025, dos 111 bugs reportados para a arquitetura AArch64, a esmagadora maioria se concentrava em três categorias:
- Usuários do Asahi Linux (baseado no Fedora) em Macs com chips da Apple.
- Sistemas rodando em virtualização.
- Dispositivos Raspberry Pi.
Relatos de outras placas, como Orange Pi, Pinebook ou laptops com Snapdragon, eram raros, muitas vezes limitados a um único usuário. Esses dados davam força ao argumento da equipe de QA de que focar no Raspberry Pi cobriria uma parcela significativa dos casos de uso em hardware físico real.
O argumento por uma abordagem flexível
Apesar dos dados, a visão de Robinson defendia um princípio maior: tratar o AArch64 como uma arquitetura de primeira classe, assim como o x86_64. Ele destacou que o ecossistema ARM está em plena expansão, especialmente em servidores na nuvem e com a chegada de novos laptops. Criar uma lista restritiva poderia sufocar o suporte a essas novas plataformas. A solução, para ele, seria abandonar completamente as listas explícitas e avaliar cada bug caso a caso, considerando fatores como o impacto para o usuário e a popularidade do hardware afetado.
A decisão do FESCo: Uma nova era para o Fedora em AArch64
Após semanas de debates e análises, o FESCo (Fedora Engineering Steering Committee), o comitê de engenharia responsável pelas decisões técnicas do projeto, chegou a um veredito. Em uma votação unânime, o comitê aprovou a mudança de política, alinhando-se com a visão mais flexível.
A decisão oficial foi clara:
“ACORDADO: O hardware de bloqueio de lançamento do Fedora em AArch64 passa de uma lista de compatibilidade de hardware dedicada para um status de arquitetura genérica, onde os problemas são decididos caso a caso com fatores semelhantes a como os bugs bloqueadores do x86_64 são decididos.”
Esta é, sem dúvida, uma das mudanças mais significativas na política de suporte Fedora ARM em anos. Ela demonstra o amadurecimento da plataforma e a confiança do projeto na sua comunidade.
O que isso significa na prática?
Para o usuário final do Fedora Workstation ou outras variantes em um dispositivo ARM, a mudança é positiva. Significa que, a partir de agora:
- Não há mais listas fixas: Seu dispositivo não precisa estar em uma lista oficial para ser considerado “suportado”.
- O impacto do bug é o que importa: Se você encontrar um bug crítico em seu laptop com Snapdragon ou em sua placa Rockchip, ele tem o potencial de ser considerado um
release-blockingse for demonstrado que afeta um número considerável de usuários ou uma funcionalidade essencial. - A comunidade ganha mais poder: A responsabilidade de relatar bugs de forma clara e ajudar a validar correções torna-se ainda mais importante. É um modelo que depende da participação ativa dos usuários.
Ao abandonar as listas rígidas, o Fedora não está diminuindo o suporte ao ARM; pelo contrário, está adotando uma abordagem mais madura e escalável, muito parecida com a que consolidou a distribuição como uma gigante no mundo dos PCs. É um voto de confiança no futuro vibrante e diversificado da arquitetura AArch64.
Nota de transparência editorial: Este artigo foi elaborado a partir de análise técnica, fontes públicas e curadoria editorial humana, seguindo as diretrizes de utilidade e precisão do SempreUpdate.
