História do kernel Linux: decisões que ainda valem

A breve história do kernel Linux

A história do kernel Linux vai da versão 0.01, em setembro de 1991, à série 7.x, que atualmente arranca em servidores. A lista de versões é a parte menos interessante. Um pequeno número de decisões definiu a sua estrutura, e cada uma ainda tem consequências numa máquina que alugue hoje à tarde.

As datas e os números de versão apresentados aqui vêm de kernel.org e do histórico de versões que o site publica. Estado atual, em agosto de 2026: a versão 7.0 foi lançada em 12 de abril de 2026, a 7.1 em 14 de junho de 2026, e a 7.2 está em versões candidatas.

Por que a escolha da GPL em 1992 ainda é importante

A versão 0.01 foi publicada em 17 de setembro de 1991 sob uma licença escrita pelo próprio Torvalds. Ela exigia que o código-fonte fosse distribuído e acrescentava uma frase mais importante: "Você não pode distribuir isto mediante pagamento, nem mesmo para cobrir custos de 'manuseamento'." Em 1991, o software era distribuído em disquetes, e copiar e enviar disquetes tinha custos. Essa cláusula tornava impossível uma distribuição comercial do Linux.

Ele alterou a licença. A mudança para a GNU General Public License (GPL) foi anunciada nas notas de lançamento da versão 0.12 em janeiro de 1992 e entrou em vigor em 1 de fevereiro de 1992. A versão 0.95, em março de 1992, foi a primeira versão publicada sob essa licença. Todas as empresas posteriormente construídas sobre o Linux dependem dessa alteração.

O kernel está sob a GPL versão 2 apenas e nunca passou para a versão 3. Torvalds recusou a mudança em 2007, principalmente por causa da regra anti-tivoização da GPLv3, que exige que um dispositivo que distribua código GPL também aceite uma cópia modificada desse código. Ele considerava o hardware bloqueado uma decisão comercial do fabricante. Em 2017, os developers do kernel publicaram a Kernel Enforcement Statement, que incorpora, ainda assim, um elemento da GPLv3: quem corrige uma violação depois de ser informado sobre ela mantém a sua licença, em vez de a perder permanentemente na primeira violação.

Num servidor, há duas consequências. O binário do kernel que arranca inclui o direito ao código-fonte correspondente. Por isso, ninguém pode fornecer-lhe um kernel Linux que não possa inspecionar ou recompilar. Além disso, o aviso de copyright do kernel indica que a licença não abrange programas de utilizador que utilizem os serviços do kernel através de chamadas de sistema normais. É por isso que bases de dados proprietárias e agentes de monitorização são distribuídos para Linux sem causar problemas de licenciamento. Uma licença permissiva cria a pressão oposta, e vale a pena compreender essa diferença antes de escolher uma plataforma: consulte Linux e FreeBSD como plataformas de servidor.

Por que o kernel monolítico venceu na prática

Em 29 de janeiro de 1992, Andrew Tanenbaum publicou uma mensagem intitulada "LINUX is obsolete" no grupo de notícias comp.os.minix. Ele apresentou duas afirmações. Kernels monolíticos, nos quais os drivers e os sistemas de ficheiros executam dentro de um único espaço de endereçamento privilegiado, eram um projeto dos anos 1970. Os microkernels, nos quais essas partes executam como processos normais, eram o futuro. Além disso, o Linux estava fortemente ligado ao Intel 386 e nunca seria portável para outras arquiteturas.

A afirmação sobre portabilidade foi respondida com portabilidade efetiva. A versão 1.2, em março de 1995, adicionou Alpha, SPARC e MIPS. A versão 2.0, em junho de 1996, adicionou uma portabilidade de 64 bits para Alpha.

A afirmação sobre o projeto foi respondida com um compromisso. O Linux nunca se tornou um microkernel. Em vez disso, passou a ter módulos de kernel carregáveis: ficheiros de objetos que podem ser inseridos num kernel em execução e removidos depois, permitindo distribuir um driver separadamente do binário do kernel.

lsmod | head
modinfo virtio_net | head -5

lsmod lista o que está carregado neste momento. modinfo mostra o ficheiro de origem do módulo e os parâmetros que ele aceita. Num servidor virtual, a maior parte do suporte de armazenamento e de rede é fornecida por módulos. Por isso, uma única imagem de kernel pode arrancar em hardware que nunca encontrou antes.

