Histórico do kernel Linux: decisões que ficaram

A versão curta do histórico do kernel Linux

A história do kernel Linux vai da versão 0.01, em setembro de 1991, à série 7.x, que hoje arranca em servidores. A lista de releases é a parte menos interessante. Um pequeno número de decisões definiu a forma do projeto, e cada uma ainda tem consequências numa máquina que alugue esta tarde. A razão pela qual foi necessário um novo kernel em 1991 faz parte de uma história mais longa sobre Unix, o licenciamento da AT&T e o processo judicial que atrasou o BSD.

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. O estado atual, em agosto de 2026, é o seguinte: 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 fase de release candidates.

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: "You may not distribute this for a fee, not even 'handling' costs." 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 mudou a licença. A adoção da 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 publicada sob essa licença. Todos os negócios criados posteriormente com base no Linux dependem dessa mudança.

O kernel está licenciado somente sob a GPL versão 2 e nunca passou para a versão 3. Torvalds recusou essa 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 um assunto comercial do fabricante. Em 2017, os desenvolvedores do kernel publicaram o 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 licença, em vez de perdê-la permanentemente na primeira violação.

Isso produz duas consequências num servidor. O binário do kernel que arranca dá direito ao código-fonte correspondente. Portanto, ninguém pode fornecer um kernel Linux que não possa ser inspecionado ou recompilado. O aviso de copyright do kernel também informa que a licença não abrange programas de utilizador que utilizam os serviços do kernel por meio 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 uma pressão oposta. Vale a pena entender 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 newsgroup comp.os.minix. Ele apresentou duas afirmações. Os kernels monolíticos, nos quais os drivers e os sistemas de ficheiros executam num único espaço de endereçamento privilegiado, eram um projeto dos anos 1970, enquanto os microkernels, nos quais essas partes executam como processos comuns, eram o futuro. Além disso, o Linux estava preso ao Intel 386 e nunca seria portável para outras plataformas.

A afirmação sobre portabilidade foi respondida com ports. 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 um port de 64 bits para Alpha.

A afirmação sobre o projeto foi respondida com um compromisso. O Linux nunca se tornou um microkernel. 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 caminho de armazenamento e de rede é composta por módulos. É por isso que uma única imagem do kernel arranca em hardware que nunca encontrou antes. O kernel apenas anuncia o novo hardware, e um daemon do espaço de utilizador decide que módulo carregar e que nome atribuir ao dispositivo. Foi assim que a gestão de dispositivos passou a integrar o sistema init, e essa é uma das razões pelas quais o systemd se tornou difícil de evitar.

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

O custo que o Linux manteve é o que deve ser considerado no planeamento: um módulo executa com privilégios completos do kernel. Por isso, um módulo defeituoso pode fazer toda a máquina parar, 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 está incluído no mainline 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, mais de uma CPU executando um kernel. A primeira implementação usava um único bloqueio, o big kernel lock (BKL), portanto apenas um processador podia executar código do kernel de cada vez. Por isso, uma segunda CPU ajudava uma carga de trabalho que fazia os cálculos no espaço do utilizador, mas ajudava muito pouco uma carga baseada em chamadas de sistema, porque essas chamadas ficavam em fila atrás do mesmo bloqueio.

A remoção desse bloqueio levou quinze anos. Os pontos restantes 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 não é nada fora do comum atualmente. Ele também evidencia um limite que vale a pena conhecer. Num servidor virtual partilhado, o seu kernel escalona as suas threads, e o hypervisor escalona o seu kernel. Execute top e leia o campo %st. 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 versão 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 correçõ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. Atualmente, a mainline abre uma merge window de cerca de duas semanas, aceita trabalho novo, depois executa release candidates até o desenvolvimento estabilizar e lança uma nova versão a cada 9 a 10 semanas, conforme continua documentado em kernel.org. 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 recusa funcionalidades.

Um efeito secundário foi o número da versão deixar de ser uma promessa. As versões 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 branch a distribuição acompanha e se essa branch ainda recebe correções.

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

A partir de fevereiro de 2002, o kernel passou a ser 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 desenvolvedores 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 desenvolvedores não gostavam de criar um kernel livre com uma ferramenta cujo código não podiam 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 self-hosting, o que significa que o próprio histórico do git já era mantido no git. A primeira integração de vários branches ocorreu em 18 de abril. Em junho de 2005, o git geriu o lançamento da versão 2.6.12. Pouco depois, Torvalds passou a manutenção para Junio Hamano e voltou ao kernel.

O design 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 alegação. Cada pipeline de deploy, cada repositório de configuração, o servidor de código para onde a maioria das equipas envia alterações e o servidor git que pode executar por conta própria surgiram de uma discussão sobre licenciamento relacionada com um kernel.

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

Mainline não é 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 por 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 dezembro de 2009, foi a que comprovou o modelo. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 e Ubuntu 10.04 LTS incluíram-na, e a branch foi mantida até fevereiro de 2016, mais de seis anos depois do seu lançamento. A Red Hat foi ainda mais longe. Manteve o seu kernel baseado em 2.6.32 com backports próprios até ao fim do RHEL 6 em 2020. Reproduzir gratuitamente essa década de suporte é precisamente a razão pela qual o CentOS existiu e o Rocky Linux e o AlmaLinux o substituíram.

