O CERN vai pôr 2200 máquinas de controlo em Debian, e a razão não foi o preço da licença: foi uma flag de compilador a decidir quando o hardware deles morre

Higgs

Olá a todos!

Prefácio do costume, e este é importante porque o tema aquece as pessoas depressa: eu corro varias distros em casa, corro openSUSE na maior parte das coisas que monto para mim, e ao mesmo tempo já operei estimação de RHEL e derivados em produção paga, com contrato, com fornecedor ao telefone e com alguém a pagar. Não acho que Red Hat seja o vilão desta história. Acho que a Red Hat tomou uma decisão de engenharia perfeitamente defensível e que o CERN tomou outra decisão de engenharia perfeitamente igualmente defensível, e que o interessante é exactamente o sítio onde as duas se separam. Não sou purista. Sou pratico, e isto ainda  continua a ser coisa diferente.

No dia 30 de Agosto, na MiniDebConf em Winterthur, dois engenheiros do CERN, o Federico Vaga e o Nikos Tsipinakis, apresentaram uma coisa que os agregadores de notícias transformaram imediatamente num título de guerra: o CERN abandona a Red Hat e passa para Debian. Vi isso a circular a semana toda no Mastodon e em meia dúzia de sites, com o entusiasmo de quem finalmente ganhou uma discussão de vinte anos.

Não é bem isso. E a parte real da história é muito mais útil do que a versão de bandeira, sobretudo para quem por cá tem de defender orçamentos de infraestrutura em frente a pessoas que só querem saber o valor da licença.

Como Jack diria, vamos por partes.

Primeiro, o âmbito, porque o título mente por omissão

O alvo são mais de 2200 computadores industriais e sistemas embebidos usados à volta do complexo de aceleradores, com objectivo de estarem todos em Debian 13, o Trixie, até ao final de 2026. Na altura da apresentação, apenas algumas dezenas estavam operacionais. Ou seja, isto é uma implantação a decorrer com prazo marcado, não um trabalho terminado.

E o âmbito acaba ali. A documentação de Linux do próprio CERN é explícita: o Debian é suportado apenas nos sistemas de linha da frente dos aceleradores, ao abrigo de um acordo entre a equipa dos aceleradores e a equipa de informática, e esse suporte não se estende a máquinas de utilizador final nem a máquinas de centro de dados. Para tudo o resto, o CERN continua a recomendar RHEL ou AlmaLinux. O Phoronix chegou a corrigir a peça depois de o CERN clarificar precisamente isso.

Vale a pena perceber a arquitectura para não dizer disparates e gerar clickbaits desnecessários. O controlo dos aceleradores está organizado em camadas: uma camada de cliente na sala de controlo, uma camada intermédia de servidores em alta disponibilidade e uma camada de baixo, de computadores embebidos que executam aplicações em tempo real e falam directamente com a electrónica. É essa camada de baixo que vai para Debian. As outras ficam onde estavam.
Portanto a frase honesta não é “o Debian conquistou o CERN”. A frase honesta é que o Debian ganhou uma camada estrategicamente sensível, aquela onde a longevidade do hardware, a electrónica feita em casa e as janelas de manutenção planeadas com anos de antecedência pesam mais do que ter uma distribuição única em toda a instituição.

O que, se pensarem bem, é uma afirmação mais forte e não mais fraca. O CERN não está a uniformizar nada. Está a partir deliberadamente um padrão de sistema operativo único que mantinha desde que o LHC arrancou. É uma decisão de arquitectura, não uma decisão de compras.

E, para dar escala à coisa: os slides colocam estes computadores num contexto que ocupa cerca de 43 quilómetros quadrados, quase metade da área do concelho de Lisboa, com interface para à volta de 17 mil dispositivos.

A frase que devia estar afixada em todos os departamentos de compras e procurement.

Os engenheiros do CERN descreveram o problema com uma expressão que eu gostava de ter inventado: forçar a obsolescência com uma flag de compilador.

Explico para quem não vive nisto, porque parece um detalhe técnico irrelevante e é o eixo de toda a decisão.

