O CERN tinha duas opções: trocar de sistema operacional ou substituir mais de mil computadores — escolheram o caminho mais lógico

Acontece com muitos de nós em casa: temos um dispositivo que continua funcionando, cumpre perfeitamente o que pedimos e, de repente, o software começa a deixá-lo para trás. Pode ser aquele iPod que já não recebe novas atualizações ou um computador ainda potente que não atende aos requisitos para dar o salto para o Windows 11. O hardware não estragou, mas sua vida útil começa a ficar condicionada pelo que ele consegue rodar. É uma situação bem rotineira — até levarmos esse mesmo problema para outra escala: a dos computadores que mantêm em funcionamento os aceleradores de partículas do CERN.

O que estava em jogo não eram os notebooks dos pesquisadores nem os servidores gerais da organização, mas uma peça muito mais específica de todo o complexo de aceleradores. Estamos falando de cerca de 2.200 Front-End Computers, entre computadores industriais e sistemas embarcados, utilizados para se comunicar com a eletrônica que controla essas instalações. Os requisitos de processador introduzidos nas novas versões do ecossistema Red Hat ameaçavam deixar para trás uma parcela relevante dessas máquinas. O laboratório precisava decidir: fazer intervenções em equipamentos e circuitos que ainda funcionavam perfeitamente ou contornar o problema mudando a rota do software.

Um problema de software com consequências físicas

Para entender onde estava o impasse, é preciso olhar para a CPU. O termo x86-64 não define um conjunto único e imutável de recursos: existem níveis como x86-64-v2 e x86-64-v3, que trazem instruções adicionais que o software mais moderno passa a exigir como obrigatórias. O Red Hat Enterprise Linux 9 (RHEL 9) passou a exigir no mínimo o nível v2, enquanto o RHEL 10 elevou o requisito para o v3. Isso permite compilar o sistema operacional, extraindo melhor desempenho de processadores recentes, mas traz uma consequência direta: os chips anteriores que não contam com essas instruções ficam de fora, mesmo que continuem funcionando sem qualquer falha com o software atual.

Quando a instituição colocou os números na ponta do lápis, a incompatibilidade deixou de parecer um detalhe marginal. Em sua análise de risco de 2023, o laboratório calculou que aproximadamente 47% de todo aquele parque tecnológico utilizava processadores no nível original x86-64 — ficando, portanto, abaixo do mínimo exigido pelo RHEL 9. Outros 17% estavam no patamar x86-64-v2 e entrariam em conflito com o salto posterior do RHEL 10 para o v3. Isso não significava que 64% das máquinas precisassem ser descartadas imediatamente, mas indicava que, ao acompanhar a evolução do sistema, cerca de dois terços da infraestrutura acabariam colidindo com o novo piso de hardware.

E aqui entra outra diferença essencial em relação ao computador que usamos em casa. Esses sistemas fazem parte de uma infraestrutura distribuída por todo o complexo de aceleradores e estão conectados a cerca de 17.000 dispositivos, entre circuitos de controle e equipamentos altamente especializados. O CERN contabiliza também em torno de 70.000 cabos interligados e utiliza tanto hardware industrial padronizado quanto placas e controladores fabricados sob encomenda para tarefas ultraespecíficas. Substituir uma dessas máquinas significa, portanto, checar compatibilidades minuciosas, modificar circuitos eletrônicos, reorganizar o cabeamento e revalidar se todo o conjunto continua funcionando com máxima precisão.

Quando os técnicos calcularam quanto custaria resolver o impasse pelo lado do hardware, a dimensão dos custos chamou a atenção. O cenário analisado em 2023 girava em torno de 5,4 milhões de francos suíços (aproximadamente 5,7 milhões de euros no câmbio atual) e previa o redesenho de cerca de 11 modelos de placas, a contratação de seis profissionais dedicados entre engenheiros e técnicos, tarefas complexas de reorganização e recabeamento de racks, além de todo o comissionamento posterior. Para completar, a própria estimativa interna considerava otimista uma taxa de sucesso de apenas 20%, mesmo supondo que as novas soluções saíssem sem falhas. Era esforço e risco demais para sanar uma incompatibilidade gerada originalmente no software.

Debian como alternativa: "solução de software para problema de software"

O Debian não surgiu por acaso nessa equação. O CERN acumulava mais de duas décadas de atuação no ecossistema da Red Hat, primeiro com o Scientific Linux e, mais tarde, com distribuições como AlmaLinux e CentOS Stream — uma continuidade que facilitava o reaproveitamento de rotinas, ferramentas e conhecimento técnico acumulado. Apesar disso, os engenheiros sempre mantiveram o Debian como plano de contingência caso mudanças bruscas comprometessem ciclos de vida tão longos. Quando essa alternativa se tornou uma necessidade real, a escolha foi categórica: migrar esses sistemas de controle para o Debian 13. Os próprios especialistas resumiram o veredito em uma frase: "Solução de software para um problema de software".

Mudar de distribuição, no entanto, não significava simplesmente rodar um instalador do Debian e dar o trabalho por concluído. O time enfrentou a ausência de utilitários padronizados para compilar e empacotar programas em escala, além de dificuldades para manter diferentes versões de um mesmo componente e gerenciar módulos binários específicos do kernel. A saída foi readequar sua própria infraestrutura interna, incluindo ferramentas como o Koji, já utilizado em outros ambientes da entidade. A vantagem estratégica era evidente: concentrar recursos em software e ferramentas internas em vez de intervir fisicamente em uma rede industrial muito mais complexa e sensível.

Cronograma em andamento e limites bem definidos

A transição já começou. Quando os líderes do projeto detalharam seus planos no final de agosto, explicaram que dezenas de máquinas com Debian já estavam operando normalmente no complexo. A meta agora é levar todos os mais de 2.200 computadores industriais e sistemas embarcados para o Debian 13 antes do final de 2026. Essa versão contará com suporte estendido (LTS) até 2030, com caminhos para prolongá-lo por ainda mais tempo. O escopo da mudança, porém, tem limites bem definidos: os data centers e os nós computacionais dedicados aos experimentos continuarão utilizando RHEL e AlmaLinux. O CERN não está rompendo com a Red Hat; apenas decidiu que, para manter esta frente específica de seus aceleradores funcionando, a saída mais inteligente era trocar o software, não o hardware.

Matéria traduzida de Xataka*