Durante décadas, o ecossistema do software livre cultivou um orgulho muito particular: a capacidade de ressuscitar hardware que o mercado corporativo considerava obsoleto. O Kernel Linux construiu sua reputação, em parte, por rodar de forma eficiente em máquinas que engasgariam com as versões mais recentes do Windows. Contudo, essa cultura da retrocompatibilidade extrema tem um custo oculto severo. A recente decisão de tornar o Time Stamp Counter (TSC) obrigatório para processadores x86 prova que os mantenedores finalmente decidiram que a nostalgia não pode mais pautar a engenharia técnica.
A alteração no código encerra o suporte a chips pré-Pentium, abolindo rotinas de compatibilidade que permitiam compilar o sistema para CPUs sem o registrador de tempo. Na prática, a mudança não afeta o usuário doméstico, mas sinaliza uma guinada importante na filosofia de desenvolvimento do projeto.
O preço invisível de manter peças de museu

O Time Stamp Counter foi introduzido em 1993. Trata-se de um recurso básico que conta ciclos de clock, oferecendo uma precisão essencial para o funcionamento do sistema operacional sem gargalos. Antes da obrigatoriedade do TSC, o Kernel Linux mantinha um código de fallback para acessar timers de placa-mãe mais lentos, apenas para acomodar hardwares das décadas de 1980 e 1990, como o Intel 486.
Manter esse código legado ativo significa exigir que desenvolvedores e mantenedores revisem, testem e adaptem rotinas de tempo antigas a cada nova arquitetura ou recurso de segurança adicionado ao kernel. É o que chamamos de dívida técnica: um peso morto que consome horas de trabalho altamente qualificado para atender a uma fatia de usuários estatisticamente irrelevante.
A Microsoft percebeu isso há muito tempo. O TSC se tornou um requisito no Windows 8, lançado em 2012. O fato de o Kernel Linux ter carregado essa âncora por mais de uma década adicional não é apenas uma prova de resiliência, mas também de uma teimosia arquitetônica que começa a cobrar seu preço na era da computação em nuvem e dos processadores híbridos.
A realidade dos sistemas críticos e o papel do LTS
O argumento comum contra cortes de hardware legado é o impacto em sistemas industriais e equipamentos embarcados que ainda operam com processadores de 32 bits antigos. Embora seja verdade que essas máquinas existem e controlam desde tornos mecânicos até sistemas de automação antigos, a premissa de que elas precisam do kernel mais recente é fundamentalmente falha.
Um controlador industrial operando um chip de 30 anos não precisa e sob nenhuma métrica de segurança deveria rodar o mainline atual do Kernel Linux. Esses ambientes isolados e altamente específicos são exatamente o público-alvo das versões LTS (Long Term Support). Congelar a base de software em ramificações antigas garante a estabilidade que a indústria exige, liberando o ramo principal para evoluir.
O amadurecimento necessário
Cortar o suporte a CPUs x86 sem TSC é um passo pragmático e indispensável. O Kernel Linux contemporâneo precisa lidar com desafios complexos, mitigando vulnerabilidades de execução especulativa em tempo real e orquestrando cargas de trabalho intensas para inteligência artificial e servidores em hiperescala.
Nesse cenário, não há mais espaço para manter linhas de código destinadas a processadores que sequer possuem poder computacional para abrir uma página web moderna. A decisão de limpar a casa não torna o sistema menos acessível; ela o torna mais sustentável, ágil e preparado para as próximas três décadas de evolução do hardware.
