Futuro do suporte à plataforma 32-bit no FreeBSD

Status do suporte a 32 bits em grandes sistemas

• O Fedora vem descontinuando sistematicamente kernels e pacotes i686; muitos pacotes novos nem chegam a compilar mais no i686.
• O Ubuntu em grande parte abandonou 32 bits, mantendo apenas um conjunto mínimo de libs para Steam/Wine.
• O Debian está migrando de 32 bits para tempo de 64 bits, mas avisa que o i686 pode ser abandonado em breve.
• O FreeBSD 16 não terá suporte a plataformas de 32 bits, mas binários de 32 bits continuam suportados em kernels de 64 bits (ainda não há plano para abandonar isso).
• O OpenBSD já trata o i386 como baixa prioridade (apenas correções fáceis/críticas). O futuro ali é incerto.
• O NetBSD é amplamente visto como o lar de longo prazo para hardware 32-bit/legado.

Impacto prático em software e bibliotecas

• Aplicativos proprietários legados de 32 bits e libs relacionadas ao Wine ainda são um ponto problemático; remover libs de 32 bits pode simplesmente quebrá-los.
• Alguns mantenedores acham que o software novo pressupõe 64 bits e não vai corrigir problemas de compilação em 32 bits.
• Testar 32 bits está cada vez mais difícil porque distribuições modernas não incluem stacks completas de 32 bits; as pessoas recorrem a VMs antigas.

Portabilidade, UB e debates sobre tamanhos de tipos em C

• Problemas recorrentes: suposições erradas sobre o tamanho de long/size_t e conversão de ponteiros para long em vez de uintptr_t.
• Alguns argumentam que isso é apenas C ruim, independente de 32 vs 64 bits, e que deve ser corrigido como bugs de UB/portabilidade.
• Outros rebatem: corrigir para plataformas teóricas tem custo real e pouco benefício atual; muitos projetos otimizam deliberadamente para o Unix 64-bit dominante.
• Há apoio para preferir size_t/uint32_t/uint64_t (tipos de C99) em vez de int/long, e até a ideia de descontinuar tipos inteiros legados.

Tendências de arquitetura de CPU e modo de boot

• O x86-S proposto pela Intel e novos designs ARM Cortex-A estão abandonando modos de boot de 16/32 bits; alguns núcleos ARM já não conseguem executar apps 32-bit de forma alguma.
• A Apple removeu cedo o suporte a apps 32 bits; o hardware atual não suporta código Mac de 32 bits, mas há uma capacidade mínima de 32 bits no Rosetta para coisas como Wine.
• Alguns acham que já passou da hora de o x86 iniciar diretamente em long mode; outros alertam que não literalmente “todo mundo” precisa apenas de 64 bits.

Wine, time_t e Y2038

• O Wine está caminhando para um modelo em que apps de 32 bits chamam bibliotecas de 64 bits, o que poderia permitir que distribuições removam a maioria das libs de 32 bits.
• O problema do ano 2038 adiciona pressão: tempo de 32 bits em sistemas de 32 bits é outro grande fardo de migração; o FreeBSD já usa time_t de 64 bits em todo lugar, exceto i386.

Sistemas embarcados e cauda longa

• Há a preocupação de que a rápida descontinuação de 32 bits prejudique o uso de Unix embarcado.
• Um lado: para trabalho embarcado sério, RTOS ou bare metal são melhores; Unix de 32 bits é exagero e obsoleto, e SoCs baratos de 64 bits (por exemplo, classe Cortex-A55) estão amplamente disponíveis.
• Contra-argumento: muito “embarcado gordo” (roteadores, dispositivos de segurança, placas classe RPi) ainda roda Linux 32 bits; o Linux 32 bits provavelmente vai persistir lá por muito tempo.
• Alguns sugerem tratar o Unix 32 bits no futuro como 8/16 bits hoje: nicho, sob medida, não alvo para software portátil genérico.

Papel do ecossistema BSD e sentimento geral

• O FreeBSD é visto como cada vez mais focado em hardware 64-bit de classe servidor; 32 bits nunca foi muito forte em sua história embarcada.
• O NetBSD é visto como o refúgio para hardware legado e um nicho complementar ao FreeBSD.
• O OpenBSD e o suporte multi-arquitetura são elogiados por detectar suposições não portáveis (endianness, alinhamento, 32/64 bits).
• Vários participantes expressam nostalgia e uma sensação de envelhecimento à medida que o suporte a 32 bits é aposentado.