Poucos tópicos despertam tanta paixão na comunidade Linux quanto a questão da compatibilidade com arquiteturas legadas, especialmente a i686 (32 bits). Em uma reviravolta significativa, o Fedora 44 abandonou oficialmente os planos de descontinuar o suporte completo a pacotes i686 — um movimento que, se implementado, teria profundas repercussões para desenvolvedores, usuários e especialmente gamers no Linux.
A decisão foi revertida após uma onda de críticas e oposição firme da comunidade, culminando com um posicionamento técnico contundente da Valve, empresa responsável por Steam, Proton e parte essencial do ecossistema de jogos Linux. A discussão revelou as tensões recorrentes entre inovação e legado, e como o equilíbrio entre esses dois mundos continua moldando o futuro das distribuições Linux modernas.
O recuo do Fedora: a proposta de fim do i686 (32 bits) é retirada
A proposta de abandonar o suporte a i686, ou seja, os pacotes de 32 bits, foi apresentada por Fabio Valentini, um dos desenvolvedores envolvidos com o empacotamento do Fedora. O plano previa a remoção de todo o suporte a binários multilib — bibliotecas e dependências que permitem rodar aplicativos de 32 bits em sistemas x86_64 (64 bits).
É importante destacar que o Fedora já não oferece suporte a hardware exclusivamente i686 desde 2020. A proposta de 2024 dizia respeito apenas aos builds multilib de 32 bits para uso em sistemas 64 bits, que ainda são amplamente utilizados para executar aplicações legadas e jogos.
Contudo, a proposta não foi bem recebida. A Fedora Engineering Steering Committee (FESCo), órgão que rege as mudanças de grande impacto na distribuição, rapidamente viu o caso se tornar um dos mais comentados do ciclo.
Diante da repercussão negativa, e principalmente após os argumentos técnicos apresentados por membros da comunidade e empresas como a Valve, a proposta foi oficialmente retirada. O Fedora 44, portanto, manterá o suporte ao i686, inclusive com pacotes cruciais para o funcionamento de drivers, ferramentas de compatibilidade e softwares legados.
Contexto da proposta e a reação da comunidade
A motivação original para encerrar o suporte ao i686 estava alinhada com os objetivos de modernização e simplificação da base de pacotes do Fedora. Com cada vez menos usuários rodando sistemas em hardware 32 bits nativo, manter o suporte multilib impõe um fardo significativo de manutenção, testes e engenharia de integração.
Ainda assim, a proposta ignorou cenários críticos de compatibilidade, especialmente relacionados ao mundo dos jogos e aplicações legadas, o que gerou forte mobilização nos canais de discussão e redes sociais da comunidade Fedora.
Desenvolvedores relataram impactos imediatos em ferramentas como Wine, Steam e jogos que utilizam o Proton — todas dependentes de bibliotecas glibc e mesa drivers de 32 bits. Também houve alertas sobre a dependência de pacotes 32 bits por parte de bibliotecas gráficas herdadas do X.Org Server, ainda amplamente usadas no stack gráfico Linux. O tema se conecta diretamente com discussões paralelas em torno do XLibre, um fork do X.Org que pretende manter suporte a drivers e arquiteturas antigas, incluindo 32 bits.
A influência da Valve e o impacto no gaming Linux
O ponto de inflexão veio com um alerta direto da Valve, empresa que tem investido pesadamente no ecossistema gaming Linux. Segundo os engenheiros da Valve, abandonar suporte a i686 afetaria diretamente o funcionamento de títulos no Steam com suporte via Proton, quebrando uma cadeia de compatibilidade cuidadosamente construída nos últimos anos.
Como muitos jogos ainda são fornecidos em binários 32 bits ou exigem bibliotecas específicas, a Valve declarou que o Fedora poderia se tornar uma plataforma inviável para gaming, caso o suporte fosse descontinuado. Isso também afetaria o Steam Deck, que usa o ecossistema SteamOS, baseado em pacotes compatíveis com o Fedora e Debian.
A intervenção da Valve foi considerada um fator decisivo na reversão da proposta.
As razões por trás da retirada: uma análise dos bastidores
Internamente, desenvolvedores apontaram que a proposta chegou mal embasada tecnicamente e sem uma análise completa de impacto. Além disso, não houve testes em repositórios paralelos (como o COPR) para validar cenários críticos.
A falta de comunicação prévia com projetos como Wine, mesa, Steam, Flatpak e emuladores de plataformas antigas — todos fortemente dependentes de bibliotecas 32 bits — contribuiu para a percepção de que a decisão foi precipitada e descolada da realidade dos usuários.
Em comentário público na retirada oficial da proposta no Bugzilla, o próprio Fabio Valentini reconheceu que a comunicação foi falha e se comprometeu a buscar um processo mais colaborativo e técnico em futuras tentativas.
A percepção de que ‘Fedora 44’ era cedo demais
Muitos membros da FESCo concordaram que, embora o suporte a i686 esteja de fato com os dias contados, a Fedora 44 não era o momento apropriado para esse corte. Havia um consenso de que uma transição cuidadosa, planejada e acompanhada por ferramentas de migração seria o caminho ideal.
Entre as sugestões surgidas, está a possível criação de um SIG (Special Interest Group) dedicado à manutenção voluntária do i686, o que permitiria aliviar o time central do Fedora e ao mesmo tempo garantir a continuidade do suporte a quem realmente precisa.
Além disso, o timing da proposta, próximo à janela de congelamento de features do Fedora 44, contribuiu para a rejeição: não haveria tempo hábil para mitigar os efeitos colaterais.
O conflito inerente ao processo de ‘Changes’ do Fedora
O sistema de mudanças do Fedora, conhecido como Changes process, permite que qualquer desenvolvedor proponha alterações significativas para as próximas versões. No entanto, o episódio expôs um problema estrutural: propostas de alto impacto podem ser levadas adiante com pouco diálogo com os stakeholders afetados.
Esse modelo, embora ágil, também se mostrou vulnerável a decisões potencialmente destrutivas, caso não haja um amplo envolvimento da comunidade e validação realista dos impactos técnicos.
Críticas ao feedback da comunidade e à ‘imprensa clickbait’
Durante as discussões, houve críticas ao comportamento de partes da comunidade, acusada de ser reativa demais, além de apontamentos sobre a atuação de canais de YouTube e sites de imprensa que supostamente distorceram a proposta.
Alguns desenvolvedores argumentaram que o pânico gerado em torno do fim do i686 foi amplificado por conteúdo sensacionalista, comprometendo o debate técnico. Por outro lado, usuários responderam que a própria comunicação oficial da proposta foi ambígua e pouco transparente.
O resultado foi um embate entre a necessidade de clareza e didatismo por parte dos mantenedores, e a responsabilidade da mídia técnica de não amplificar ruídos desnecessários.
O dilema do 32 bits no Linux: modernização versus compatibilidade
O dilema enfrentado pelo Fedora não é novo no mundo Linux. Muitas distribuições já abandonaram completamente a arquitetura 32 bits, como o Ubuntu, que manteve apenas os pacotes mínimos para compatibilidade via Wine e Steam.
Manter compatibilidade legada consome tempo, infraestrutura e testes automatizados. Porém, abandonar esse suporte pode cortar acesso a milhares de jogos, aplicações industriais antigas e ferramentas de desenvolvimento que ainda não foram portadas para 64 bits.
O caso Fedora 44 escancara a tensão entre evoluir tecnicamente e respeitar o ecossistema atual.
O fardo da manutenção para desenvolvedores e engenharia de release
Manter o suporte a i686 envolve:
- Compilar e distribuir milhares de pacotes duplicados na versão 32 bits;
- Garantir testes funcionais e de segurança para essas versões;
- Suportar multilib em ferramentas como dnf e repositórios de mirrors;
- Resolver conflitos em builds paralelos, como drivers gráficos ou bibliotecas de sistema.
Para engenheiros de release e mantenedores, é um fardo constante, que muitas vezes atrasa o desenvolvimento e empacotamento de novas features para 64 bits.
O impacto em softwares como Wine e Steam
Wine, ferramenta essencial para rodar programas do Windows no Linux, depende fortemente de bibliotecas 32 bits, pois muitos executáveis antigos ainda usam essa arquitetura. Da mesma forma, o Steam, em sua base, ainda possui inúmeros jogos com versões apenas em 32 bits, especialmente títulos da geração do DirectX 9/10.
Sem i686, usuários Fedora ficariam sem suporte pleno a essas ferramentas — quebrando fluxos de trabalho, experiências de jogo e até mesmo sistemas corporativos legados que usam Wine para rodar aplicações internas.
O futuro do suporte a 32 bits no Fedora e outras distros
Embora a proposta tenha sido retirada no Fedora 44, isso não significa que o suporte ao i686 está garantido indefinidamente. A expectativa é que, até o Fedora 46, uma transição gradual comece a ser desenhada.
Possibilidades incluem:
- Separar o repositório multilib em um repositório opcional;
- Reduzir o escopo de pacotes 32 bits, mantendo apenas os essenciais;
- Oferecer containers Flatpak com suporte 32 bits isolado, permitindo compatibilidade sem afetar o sistema base;
- Trabalhar em conjunto com projetos como Wine e Steam para uma migração coordenada;
- Criar um SIG (Special Interest Group) dedicado à manutenção comunitária do i686.
Distribuições como o Arch Linux e o openSUSE também já avaliam rotas semelhantes, o que indica que o fim do 32 bits será uma questão de tempo, embora cuidadosamente planejada.
Conclusão: o poder da comunidade e o caminho incerto do 32 bits no Linux
A reversão da proposta no Fedora 44 é um exemplo emblemático de como a comunidade, quando mobilizada com argumentos técnicos sólidos, ainda pode influenciar decisões de upstream em grandes projetos open source.
O episódio também serviu de alerta para os desenvolvedores: modernização não pode ocorrer às custas da compatibilidade crítica, especialmente em ecossistemas com tanta diversidade de uso como o Linux.
Por ora, o suporte ao i686 sobrevive — mas o futuro permanece incerto. E, como esse caso mostrou, esse futuro dependerá menos de decisões isoladas e mais de diálogo, transparência e cooperação multilateral.