Os processadores x86 de 64 bits têm níveis de microarquitectura definidos. O nível base, o v1, é aquilo que qualquer processador de 64 bits sabe fazer desde sempre. O v2 acrescenta um conjunto de instruções que apareceram por volta de 2009. O v3 acrescenta AVX2 e companhia, e chega com a geração Haswell, em 2013. O v4 acrescenta AVX-512.

Isto não é uma questão de velocidade. É uma questão de elegibilidade. Quando uma distribuição declara um nível mínimo, está a dizer que os pacotes podem assumir que aquelas instruções existem na máquina. Se não existirem, o software não corre mais devagar. O software não corre.

O RHEL 9 exige x86-64-v2 como mínimo em sistemas AMD e Intel de 64 bits. O RHEL 10 sobe a fasquia para x86-64-v3. Está tudo perfeitamente descrito, preto no branco, nas notas de lançamento. Ninguém escondeu nada de ninguém, e isso é fundamental dizer.

Só que o CERN tem computadores de controlo antigos e perfeitamente funcionais, mais placas especializadas feitas por medida, que não cabem nessa fasquia. Uma análise interna de 2023 indicava que uma decisão de descontinuação de microprocessadores do lado da Red Hat afectava cerca de 65 por cento dos processadores embebidos de linha da frente que estavam então em operação.

Sessenta e cinco por cento. Não é um caso limite. É a maioria do parque.

E, no momento em que isso acontece, uma escolha de software deixa de ser uma escolha de software e passa a ser uma decisão de ciclo de vida de hardware. Que é uma coisa completamente diferente, com outro orçamento, outro calendário e outro tipo de gente a ter de aprovar.

A conta que mudou a decisão: 5,4 milhões de francos e 20 por cento de hipóteses

O CERN fez o exercício a sério, e é por isso que este caso é útil e não é apenas mais uma opinião de internet.

Numa análise de risco do segundo trimestre de 2023, a equipa perguntou o que custaria manter estes sistemas de linha da frente dentro do ecossistema Red Hat. A resposta: um orçamento estimado de 5,4 milhões de francos suíços, cerca de onze placas de hardware para redesenhar, contratação de dois engenheiros electrónicos, dois engenheiros de software e dois técnicos, mais reorganização de bastidores e recablagem. E a expectativa de ter de mexer na maioria dos sistemas durante o comissionamento.

Guardem esse número por um segundo. Cinco vírgula quatro milhões de francos anda perto dos sete milhões de euros que Portugal gastou a construir o AMALIA de raiz, dezoito meses de trabalho e sessenta investigadores incluídos. É esta a ordem de grandeza de que estamos a falar, e o que se compraria com ela não era um modelo de linguagem nacional. Era o direito de continuar a usar a mesma distribuição.

O bonus está no mesmo slide: a equipa atribuiu àquele caminho uma probabilidade de sucesso de 20 por cento, e classificou esse valor como optimista, assumindo que as soluções de substituição sairiam sem bugs, contra um prazo rígido no quarto trimestre de 2026.

E convém ser rigoroso com estes números, porque já os vi a ser citados de forma torta. Aquilo não é uma poupança auditada que o Debian trouxe. É a estimativa interna do CERN para o custo do caminho alternativo. E os 20 por cento não são uma taxa de falha medida estatisticamente; são o registo de que a própria equipa tinha pouquíssima confiança em conseguir cumprir o prazo por aquela via. O valor é direccional, e é assim que deve ser lido.

Mas mesmo lido com todas as reservas, diz uma coisa que interessa a toda a gente: o custo decisivo não foi a licença. Foi a engenharia em cascata provocada por um requisito de plataforma. Placas novas, validação nova, cablagem nova, mais pessoas, mais risco de comissionamento.

A unidade económica não é o processador. Foi (É) a cadeia de controlo inteira.

Isto já tinha acontecido antes, e chamava-se CentOS

Nada disto apareceu na semana em que o Debian 13 saiu. A migração anterior, para CentOS 7, arrancou em 2014 e demorou uns dois anos até chegar a produção. Em 2022, o CERN já tinha um projecto novo a andar para escolher e preparar a plataforma seguinte.