Os módulos proporcionaram essa flexibilidade sem o custo associado ao projeto de microkernel. Isolar um driver no seu próprio processo implica pagar o custo de uma mudança de contexto e de uma mensagem em cada chamada. Em 1992, esse custo era elevado.

O custo mantido pelo Linux é aquele que deve ser considerado no planeamento: um módulo executa com privilégios completos de kernel. Por isso, um módulo defeituoso pode deixar toda a máquina indisponível, em vez de afetar apenas um processo. É nos módulos externos à árvore principal que este problema se manifesta. Um driver de fornecedor que não esteja no kernel principal tem de ser recompilado para cada novo kernel. É isso que o DKMS faz durante uma atualização. Quando essa compilação falha, o dispositivo simplesmente fica indisponível depois do reboot.

Por que o SMP levou quinze anos para ser concluído

O Linux 2.0, lançado em junho de 1996, foi o primeiro kernel a oferecer suporte a multiprocessamento simétrico (SMP), ou seja, a executar um kernel com mais de uma CPU. A primeira implementação usava um único bloqueio, o big kernel lock (BKL), por isso apenas um processador podia executar código do kernel de cada vez. Assim, uma segunda CPU ajudava uma carga de trabalho que executasse cálculos no espaço de utilizador, mas ajudava muito pouco numa carga de trabalho composta por chamadas de sistema, porque essas chamadas ficavam em fila atrás do mesmo bloqueio.

A remoção desse bloqueio levou quinze anos. Os pontos que ainda usavam o BKL foram convertidos para bloqueios de granularidade fina, em grande parte por Arnd Bergmann, e o BKL foi removido no 2.6.39, lançado em 18 de maio de 2011. O escalonador avançou no mesmo ritmo lento: o escalonador O(1) no 2.6.0, o Completely Fair Scheduler (CFS) a partir do 2.6.23, em 2007, e o EEVDF, que substituiu o CFS no 6.6, em outubro de 2023.

Esse trabalho explica por que um plano com 4 vCPU é algo comum atualmente. Também assinala um limite que vale a pena conhecer. Num servidor virtual partilhado, o seu kernel agenda as suas threads, e o hypervisor agenda o seu kernel. Execute top e leia o campo %st. O steal time é o tempo de CPU que o seu kernel estava pronto para utilizar, mas que o host atribuiu a outro guest. Por isso, nenhum ajuste dentro do seu kernel o recupera.

Por que a série 2.6 mudou a forma como o kernel é compilado

Antes da 2.6, os números de versão vinham em pares. Um segundo número par indicava uma série estável (2.4); um número ímpar indicava desenvolvimento (2.5). A 2.4 foi lançada em 4 de janeiro de 2001 e a 2.6 em 17 de dezembro de 2003, por isso os utilizadores esperaram quase três anos pela série estável seguinte. As distribuições não podiam esperar e fizeram backport de alterações. Dois fornecedores que distribuíam a versão "2.4" podiam fornecer kernels separados por milhares de patches.

A separação foi abandonada depois da 2.6. O mainline abre agora uma janela de integração de cerca de duas semanas, aceita trabalho novo, executa depois release candidates até o desenvolvimento estabilizar e lança uma versão a cada 9 a 10 semanas, o ritmo que o kernel.org ainda documenta. A outra metade do modelo surgiu em 4 de março de 2005, com o primeiro lançamento da stable tree: uma atualização que continha apenas correções para a 2.6.11, mantida por Greg Kroah-Hartman e Chris Wright. A stable tree aceita correções e rejeita funcionalidades.

Um efeito secundário foi o número de versão deixar de ser uma promessa. 3.0, 4.0, 5.0 e 7.0 não são reescritas. Torvalds aumenta o primeiro número quando o segundo cresce o suficiente para o incomodar, razão pela qual a 7.0 sucedeu à 6.19 em abril de 2026. Para um servidor, o que importa é qual ramo a sua distribuição acompanha e se esse ramo ainda recebe correções.

Como a rutura com o BitKeeper deu origem ao git em abril de 2005

A partir de fevereiro de 2002, o kernel foi desenvolvido no BitKeeper, um sistema proprietário de controlo de versões distribuído da empresa BitMover, de Larry McVoy, começando pela série 2.5. A BitMover concedeu aos programadores do kernel uma licença gratuita com condições: não podiam trabalhar numa ferramenta de controlo de versões concorrente e não podiam fazer engenharia reversa do BitKeeper. Muitos programadores não gostavam de desenvolver um kernel livre com uma ferramenta cujo código não lhes era permitido consultar.

