O Linux 6.18 foi lançado em 30 de novembro de 2025 com uma combinação rara de ousadia técnica e pragmatismo operacional. Ele é o tipo de versão que não soa como “mais uma atualização”, e sim como um ponto de base para quem toma decisões de arquitetura. Não por acaso, muita gente já olha para esta geração como a candidata natural ao papel de LTS do ano, e é exatamente isso que torna o pacote de “Linux 6.18 LTS features” tão relevante para CTOs e sysadmins.
A melhor analogia é a do prédio. Releases comuns de kernel são reformas em andares específicos, com melhorias pontuais em encanamento, elétrica ou fachada. Um kernel que vira LTS costuma ocupar outro lugar no imaginário do ecossistema: ele vira a fundação de um novo arranha-céu, o concreto no qual distribuições, clouds, hypervisors, appliances e dispositivos vão apoiar anos de trabalho. E o 6.18 chega com reforços claros nessa “armadura”: de enablement de hardware (Apple M2, AMD Zen 6, Intel Wildcat Lake) a mudanças profundas em cache, I/O e sistemas de arquivos que parecem desenhadas para aguentar o tranco de produção.
O provável LTS de 2025 (e por que esse rótulo muda tudo)
É importante ser preciso: no momento do lançamento, o 6.18 é o mainline mais recente, mas ainda não existe uma confirmação formal de que ele já seja a série LTS. No kernel.org, as séries longterm em destaque seguem outras linhas. Ainda assim, existe um motivo objetivo para o mercado enxergá-lo como o favorito: ele é o último grande lançamento de 2025 e, historicamente, esse “último do ano” tende a ser o candidato mais conveniente para receber manutenção prolongada.
Na prática, o que muda se ele virar LTS não é só status. Muda planejamento. Muda política de backports. Muda o quanto um fornecedor se sente confortável em padronizar uma frota enorme em cima de uma base. Para enterprise, um LTS significa mais previsibilidade, menos “surpresas” no meio do ciclo e uma plataforma-alvo estável para certificações, drivers e compliance. Se você administra um parque com milhares de nós, a diferença entre “novo e empolgante” e “novo, empolgante e sustentado por anos” é a linha que separa piloto de produção.
Apple, AMD e Intel: o novo hardware entrando no ritmo do mainline
O Linux 6.18 é um lembrete de como o mainline molda o futuro do suporte a hardware. O avanço mais simbólico aparece na Apple: chega o suporte inicial ao Apple M2 nas variantes Pro, Max e Ultra, com Device Trees upstreamados. Isso tem um peso histórico, porque é o momento em que o kernel oficial começa a carregar, nativamente, os “mapas” necessários para entender Macs mais potentes sem depender completamente de árvores externas.
Ao mesmo tempo, o texto precisa ser honesto com usuários finais: esse suporte está em “early form”. Para uso diário com melhor aceleração e polimento, a recomendação prática ainda tende a ser o Asahi Linux, que carrega o downstream mais completo para Apple Silicon. O que o 6.18 sinaliza, porém, é o caminho sem volta: o mainline está absorvendo as peças estruturais que tornam o ecossistema sustentável.
Do lado x86, o kernel também se prepara para o amanhã. Há trabalho de base para AMD Zen 6, aquele tipo de preparação que parece invisível até o dia em que OEMs começam a enviar máquinas e você percebe que não precisou de um “patch de emergência” para bootar. Na Intel, o destaque vai para suporte de display do Wildcat Lake, associado ao caminho de gráficos Xe3 em hardware mais enxuto. Para quem opera frotas corporativas e precisa manter uma matriz de compatibilidade saudável, esses movimentos no kernel principal são o verdadeiro “hardware enablement”.
Performance: Sheaves e DM-PCACHE como engenharia de latência
Se você precisar de um argumento técnico para justificar o 6.18 como “fundação”, ele está aqui. O kernel ganhou duas peças que conversam diretamente com latência e throughput, duas palavras que definem o custo de produção em datacenters.
O Sheaves é uma mudança inteligente no universo do alocador SLUB. Em vez de tratar toda alocação como uma ida ao “estoque central”, ele introduz um cache opt-in por CPU, baseado em arrays, com dois conceitos importantes: a “sheaf” e o “barn”. Pense em uma fábrica: cada estação de trabalho (CPU) passa a ter uma bandeja local com as peças mais usadas (a sheaf), e quando a bandeja esvazia ela é reabastecida a partir de um depósito maior do mesmo “bairro” (o barn), reduzindo idas e voltas ao estoque global e, principalmente, reduzindo conflito entre CPUs e tráfego de cache inter-core. É o tipo de otimização que não aparece em uma lista de features de desktop, mas pode significar menos latência em caminhos quentes e melhor eficiência sob concorrência.
Já o DM-PCACHE entra como uma peça com DNA enterprise. Ele é um target do Device Mapper que usa uma região de memória persistente (pmem) acessada via DAX como cache de alta performance à frente de um dispositivo de bloco mais lento. A analogia aqui é ótima para explicar o “por que” da tecnologia: muitos caches são como post-its grudados em uma mesa, rápidos, mas se a energia cai você perde o recado. O DM-PCACHE, por se apoiar em memória persistente, é mais parecido com um caderno de anotações que continua existindo após um reboot, permitindo um cache de leitura e escrita com características de persistência e recuperação (replay) que fazem sentido em ambientes críticos. Para cargas intensas de storage, virtualização e bancos de dados, isso é uma ferramenta nova para desenhar camadas de I/O com menos latência e mais vazão.
Armazenamento: Btrfs e XFS focados em “operar sem parar”
Em sistemas de arquivos, o 6.18 ajuda a responder uma pergunta clássica de operações: “quanto downtime eu vou pagar quando algo der errado?”
No XFS, a resposta melhora porque o reparo online (online fsck) passa a vir habilitado por padrão. O benefício é direto: mais capacidade de checar e reparar metadados com o filesystem montado, reduzindo janelas de manutenção e colocando o XFS mais perto do ideal operacional de “corrigir sem desmontar”. Para quem trabalha com SLA, isso é um upgrade de maturidade.
No Btrfs, a grande manchete é o suporte inicial a tamanhos de bloco maiores que o page size, além de melhorias para paralelismo em workloads de leitura pesada. Isso derruba uma barreira de longa data e abre espaço para otimizações, mas com uma ressalva importante: esse caminho ainda tem caráter experimental e limitações em áreas específicas. A leitura correta para enterprise é “um avanço real que aponta o futuro”, não “luz verde irrestrita para todos os cenários”.
Rede e segurança: criptografia em trânsito com o PSP da Google
Para completar o retrato de “kernel fundação”, o 6.18 também traz um reforço interessante em rede e segurança: suporte inicial ao PSP Security Protocol da Google para criptografia em trânsito em conexões TCP. Ele não tem relação com o PSP de hardware da AMD, e o ponto aqui é estratégico: colocar um mecanismo de proteção no próprio transporte, no kernel, é o tipo de decisão que pode influenciar clouds e stacks internos onde eficiência e segurança precisam coexistir. Não é o fim da conversa sobre criptografia, mas é mais uma peça de infraestrutura que faz sentido em um candidato a LTS.
Gráficos: Nouveau com GSP por padrão em GPUs modernas
No desktop e em ambientes que se beneficiam de drivers abertos, o driver Nouveau dá um passo concreto: em GPUs modernas (Turing e Ampere), ele passa a usar o firmware GSP (GPU System Processor) da NVIDIA por padrão, mantendo caminhos de fallback quando necessário. O efeito mais provável dessa mudança é elevar o “piso” de experiência do Nouveau em hardware recente, com ganhos de performance e comportamento mais adequado em placas onde o GSP já é parte do mundo real.
Modernização: mais Rust, e o Binder com transição responsável
O 6.18 também reforça a modernização pelo lado da linguagem: entra mais Rust no kernel, incluindo o driver Binder em Rust, peça central no IPC do Android. Aqui, a mensagem que passa confiança para CTO e senior sysadmin é justamente a prudência: o kernel não “vira a chave” de uma vez. O Binder antigo em C e o novo em Rust coexistem por alguns ciclos, para que compatibilidade e precisão do comportamento sejam validadas antes de qualquer transição definitiva. Isso é o tipo de gestão de risco que combina com a mentalidade LTS.
Um detalhe que diz muito sobre estabilidade: quando algo sai do mainline
Por fim, existe um sinal pequeno, mas importante, para o discurso de “base sólida”: o 6.18 também marca a remoção do Bcachefs do mainline, após ele ter sido tratado como “externamente mantido” antes. O ponto não é polêmica, e sim governança: quando um componente não está no estado ideal para acompanhar o ritmo e o modelo de manutenção do kernel principal, a decisão de removê-lo evita confusão de versões e reduz risco operacional. Para um kernel com ambição de LTS, esse tipo de escolha é parte do concreto.