Sistemas operativos industriais movem-se em calendários de engenharia, não em entusiasmo de dia de lançamento. Escrevo isto e sinto que devia estar tatuado nalgum sítio visível.

Pelo meio, o anúncio de Dezembro de 2020 mudou o cenário. O projecto CentOS passou o foco do CentOS Linux, a recompilação a jusante do RHEL, para o CentOS Stream, que anda à frente do RHEL actual, e anunciou o fim do CentOS Linux 8 para 2021. Quem tinha planeado dez anos de vida útil ficou com um ano e pouco.

Eu lembro-me bem dessa semana. Lembro-me de conversas em Portugal, em empresas com dezenas de máquinas a correr CentOS, onde a pergunta não era técnica. Era: e agora, quem é que eu chateio por causa disto? A resposta era ninguém, porque não havia contrato. E foi aí que muita gente aprendeu, com custos reais, a diferença entre uma coisa ser gratuita e uma coisa ser previsível.

O CERN tirou daí a lição certa. A equipa avaliou o RHEL 9 e escolheu-o para servidores e consolas de sala de controlo, porque ali fazia sentido. Mas concluiu que os sistemas embebidos de linha da frente precisavam de outro caminho, por causa da compatibilidade dos microprocessadores. E, enquanto seguia o plano principal dentro do ecossistema Red Hat, preparou o Debian como plano B.

Reparem no verbo. Preparou. Não avaliou, não considerou, não pôs num powerpoint de riscos. Preparou, com trabalho de engenharia feito antes de ser preciso.

Quando a incompatibilidade se tornou o risco maior, o plano B já estava testado. É por isso que o anúncio de 2026 parece súbito de fora e é conservador por dentro.

A vantagem verdadeira não é o preço. É saber quem tem o relógio.

Aqui está o ponto que eu queria escrever desde que li isto.

Quando se discute abandonar plataformas comerciais em favor de plataformas totalmente abertas e mantidas por comunidade, a conversa cai quase sempre no preço da licença. E o preço da licença é, quase sempre, a parte menos interessante da conta.

O que uma plataforma como o Debian dá ao CERN não é uma factura mais pequena. É o controlo do relógio de substituição.

O Debian mantém a fasquia de hardware baixa por política, não por acaso. A distribuição continua a assumir o nível base do x86 de 64 bits para o grosso do sistema, e distribui variantes optimizadas para processadores mais recentes onde isso traz benefício real, em vez de excluir máquinas. Suporta um leque largo de arquitecturas, e no Trixie até acrescentou riscv64 como arquitectura oficial. Ninguém no projecto tem incentivo comercial para simplificar a matriz de suporte cortando processadores antigos, porque não há uma matriz de suporte comercial a simplificar.

Isso não faz do Debian um sistema melhor em abstracto. Faz dele um sistema cujas assunções coincidem com as de quem tem máquinas caras que ainda funcionam.

E notem a subtileza, que é onde muita gente se engana: o CERN não escolheu a distribuição com a data de suporte mais longa. O RHEL 9 vai até Maio de 2032 e o RHEL 10 até Maio de 2035. O Debian 13 tem suporte pleno até 9 de Agosto de 2028 e LTS até 30 de Junho de 2030, com o plano de estender até 2033 por via do suporte alargado se for preciso.

Ou seja, em papel, o Red Hat oferece mais anos. O CERN escolheu na mesma o Debian para aquela camada.

Porque um ciclo de vida nominalmente mais longo não vale nada se a versão seguinte excluir a frota de processadores que está instalada. Data de fim de suporte é uma promessa sobre o software. Nível mínimo de microarquitectura é uma promessa sobre o vosso hardware. E, quando as duas colidem, é a segunda que manda.

A segunda vantagem: um contrato social não pode ser comprado

Há um argumento que raramente aparece nestas discussões e que eu acho o mais forte de todos.

Uma distribuição comercial pertence a uma empresa. Empresas são compradas, mudam de estratégia, mudam de dono, mudam de política de licenciamento e, ocasionalmente, mudam tudo isso num comunicado de imprensa de sexta-feira à tarde. Já vimos isso acontecer no mundo Linux mais do que uma vez, e já vimos as consequências para quem tinha construído dez anos de automação em cima do pressuposto contrário.