A situação rompeu-se em abril de 2005, depois de Andrew Tridgell demonstrar um programa que comunicava com repositórios BitKeeper. A BitMover considerou isso engenharia reversa e retirou a licença gratuita. O kernel ficou sem sistema de controlo de versões a meio de um ciclo de desenvolvimento.

O trabalho no git começou em 3 de abril de 2005. Torvalds anunciou-o em 6 de abril. Em 7 de abril, o git já era autocontido, o que significa que o próprio histórico do git já era mantido no git. A primeira integração de várias branches foi executada em 18 de abril. Em junho de 2005, o git geriu a release do 2.6.12. Pouco depois, Torvalds passou a manutenção para Junio Hamano e regressou ao kernel.

O desenho resultou diretamente do problema: milhares de contribuidores e maintainers que obtêm alterações uns dos outros através de uma rede em que ninguém confia. Cada objeto recebe um nome baseado no hash do seu conteúdo, por isso alterar um byte do histórico antigo altera o nome de cada commit posterior. É por isso que um clone é uma evidência, não uma afirmação. Cada pipeline de deploy, cada repositório de configuração, o host de código para onde a maioria das equipas faz push e o servidor git que pode executar por sua conta resultaram de uma discussão sobre licenciamento relacionada com um kernel.

O que o modelo LTS garante e o que não garante

Mainline não é a versão que deve executar. Uma versão mainline é substituída 9 a 10 semanas depois. A árvore stable recebe correções durante algumas semanas após cada versão. As branches longterm, normalmente designadas como LTS, recebem correções durante anos. São essas branches que as distribuições usam como base.

A versão 2.6.32, lançada em December 2009, foi a primeira prova do modelo. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 e Ubuntu 10.04 LTS incluíram essa versão, e a branch foi mantida até February 2016, mais de seis anos depois do seu lançamento.

A duração do suporte mudou mais de uma vez. Primeiro eram dois anos. Depois passaram a ser seis anos para algumas branches. Em 2023, os maintainers do stable reduziram novamente o período padrão para dois anos, porque fazer backport para árvores antigas consome tempo dos maintainers e as branches antigas recebem poucos testes reais. Em 25 February 2026, Greg Kroah-Hartman publicou novamente projeções mais longas, depois de discutir o assunto com as empresas que dependem dessas branches. O modelo atual varia entre três e seis anos.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

O kernel.org lista 6 branches longterm em August 2026. A mais antiga, 5.10, terá recebido correções durante 6.0 anos quando chegar ao fim em Dec 2026. A mais recente, 6.18, deverá ser mantida até Dec 2028, totalizando 3.1 anos de correções.

Considere essas datas como um limite mínimo, não como um contrato. As projeções para 6.6 e 6.12 foram ambas prolongadas em February 2026. No entanto, uma branch que ninguém usa pode ser abandonada. Normalmente, a sua distribuição toma essa decisão por si: Debian 13 inclui 6.12, e Ubuntu 26.04 LTS inclui 7.0. Essa diferença é o conteúdo prático da questão sobre usar LTS ou uma versão intermédia num servidor. É também o que realmente muda no sistema quando atualiza Ubuntu 24.04 para 26.04.

Daqui resulta uma armadilha. uname -r no Ubuntu 24.04 apresenta algo semelhante a 6.8.0-51-generic. Isso representa uma base upstream com backports próprios da distribuição. Portanto, o número indica onde a branch começou, mas não quais correções estão incluídas. Os scanners que avaliam um kernel pela sua cadeia de versão geram falsos alarmes contra kernels das distribuições exatamente por esse motivo.

Sobre o que o kernel está a discutir neste momento

Há duas discussões em curso, e ambas dizem respeito a quem faz o trabalho.

Rust tornou-se parte da infraestrutura na versão 6.1, em dezembro de 2022. Na versão 7.0, a indicação de experimental foi removida. As linguagens principais do kernel são, portanto, C, assembly e Rust, e a compilação já não precisa de um compilador nightly. A discussão diz respeito à manutenção. Um maintainer de C que altera uma interface pode quebrar bindings de Rust que não lê. A questão é saber de quem é a responsabilidade de os corrigir.