A duração do suporte mudou mais de uma vez. Inicialmente eram dois anos. Depois, algumas branches passaram a ter seis anos. Em 2023, os maintainers do stable reduziram novamente o padrão para dois anos. O backport de correções para árvores antigas consome tempo dos maintainers, e as branches antigas são pouco testadas na prática. Em 25 de fevereiro de 2026, Greg Kroah-Hartman voltou a publicar projeções mais longas, depois de discutir o tema com as empresas que dependem dessas branches. O modelo atual prevê 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 agosto de 2026. A mais antiga, 5.10, terá recebido correções durante 6.0 anos quando terminar em Dec 2026. A mais recente, 6.18, deverá ser mantida até Dec 2028, o que corresponde a 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 fevereiro de 2026. No entanto, uma branch sem utilizadores pode ser abandonada. Normalmente, a sua distribuição escolhe por si. O Debian 13 inclui a versão 6.12, e o Ubuntu 26.04 LTS inclui a versão 7.0. Essa diferença é o conteúdo prático de a questão entre LTS e versões intermédias num servidor. É também o que muda efetivamente no sistema quando atualiza o Ubuntu 24.04 para o 26.04.

Há uma armadilha relacionada com isto. uname -r no Ubuntu 24.04 apresenta algo semelhante a 6.8.0-51-generic. Esse valor combina uma base upstream com os backports da própria 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 apenas pela sua cadeia de versão geram falsos alarmes contra kernels de distribuições precisamente por este motivo.

O que o kernel está discutindo neste momento

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

O Rust entrou na 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 passaram a ser C, assembly e Rust, e a compilação já não precisa de um compilador nightly. A discussão diz respeito à manutenção. Um mantenedor de C que altera uma interface pode quebrar bindings Rust que não lê. A questão é saber de quem é a responsabilidade de corrigi-los.

A segunda discussão diz respeito às contribuições de IA. Sasha Levin propôs uma política em julho de 2025, depois de um aumento no volume de patches assistidos por máquinas enviados para as listas. O documento foi submetido em 23 de dezembro de 2025 e está agora na documentação do próprio processo do kernel, em docs.kernel.org/process/coding-assistants.html. Um agente de IA não pode adicionar uma tag Signed-off-by, porque essa linha certifica o Developer Certificate of Origin (DCO), e apenas uma pessoa pode fazer essa certificação. A assistência é declarada com uma tag Assisted-by:, alterada de Co-developed-by: durante a revisão porque uma ferramenta não é um autor. O código gerado deve 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 por trás da política é o tempo de revisão. Gerar um patch demora segundos, mas revê-lo pode ocupar uma tarde do mantenedor. Uma tag 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 esse histórico significa para o servidor que você aluga

• A licença permite ler e recompilar o kernel iniciado pelo seu provedor e explica por que software proprietário continua funcionando nele.
• O design monolítico faz com que um erro em um driver reinicie a máquina inteira e exige que um módulo externo seja recompilado a cada atualização do kernel.
• O modelo de releases faz com que o número da versão diga pouco. A branch e a data de fim de vida útil dizem quase tudo.
• O tipo de virtualização determina o que você pode fazer: no KVM, você inicia o seu próprio kernel e carrega módulos; na virtualização por contêiner, que compartilha o kernel do host, uname -r mostra a versão do host, modprobe falha e vários sysctls são somente leitura.

FAQ

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

Torvalds decidiu não adotar 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. Ele considera o hardware bloqueado uma decisão comercial 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 ao qual recorrer. O kernel está sob a GPL-2.0-only, portanto código oferecido 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 drivers e os sistemas de ficheiros são executados no espaço de endereçamento do kernel, e lsmod mostra os que estão carregados neste momento. O resultado é mais velocidade, por um lado, e um maior raio de impacto, por outro: um módulo com falhas pode causar um panic em toda a máquina, enquanto num microkernel apenas um processo seria perdido. 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. É nela que as novas funcionalidades são integradas primeiro. Stable parte da versão mainline mais recente e recebe correções de erros durante algumas semanas. As branches longterm continuam a receber correções durante anos. É nelas que as distribuições baseiam os seus kernels. O kernel.org apresenta as branches longterm atuais e a data de fim de vida prevista para cada uma.

O kernel Linux aceita código escrito por IA?

Sim, ao abrigo de uma política adotada em dezembro de 2025. A ferramenta tem de ser identificada numa tag Assisted-by:. Um agente de IA não pode adicionar uma linha Signed-off-by. O código gerado tem de ser compatível com a GPL-2.0-only. O autor humano da submissão assina a alteração. Isto 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 quase totalidade dos casos, a versão mantida pela sua distribuição. Um kernel de distribuição combina uma branch longterm, correções integradas posteriormente e os testes do fornecedor. É essa versão que as imagens do seu fornecedor e os seus acordos de suporte pressupõem. Compile um kernel mainline mais recente quando precisar de um driver ou de uma funcionalidade específica. Antes de se comprometer com essa mudança, confirme a data de fim de vida da branch para a qual vai migrar.