O Debian não tem accionistas. Tem um contrato social publicado, uma constituição, um líder eleito, e um processo de decisão que se pode acompanhar em listas públicas. É lento, é ocasionalmente exasperante, e tem discussões que duram anos sobre coisas que uma empresa resolveria numa reunião de vinte minutos.

Mas há uma coisa que ninguém pode fazer: ninguém pode comprar o Debian e mudar-lhe as regras. Não existe a operação. Não há para onde enviar o cheque.

Para uma organização que planeia manutenção de máquinas a dez e vinte anos, isso não é romantismo de software livre. É gestão de risco de fornecedor, escrita em linguagem que qualquer auditor entende.

Escrevi aqui num dos posts de Agosto sobre uma empresa americana que suspendeu o acesso aos seus modelos de topo por causa de controlos de exportação e o restabeleceu semanas depois. O princípio é exactamente o mesmo, apenas noutra camada da pilha. A pergunta a fazer nunca é se o fornecedor é bom. É o que acontece se o fornecedor mudar de ideias, e quanto custa reagir.

A terceira vantagem: pagar para ter voz em vez de pagar para ter factura

Esta é a parte que mais me agradou de toda a apresentação, e que provavelmente será a que mais gente irá ignorar.

O CERN começou a patrocinar a Freexian, a empresa que suporta boa parte do trabalho de longo prazo do Debian, precisamente para reforçar o ecossistema de que passou a depender.

Pensem no que isto significa em termos de relação. Numa licença empresarial, o dinheiro compra suporte, garantias contratuais e alguém que atende o telefone. O que não compra é influência sobre a fasquia mínima de microarquitectura da versão seguinte. Essa decisão é tomada noutro sítio, por outras razões, e vocês recebem-na feita.

Num modelo de patrocínio da comunidade, o dinheiro compra menos garantias formais e mais participação. Financia-se o suporte alargado que se vai precisar, contribui-se para as ferramentas, e a organização passa a estar dentro da conversa em vez de a receber por email.

Nem tudo o que é aberto e comunitário é gratuito, e é bom que não seja. Um Debian que só tenha utilizadores e não tenha financiadores é frágil. O CERN percebeu isso e agiu em conformidade. Se alguma coisa há a copiar deste caso para uma organização portuguesa, é isto: se a vossa operação depende de um projecto aberto, ponham uma linha no orçamento para o sustentar. É a coisa mais barata que vão fazer no ano inteiro e a que mais reduz o risco.

Mas a parte que interessa mesmo não é o Debian. É o layer portátil.

Se este post tem uma tese, aqui está ela.

A coisa mais valiosa que o CERN construiu não foi uma migração para Debian. Foi a capacidade de migrar.

Já em 2023, a equipa descrevia o trabalho de refazer a infraestrutura de configuração para ser agnóstica em relação à distribuição e capaz de suportar várias distribuições em paralelo. Ansible para instalação e configuração, ferramentas para automatizar e transformar a migração de sistema operativo numa linha de montagem em vez de num evento. Em 2026, a lição final da apresentação é literalmente essa: portabilidade entre distribuições é um requisito de desenho.

E o contexto torna isso ainda mais espantoso, porque estes computadores não são servidores normais. São máquinas sem disco, que arrancam pela rede, e que muitas vezes precisam de drivers de kernel feitos em casa para hardware feito em casa. Não dá para clonar a instalação anterior e mudar o nome. Foi preciso repensar como se distribuem os componentes do sistema operativo e como encaixam os drivers num ambiente Debian.

Isto é o que separa uma organização que troca de fornecedor por opção de uma organização que troca de fornecedor em pânico.

A portabilidade converte a mudança de plataforma de emergência em opção. E, uma vez que existe, muda a posição negocial: quem consegue testar duas distribuições contra as mesmas camadas de configuração e aplicação avalia mudanças futuras por mérito de engenharia, e não por medo da migração.