A segunda discussão diz respeito às contribuições de AI. Sasha Levin propôs uma política em julho de 2025, depois de um volume crescente de patches assistidos por máquinas ter chegado às listas. O documento foi submetido em 23 de dezembro de 2025 e está agora na documentação do próprio kernel sobre processos, em docs.kernel.org/process/coding-assistants.html. Um agente de AI não pode adicionar uma etiqueta Signed-off-by, porque essa linha certifica o Developer Certificate of Origin (DCO) e só uma pessoa pode fazer essa certificação. A assistência é declarada com uma etiqueta Assisted-by:, alterada de Co-developed-by: durante a revisão porque uma ferramenta não é um autor. O código gerado tem de ser compatível com GPL-2.0-only. A pessoa que envia o patch revê-o e assume a responsabilidade por ele.

A pressão que levou à política é o tempo de revisão. Gerar um patch demora segundos, mas revê-lo pode ocupar a tarde de um maintainer. Uma etiqueta não corrige esse desequilíbrio. O que ela preserva é a proveniência: o histórico continua a registar quem assinou cada alteração. Essa é a propriedade que o DCO foi criado para proteger em 2004.

O que este histórico significa para o servidor que arrendou

• A licença explica por que pode ler e recompilar o kernel que o seu fornecedor inicia, e por que o software proprietário continua a funcionar nele.
• O design monolítico explica por que um erro num driver reinicia a máquina inteira, e por que um módulo externo à árvore do kernel tem de ser recompilado a cada atualização do kernel.
• O modelo de lançamento explica por que o número da versão diz pouco, enquanto o branch e a respetiva data de fim de vida dizem quase tudo.
• O tipo de virtualização determina o que pode fazer: no KVM, inicia o seu próprio kernel e carrega módulos; na virtualização por contentores, que partilha o kernel do host, uname -r mostra a versão do host, modprobe falha e vários sysctls são só de leitura.

FAQ

Por que o kernel Linux continua sob a GPLv2 e não sob a GPLv3?

Torvalds rejeitou a GPLv3 em 2007, principalmente por causa do requisito contra a tivoização, que obriga um dispositivo que distribui código GPL a aceitar também uma versão modificada desse código. Para ele, o bloqueio do hardware faz parte do negócio do fabricante. Na prática, relicenciar também é quase impossível, porque os direitos de autor do kernel pertencem a milhares de contribuidores e não existe um acordo de cessão que possa ser usado como alternativa. O kernel está sob a GPL-2.0-only, portanto código disponibilizado apenas sob a GPLv3 não pode ser integrado.

O kernel Linux é monolítico ou é um microkernel?

É monolítico, com módulos carregáveis. Os controladores e os sistemas de ficheiros executam no espaço de endereçamento do kernel, e lsmod mostra os que estão carregados neste momento. O efeito é maior velocidade, por um lado, e maior área de impacto, por outro: um módulo com falhas pode causar um panic em toda a máquina, enquanto num microkernel seria perdido apenas um processo. Esta distinção tornou-se menos rígida desde 1992, com sistemas de ficheiros FUSE no espaço de utilizador e programas eBPF que o kernel verifica antes de os executar.

Qual é a diferença entre os kernels mainline, stable e longterm?

Mainline é a árvore de Torvalds, lançada a cada 9 a 10 semanas. As novas funcionalidades são integradas primeiro nessa árvore. Stable recebe a versão mainline mais recente e correções de erros durante algumas semanas. Os ramos longterm continuam a receber correções durante anos e são a base dos kernels das distribuições. O kernel.org lista os ramos longterm atuais e a data prevista de fim de vida de cada um.

O kernel Linux aceita código escrito por IA?

Sim, ao abrigo de uma política adotada em December 2025. A ferramenta tem de ser indicada numa etiqueta Assisted-by:, um agente de IA não pode adicionar uma linha Signed-off-by e o código gerado tem de ser compatível com a GPL-2.0-only. O autor humano assina a submissão, o que significa que reviu o patch e assume a responsabilidade por ele ao abrigo do Developer Certificate of Origin.

Que versão do kernel devo executar num servidor?

Na maioria dos casos, a versão mantida pela sua distribuição. Um kernel de distribuição é um ramo longterm com correções integradas posteriormente e os testes do fornecedor. É também a versão pressuposta pelas imagens do seu fornecedor e pelos seus acordos de suporte. Compile um kernel mainline mais recente quando precisar de um controlador ou de uma funcionalidade específica. Antes de se comprometer com a mudança, confirme a data de fim de vida do ramo para o qual vai migrar.