Reparem que o CERN mantém RHEL nalgumas camadas e adopta Debian noutra. Operar várias distribuições em simultâneo pode ser uma decisão intencional e saudável, desde que as ferramentas partilhadas tenham sido desenhadas para isso. O que quase nunca acontece, porque é chato, não dá para demonstrar em reunião e ninguém o pede.

O movimento estratégico do CERN não foi escolher o Debian. Foi recusar tornar qualquer distribuição insubstituível. O Debian é o beneficiário desta ronda. Podia ser outro na próxima, e é precisamente esse o ponto.

Traduzindo isto para a nossa escala

Ninguém que me lê tem 2200 sistemas embebidos espalhados por 27 quilómetros. Podem ter dezenas de milhar de servidores (ou VM’s a correr). Mas não embebidos. Aqui o padrão repete-se com uma fidelidade quase irritante, e repete-se em três sítios que conheço bem.

O primeiro é o homelab. Aquela máquina que já lá está, com sete ou oito anos, um Xeon de segunda mão comprado no OLX, que corre containers sem se queixar. Se a distribuição que lá tem decidir subir a fasquia de microarquitectura, a máquina não fica lenta. Fica fora. E vocês vão descobrir isso, com sorte, no meio de uma actualização, num domingo à noite.

O segundo é a PME industrial. A fábrica na Marinha Grande ou em Águeda com um computador ligado a uma máquina de produção que custou seis dígitos e que trabalha lindamente. O software que a controla foi escrito por uma empresa que já não existe. Ninguém quer tocar naquilo. E, um dia, o fornecedor do sistema operativo anuncia um requisito novo e a conversa deixa de ser sobre informática e passa a ser sobre parar a linha de produção.

O terceiro é o sector público. Máquinas com uma década em serviços que funcionam, orçamentos anuais, ciclos de contratação que demoram mais do que o ciclo de vida do software que estão a comprar, e uma tolerância a paragens que é basicamente zero. É o cenário do CERN sem os engenheiros do CERN.

Nos três casos, o exercício útil é o mesmo e faz-se numa tarde.

Comecem pelo hardware e pelo calendário de manutenção, não por um ranking de popularidade de distribuições. Façam inventário das gerações de processador, das interfaces especializadas, dos módulos de kernel, das dependências comerciais e do trabalho físico que é desencadeado por substituir um computador. Depois cruzem isso com as fasquias de arquitectura e as datas de fim de suporte de quem vos fornece. Um requisito de software pequeno pode expor uma factura de substituição enorme, e o objectivo é descobrir isso antes de o prazo estar a três meses.

A segunda decisão é organizativa. Desenhem a configuração, a distribuição de pacotes e a instalação de aplicações de forma a que outra distribuição possa entrar antes de ser urgente. Corram a alternativa em paralelo durante a validação. O CERN tinha dezenas de máquinas Debian a funcionar antes de apontar para as 2200, e isso é implantação faseada, não um corte de fita.

A terceira decisão é sobre quem assina por baixo. E é aqui que chegamos, finalmente, à parte incómoda.

As desvantagens, que existem e são reais

Não vou fazer de conta que isto é um passeio.

Primeiro, ferramentas de construção de pacotes. Os engenheiros do CERN foram explícitos: não encontraram ferramenta padrão que servisse as suas necessidades de construção e publicação automatizada de pacotes. Ferramentas a montante como o buildd e o dak são altamente especializadas. Avaliaram o Debusine, o Open Build Service e outras opções e concluíram que as limitações as tornavam inadequadas para este caso. Acabaram a desenvolver um plugin de Koji para acrescentar suporte a pacotes Debian e reaproveitar a infraestrutura que já tinham, orientada a RPM. Também tiveram de criar uma abordagem própria para módulos binários de kernel, e encontraram ferramentas de repositório que não lidam com várias versões do mesmo pacote como o fluxo de trabalho deles exige.

Traduzindo: escolher Debian não eliminou trabalho de integração. Transferiu esse trabalho para dentro de casa. O CERN consegue absorver isso porque tem equipas especializadas e uma razão operacional clara. Uma organização com dois administradores de sistemas e trinta outros problemas provavelmente não consegue.

Segundo, o suporte formal. A própria página de Linux do CERN classifica o Debian como suporte limitado e restringe-o aos sistemas de linha da frente dos aceleradores. Não há aqui nenhuma coroação. Há uma organização a atribuir distribuições diferentes a perfis de risco diferentes, e a assumi-lo por escrito.

Terceiro, a governação distribui-se. Numa distribuição empresarial, as promessas de ciclo de vida, o suporte e as expectativas de integração concentram-se numa relação comercial. No Debian, a responsabilidade espalha-se pelo projecto, pelos mantenedores de pacotes, pelas equipas de segurança e pelos utilizadores que precisam de extensões especializadas. Isso funciona quando o operador está disposto a participar no ecossistema de que depende. Quando o trata como electrodoméstico selado, não funciona.

Quarto, e este é o que mais dói em Portugal: certificações e matrizes de suporte de terceiros. Software comercial de bases de dados, sistemas de gestão, ferramentas de backup empresariais e drivers de fornecedores de hardware são frequentemente certificados para RHEL e derivados, e não para Debian. Podem correr à mesma. Só que, quando houver um problema e for preciso abrir um caso de suporte, a primeira pergunta vai ser qual é a distribuição, e a segunda vai ser um pedido educado para reproduzir o problema numa plataforma suportada. Isto não é um detalhe: é frequentemente o argumento que mata a discussão em ambientes regulados.

Quinto, a tentação de achar que a mudança é definitiva. Os próprios engenheiros avisam contra assumir que um sistema que funciona numa versão vai funcionar automaticamente na seguinte. A dívida de integração não desaparece; muda de credor.

Onde é que isto nos deixa

O calendário é quase bonito. No dia 31 de Agosto, o complexo de aceleradores e a Fábrica de Antimatéria entregaram os últimos feixes e entrou-se no Long Shutdown 3, o grande período de manutenção e melhoramentos, com regressos progressivos a partir de 2028 e o LHC de alta luminosidade previsto para meados de 2030. A meta de pôr as 2200 e tal máquinas em Debian 13 até ao final de 2026 cai exactamente no início dessa paragem.

Isso dá uma janela invejável. Não elimina o risco. A camada de linha da frente ainda tem de arrancar de forma fiável, carregar os drivers específicos do CERN, entregar aplicações e sobreviver à validação operacional que vem a seguir.

E é por isso que a próxima coisa a observar não é um gráfico de benchmarks nem mais um aplauso em conferência. É o registo de funcionamento destas máquinas enquanto o CERN reconstrói e recomissiona o complexo. Se a implantação fechar no prazo e a frota atravessar a paragem longa sem surpresas específicas da distribuição, a tese sai reforçada. Se a construção de pacotes, o suporte ou as transições futuras do Debian recriarem exactamente o tipo de dependência de que se estavam a libertar, sai enfraquecida.

Fico com uma conclusão que não é a que o título dos agregadores prometia, e que acho bastante mais útil.

O CERN não provou que o Debian é a melhor distribuição do mundo. Provou que, quando o hardware vive mais tempo do que o roteiro de qualquer fornecedor, quem controla o relógio de substituição vale mais do que quem oferece a data de fim de suporte mais longínqua. E provou que se paga esse controlo com trabalho próprio de integração, com competência interna e com dinheiro a financiar o ecossistema, não com uma poupança na licença.

A pergunta a levar deste caso não é qual a distribuição que devem instalar. É esta: se o vosso fornecedor de plataforma anunciar amanhã um requisito que exclui metade das vossas máquinas, quanto tempo demoram a ter uma alternativa a correr, e quem é que faz esse trabalho?

Se a resposta for que ninguém sabe, isso não é um problema de Linux. É um problema de arquitectura, e resolve-se antes de existir, que é a única altura em que é barato.

Até ao próximo post!
Nuno

Documentação:

Artigo de origem

A apresentação e o caso do CERN

As fasquias de microarquitectura

Debian

Cobertura independente

Nota: Este post foi feito com o auxílio de um LLM privado.

Related Posts