A história do kernel Linux: do projeto de um estudante ao Linux 7.2

O kernel Linux nasceu como um projeto pessoal, limitado a um tipo específico de computador. Trinta e cinco anos depois, tornou-se a base de servidores, smartphones, supercomputadores, roteadores, automóveis, televisores e infraestruturas de nuvem espalhadas pelo mundo.

Tux tornou-se o mascote do Linux em 1996, quando o kernel já começava a ultrapassar os limites dos computadores pessoais.

Antes do Linux: Unix, GNU e Minix

Para compreender o nascimento do Linux, é necessário voltar aos sistemas Unix, desenvolvidos a partir do final da década de 1960 nos laboratórios Bell. O Unix ajudou a consolidar conceitos que ainda fazem parte dos sistemas operacionais modernos: processos, permissões, arquivos organizados em uma árvore de diretórios, pequenos programas combináveis e uma divisão clara entre o kernel e as ferramentas executadas pelo usuário.

Durante muito tempo, porém, as diferentes versões do Unix estiveram ligadas a universidades ou empresas e eram distribuídas sob licenças restritivas.

Em 1983, Richard Stallman iniciou o Projeto GNU, cujo objetivo era desenvolver um sistema operacional compatível com Unix que pudesse ser usado, estudado, modificado e redistribuído livremente. Diversos componentes fundamentais foram produzidos: compiladores, bibliotecas, interpretadores de comandos, depuradores e utilitários.

Faltava uma peça particularmente complexa: um kernel funcional e suficientemente maduro.

Outro sistema importante para essa história foi o Minix, criado pelo professor Andrew Tanenbaum para fins educacionais. O código do Minix podia ser estudado por alunos interessados em sistemas operacionais, embora sua licença inicial não oferecesse a mesma liberdade que mais tarde seria associada ao Linux.

Foi nesse ambiente que um estudante finlandês chamado Linus Benedict Torvalds começou a trabalhar em seu próprio kernel.

O computador que deu origem ao Linux

No começo de 1991, Linus Torvalds estudava ciência da computação na Universidade de Helsinque. Ele havia comprado um computador equipado com um processador Intel 80386, uma arquitetura que oferecia recursos avançados para a época, como modo protegido, paginação e mecanismos de gerenciamento de memória.

O interesse inicial de Torvalds não era criar uma plataforma mundial nem competir com empresas de software. Ele queria compreender melhor o funcionamento do processador e aproveitar seu novo computador.

Os primeiros experimentos foram relacionados à troca de tarefas e ao acesso ao terminal. Pouco a pouco, o programa cresceu. Linus implementou gerenciamento de memória, processos, acesso a dispositivos e um sistema de arquivos. O que havia começado como um emulador de terminal aproximava-se de um pequeno kernel semelhante ao Unix.

Em julho de 1991, Torvalds já procurava informações sobre as regras POSIX, o conjunto de padrões destinado a manter compatibilidade entre sistemas Unix. Em 25 de agosto daquele ano, publicou uma mensagem no grupo comp.os.minix informando que estava desenvolvendo um sistema operacional livre para computadores 386 e 486.

Na mensagem, apresentou o projeto como um hobby e avisou que ele não seria grande ou profissional como o GNU. A frase tornou-se curiosa porque descrevia justamente o oposto do que aconteceria nas décadas seguintes. As mensagens originais e os comentários de Linus sobre esse período foram preservados em um arquivo histórico sobre o nascimento do Linux.

Linux 0.01: pequeno, limitado e surpreendentemente avançado

A versão 0.01 foi disponibilizada em setembro de 1991. Seu pacote compactado ocupava aproximadamente 71 KB — um tamanho minúsculo quando comparado aos milhões de arquivos e dezenas de milhões de linhas do kernel atual.

O sistema tinha limitações consideráveis:

• Funcionava apenas em computadores compatíveis com o Intel 386.
• Dependia do Minix para ser compilado e instalado.
• Tinha suporte restrito a discos rígidos, teclado, tela e portas seriais.
• O teclado finlandês estava incorporado ao código.
• Não possuía comandos completos para montar e desmontar sistemas de arquivos.
• Não era um sistema adequado para ambientes de produção.
• Exigia conhecimentos técnicos até mesmo para iniciar.

As notas oficiais do Linux 0.01 deixam claro que aquele software era experimental. Também revelam decisões técnicas relevantes. O kernel utilizava recursos específicos do 386, possuía paginação, segmentação, cópia sob escrita e um sistema de arquivos com capacidade para atender várias tarefas.

A abordagem escolhida era a de um kernel monolítico. Isso significa que componentes como gerenciamento de memória, sistema de arquivos, escalonamento e drivers executavam no espaço privilegiado do kernel.

“Monolítico” não significa necessariamente que o código seja desorganizado ou impossível de ampliar. O Linux evoluiu para uma arquitetura monolítica modular: diversos componentes podem ser separados em módulos e carregados somente quando necessários.

De Freax para Linux

Torvalds teria considerado chamar seu projeto de Freax, uma combinação de “free”, “freak” e a letra X, tradicionalmente associada aos sistemas Unix.

Ari Lemmke, administrador do servidor FTP usado para distribuir os primeiros arquivos, não gostou do nome. Ao criar o diretório público, escolheu “Linux”, combinando Linus e Unix.

O nome permaneceu.

Essa pequena decisão também mostra como o Linux começou a crescer por meio da colaboração. Linus escreveu a base inicial, mas desenvolvedores de diferentes países passaram a testar, corrigir e ampliar o sistema. O correio eletrônico, os grupos de discussão e os servidores FTP funcionaram como a infraestrutura de uma comunidade internacional muito antes da popularização das plataformas modernas de hospedagem de código.

A licença que permitiu o crescimento do projeto

A versão 0.01 não utilizava a licença GNU GPL. Linus havia escrito uma licença própria que permitia a redistribuição do código, mas proibia cobrar pelo software.

Essa restrição apresentava um problema: software livre não significa necessariamente software gratuito. A liberdade de estudar, modificar e redistribuir pode coexistir com a cobrança por cópias, serviços, suporte, integração e manutenção.

Em 1992, o Linux passou a ser distribuído sob a GNU General Public License. A adoção da GPL foi decisiva porque permitiu que pessoas e empresas utilizassem e comercializassem o sistema, desde que respeitassem as obrigações da licença ao distribuir versões modificadas.

O kernel permanece licenciado sob a GPL versão 2. Componentes individuais podem utilizar licenças compatíveis, mas o kernel como conjunto continua sob a GPL-2.0.

Essa escolha jurídica ajudou a criar um espaço incomum: empresas concorrentes poderiam investir em uma infraestrutura comum sem que uma delas tivesse o direito de fechar unilateralmente o código principal.

A discussão entre Linus Torvalds e Andrew Tanenbaum

Uma das primeiras controvérsias do Linux ocorreu em 1992. Andrew Tanenbaum, criador do Minix, criticou publicamente a arquitetura monolítica escolhida por Torvalds.

Tanenbaum defendia os microkernels, nos quais apenas mecanismos essenciais permanecem no núcleo privilegiado. Serviços como drivers e sistemas de arquivos podem ser executados como processos separados. Em teoria, essa divisão melhora o isolamento e reduz os danos provocados por falhas em componentes individuais.

Linus argumentava que sua arquitetura era mais prática e apresentava melhor desempenho no hardware disponível. A discussão também envolveu portabilidade, projeto de sistemas operacionais e a dependência inicial do Linux em relação ao processador 386.

O debate costuma ser recontado como uma disputa simples na qual um lado estava certo e o outro errado. A realidade é mais interessante. Microkernels continuam sendo usados em sistemas nos quais isolamento, verificabilidade e segurança funcional são prioridades. O Linux, por sua vez, demonstrou que um kernel monolítico modular poderia crescer, receber milhares de drivers e funcionar em muitas arquiteturas.

O próprio Linux mudou bastante. Ele deixou de ser rigidamente dependente do 386, ganhou módulos carregáveis, abstrações de hardware, isolamento de processos, namespaces, mecanismos de segurança e suporte a arquiteturas muito diferentes.

Linux 1.0: o projeto experimental torna-se utilizável

O Linux 1.0 foi lançado em 13 de março de 1994. A chegada à versão 1.0 comunicava que o kernel havia atingido um nível razoável de estabilidade e poderia ser usado fora do grupo restrito de pessoas que acompanhavam as versões experimentais.

Entre os recursos desenvolvidos ou amadurecidos durante esse período estavam:

• Redes TCP/IP.
• Maior quantidade de drivers.
• Suporte a SCSI.
• Integração de recursos de áudio.
• Melhorias no gerenciamento de memória.
• Suporte inicial ao formato de executáveis ELF.
• Sistemas de arquivos mais funcionais.
• Aprimoramentos no NFS.
• Suporte a CD-ROM e unidades de fita.
• Melhorias no escalonador e na criação de processos.

O arquivo oficial de mudanças do Linux 1.0 começa com uma brincadeira sobre a remoção de todos os bugs. O humor já fazia parte da comunicação do projeto, embora a estabilidade de um kernel jamais signifique ausência completa de defeitos.

O Ext2, desenvolvido principalmente por Rémy Card, Theodore Ts’o e Stephen Tweedie, tornou-se uma peça importante dos primeiros sistemas Linux. Ele substituiu sistemas de arquivos mais limitados e permaneceu durante anos como uma escolha comum. Sua estrutura está documentada na documentação oficial do kernel.

Distribuições como Slackware e Debian começaram a transformar o kernel, as ferramentas GNU e outros programas em sistemas instaláveis. Esse ponto é importante: Linux, em sentido técnico, é o kernel. Uma distribuição reúne o kernel, bibliotecas, comandos, instalador, gerenciador de pacotes, ambiente gráfico e aplicações.

Das versões 1.x ao Linux 2.0

O Linux 1.2, lançado em 1995, ampliou o suporte a hardware, redes e sistemas de arquivos. O desenvolvimento também começou a ultrapassar a arquitetura x86, afastando-se da antiga ideia de que o kernel seria inseparável do Intel 386.

Em 1996 chegou o Linux 2.0, um marco para a utilização profissional do sistema. Uma de suas características mais importantes foi o suporte a multiprocessamento simétrico, conhecido como SMP. O kernel passava a trabalhar com máquinas dotadas de mais de um processador.

O suporte a novas arquiteturas também ganhou importância. O Linux começou a aparecer em servidores, estações de trabalho e dispositivos que não se pareciam com o computador pessoal usado por Torvalds em 1991.

Foi durante a era do Linux 2.0 que o pinguim Tux se tornou o mascote do projeto. O desenho original foi criado por Larry Ewing em 1996, usando o programa GIMP. O nome costuma ser interpretado como uma referência a “Torvalds Unix”, embora também lembre a palavra inglesa “tuxedo”, relacionada à aparência de um pinguim.

Linux 2.2: redes, servidores e mais processadores

Lançado em 1999, o Linux 2.2 trouxe avanços no suporte a multiprocessamento, redes, arquiteturas e dispositivos. O kernel tornava-se cada vez mais atraente para servidores de internet e empresas que procuravam uma alternativa aos sistemas Unix comerciais.

A expansão da internet favoreceu o Linux. Servidores web, DNS, correio eletrônico, bancos de dados e compartilhamento de arquivos eram aplicações nas quais estabilidade, automação e acesso ao código tinham grande valor.

O modelo de desenvolvimento também amadurecia. Linus não analisava sozinho cada linha enviada. Mantenedores passaram a cuidar de subsistemas, como redes, armazenamento, arquiteturas, sistemas de arquivos e drivers. Essa estrutura hierárquica permanece fundamental.

Uma alteração normalmente é discutida, revisada e testada dentro de um subsistema. O mantenedor reúne as mudanças consideradas adequadas e as encaminha para os níveis seguintes. A própria documentação sobre envio de patches explica que poucas contribuições são encaminhadas diretamente a Linus Torvalds.

Linux 2.4: USB, desktops, servidores e a participação brasileira

O Linux 2.4 foi lançado em janeiro de 2001. Essa série ampliou o suporte a USB, redes, armazenamento, memória de grande capacidade, multiprocessamento e arquiteturas diferentes. O kernel passou a atender melhor tanto computadores pessoais quanto servidores mais poderosos.

Recursos como Netfilter e iptables fortaleceram sua utilização em roteadores e firewalls. O suporte a dispositivos USB ajudou a aproximar o Linux dos computadores domésticos. Durante a série 2.4, o Ext3 introduziu journaling sobre a base do Ext2, reduzindo o tempo e os riscos da recuperação após desligamentos inesperados.

A história dessa versão possui uma participação brasileira muito importante.

Marcelo Tosatti, o brasileiro responsável pela série estável 2.4

Em novembro de 2001, o gaúcho Marcelo Tosatti tornou-se mantenedor da árvore estável do Linux 2.4. Ele tinha apenas 18 anos.

Tosatti já trabalhava com o kernel na Conectiva, empresa brasileira responsável por uma das primeiras distribuições Linux da América Latina. Alan Cox sugeriu seu nome, e a escolha foi apoiada por Linus Torvalds.

Dizer que Marcelo “desenvolveu o Linux 2.4” seria incorreto. A série já existia e era resultado do trabalho de muitos desenvolvedores. Sua responsabilidade era manter a versão estável: avaliar correções, integrar mudanças seguras, tratar regressões e impedir que novidades arriscadas comprometessem máquinas em produção.

Seu primeiro lançamento como mantenedor foi o Linux 2.4.16, publicado em 26 de novembro de 2001. Uma entrevista com Marcelo Tosatti registra sua escolha e as responsabilidades assumidas.

Esse trabalho tinha um peso enorme. A série 2.4 era usada em servidores, provedores de acesso, equipamentos de rede e sistemas corporativos. Uma correção inadequada poderia afetar milhares de instalações.

A participação de Tosatti também é um capítulo relevante da tecnologia brasileira. A Conectiva não se limitava a traduzir programas. Seus profissionais contribuíam com componentes de baixo nível, empacotamento, internacionalização e desenvolvimento do próprio kernel.

Linux 2.6: a série que pareceu não terminar

O Linux 2.6 foi lançado em dezembro de 2003. Ele representou uma grande modernização na capacidade de escalar, responder rapidamente e atender diferentes categorias de dispositivo.

Entre os destaques da geração 2.6 estavam:

• Kernel preemptivo, importante para melhorar a resposta do sistema.
• Novo modelo de dispositivos.
• Evolução do gerenciamento de energia.
• Melhor suporte a NUMA e grandes máquinas multiprocessadas.
• Sysfs e integração com ferramentas como o udev.
• Novos escalonadores de processos.
• Expansão do suporte a dispositivos embarcados.
• Aprimoramentos em segurança, redes e sistemas de arquivos.
• Virtualização com tecnologias como KVM.
• Control groups, ou cgroups, essenciais para limitar e organizar recursos.
• Namespaces, que ajudaram a formar a base dos contêineres modernos.
• FUSE, permitindo sistemas de arquivos implementados no espaço do usuário.
• Inotify, usado para monitorar alterações em arquivos e diretórios.

O Linux 2.6 permaneceu como numeração principal durante quase oito anos. Nesse intervalo, o projeto adotou um ciclo mais previsível de desenvolvimento. Em vez de guardar grandes transformações para uma futura versão 2.7, novos recursos passaram a entrar gradualmente em lançamentos regulares.

O escalonador também mudou durante essa longa fase. O Completely Fair Scheduler, ou CFS, entrou no Linux 2.6.23 e substituiu o mecanismo anterior para tarefas comuns. Seu objetivo era aproximar o uso real do processador de uma divisão ideal e justa entre processos. A documentação do CFS descreve esse princípio usando o conceito de tempo de execução virtual.

A controvérsia do BitKeeper e o nascimento do Git

O crescimento do kernel criou um problema de engenharia: como administrar mudanças produzidas por milhares de desenvolvedores?

Em 2002, o projeto começou a usar o BitKeeper, um sistema de controle de versões distribuído, porém proprietário. A escolha gerou críticas dentro da comunidade de software livre. Alguns desenvolvedores consideravam contraditório usar uma ferramenta fechada para construir um dos maiores projetos livres do mundo.

O acesso gratuito oferecido aos desenvolvedores do kernel terminou em 2005, após conflitos envolvendo a engenharia reversa do protocolo do BitKeeper.

Linus Torvalds decidiu criar uma ferramenta própria. Ela deveria ser distribuída, rápida, confiável e capaz de trabalhar com a escala incomum do kernel. O resultado foi o Git.

O Git não nasceu como uma plataforma social ou um serviço de hospedagem. Era um mecanismo para gerenciar objetos, históricos e conjuntos de mudanças de maneira distribuída. Sua criação está diretamente ligada à crise do BitKeeper, conforme relata a história oficial apresentada pelo projeto Git.

A controvérsia terminou produzindo uma das ferramentas mais importantes do desenvolvimento de software moderno.

Linux 3.0: uma mudança de número, não uma reconstrução

O Linux 3.0 foi lançado em julho de 2011, quando o projeto completava vinte anos. A mudança de 2.6.39 para 3.0 não indicava uma ruptura arquitetônica.

Linus considerava a numeração 2.6 longa e pouco prática. O novo número simplificava a identificação das versões e marcava simbolicamente o aniversário do projeto.

Durante a família 3.x, o Linux se fortaleceu em áreas que mudariam a indústria:

• Android e dispositivos móveis.
• Computação em nuvem.
• Virtualização.
• Contêineres.
• Arquiteturas ARM.
• Novos sistemas de arquivos, como Btrfs.
• Aprimoramentos em cgroups e namespaces.
• Melhor suporte a gráficos, energia e dispositivos móveis.

O domínio do Linux deixou de estar concentrado em servidores tradicionais. Bilhões de smartphones passaram a executar o kernel por meio do Android, mesmo que muitos usuários não associassem seus aparelhos ao Linux.

Linux 4.0: atualização do kernel em sistemas críticos

O Linux 4.0 chegou em abril de 2015. Assim como a versão 3.0, a troca de numeração não significou que o kernel tivesse sido reescrito.

Um recurso simbólico dessa fase foi a infraestrutura para aplicar determinadas correções ao kernel em execução, base de soluções de live patching. Em ambientes críticos, reiniciar um servidor para cada correção pode ser caro ou operacionalmente difícil. O live patching permite corrigir classes específicas de problemas sem uma reinicialização imediata.

A série 4.x também acompanhou o crescimento de contêineres, plataformas de nuvem, armazenamento flash, redes de alta velocidade, dispositivos ARM e sistemas embarcados.

Tecnologias como eBPF começaram a ultrapassar seu uso original relacionado à filtragem de pacotes. O eBPF evoluiu para uma plataforma capaz de executar programas verificados dentro do kernel, sendo usado em observabilidade, redes, segurança e análise de desempenho.

Linux 5.0: infraestrutura para nuvem, dispositivos e desempenho

Lançado em março de 2019, o Linux 5.0 foi outra alteração numérica motivada principalmente pela conveniência. O kernel continuou seguindo o ciclo regular de integração e estabilização.

Durante a família 5.x, ganharam destaque:

• io_uring para operações de entrada e saída assíncronas.
• Expansão do eBPF.
• WireGuard integrado ao kernel.
• Melhorias contínuas em AMD, Intel, ARM e RISC-V.
• Novos drivers para GPUs e aceleradores.
• Evolução de Ext4, XFS e Btrfs.
• Aprimoramentos no gerenciamento de energia.
• Suporte crescente a notebooks, servidores e dispositivos embarcados.
• Mecanismos usados por plataformas de contêineres e orquestração.

O kernel já não podia ser avaliado apenas pelo desempenho de um computador isolado. Uma alteração aparentemente pequena poderia afetar data centers, redes móveis, clusters de supercomputação, televisores e sistemas industriais.

Linux 6.0: Rust, novas arquiteturas e segurança de memória

O Linux 6.0 foi lançado em outubro de 2022. A mudança de número não representou uma nova arquitetura, mas abriu uma série marcada pela discussão sobre segurança de memória e pela adoção inicial da linguagem Rust.

O suporte inicial à infraestrutura de Rust entrou no Linux 6.1. Isso não significou reescrever o kernel ou abandonar a linguagem C. A intenção era permitir que determinados componentes, sobretudo novos drivers, pudessem aproveitar garantias de segurança oferecidas pela linguagem.

A adoção provocou debates técnicos e culturais. O código em C possui décadas de ferramentas, experiência e convenções. Rust traz um modelo de memória diferente, exige novas abstrações e demanda conhecimento de outra linguagem. Seus defensores apontam a possibilidade de reduzir erros como uso de memória após liberação, acessos inválidos e certas condições de concorrência.

A série 6.x também desenvolveu o sched_ext, uma estrutura que permite implementar políticas de escalonamento extensíveis com auxílio do eBPF. Outras áreas em evolução incluíram io_uring, folios de memória, redes, virtualização confidencial, RISC-V e suporte ao hardware mais recente.

Linux 7.0, 7.1 e 7.2

O Linux 7.0 foi lançado em 12 de abril de 2026. Mais uma vez, não se tratava de uma reconstrução completa. A troca de 6.x para 7.x evitou que a numeração secundária continuasse crescendo indefinidamente.

Segundo o histórico do projeto, os lançamentos 7.0, 7.1 e 7.2 ocorreram com exatamente 63 dias de intervalo: 7.0 em 12 de abril, 7.1 em 14 de junho e 7.2 em 16 de agosto de 2026. A linha do tempo pode ser consultada no Linux Kernel Newbies.

Linux 7.0

Entre as mudanças destacadas no Linux 7.0 estavam:

• Uma API genérica para informar erros de entrada e saída em arquivos.
• Monitoramento de integridade para XFS.
• Melhorias nos filtros do io_uring.
• Opções voltadas à criação de contêineres com open_tree.
• Aprimoramentos no mecanismo de swap.
• Uso padrão de Accurate ECN em redes compatíveis.
• Trabalho experimental relacionado à árvore de remapeamento do Btrfs.
• Mecanismos mais seguros para lidar com objetos alocados no kernel.

Esses recursos mostram uma característica do Linux moderno: os avanços raramente cabem em uma única categoria. Um lançamento reúne mudanças em armazenamento, redes, segurança, processadores, drivers, sistemas de arquivos e ferramentas de desenvolvimento.

Linux 7.1

O Linux 7.1 continuou esse processo. Entre seus destaques estavam:

• Um novo driver para o sistema de arquivos NTFS.
• Melhorias no swap.
• Ativação do mecanismo Intel FRED em hardware compatível.
• Integração entre eBPF e io_uring.
• Preparação para subescalonadores no sched_ext.
• Novas opções da chamada clone3.
• Aprimoramentos para namespaces e criação de contêineres.

A evolução de clone3, namespaces e escalonadores extensíveis é especialmente relevante para data centers. Muitas cargas de trabalho modernas são executadas em contêineres e precisam dividir processadores, memória e dispositivos entre aplicações com perfis muito diferentes.

Linux 7.2

O Linux 7.2 foi lançado em 16 de agosto de 2026 e era a versão principal mais recente na data de elaboração deste artigo. O lançamento pode ser confirmado no arquivo oficial do kernel.

Um de seus destaques é o escalonamento mais consciente da organização dos caches. O kernel pode aproximar tarefas que compartilham dados dentro do mesmo domínio de cache de último nível, reduzindo movimentações desnecessárias e melhorando o aproveitamento do processador em algumas cargas.

O Linux 7.2 também trouxe:

• Melhorias na recuperação de memória.
• Uma implementação de swap mais enxuta e eficiente.
• Suporte a USB4STREAM para transportar fluxos de dados por conexões USB4.
• Otimizações de desempenho no Btrfs.
• O novo alvo dm-inlinecrypt para criptografia integrada de dispositivos de bloco.
• Novas opções relacionadas à família de chamadas openat.
• Leitura mais rápida de informações em /proc/filesystems e /proc/interrupts.
• Preparações adicionais para subescalonadores no sched_ext.
• Atualizações de drivers e suporte a novas gerações de hardware.

A relação detalhada pode ser consultada no resumo técnico do Linux 7.2.

Como um novo kernel é desenvolvido

O kernel atual utiliza um modelo de desenvolvimento contínuo. A versão principal costuma ser lançada a cada nove ou dez semanas.

Após um lançamento, abre-se uma janela de integração de aproximadamente duas semanas. Nesse período, Linus recebe conjuntos de mudanças preparados pelos mantenedores. Encerrada a janela, surgem as versões candidatas, identificadas por -rc1, -rc2 e assim sucessivamente.

As semanas seguintes são voltadas a testes, correções e regressões. Quando a versão é considerada suficientemente estável, ocorre o lançamento oficial. A documentação de versões do kernel explica a divisão entre mainline, stable e longterm.

Isso não significa que todos os usuários devam instalar imediatamente a versão mais recente. Distribuições e empresas costumam manter kernels estáveis ou de longo prazo, aplicando correções de segurança sem incorporar toda novidade disponível na árvore principal.

Quem paga pelo desenvolvimento do Linux?

A imagem romântica de programadores trabalhando apenas nas horas vagas representa parte da origem do Linux, mas não descreve sua realidade industrial.

Muitos desenvolvedores continuam contribuindo de forma independente. Uma parcela significativa das mudanças, porém, é produzida por profissionais pagos por empresas.

Relatórios históricos da Linux Foundation ajudam a dimensionar essa transformação. Em 2011, a fundação estimou que cerca de 75% do desenvolvimento analisado havia sido realizado por profissionais remunerados. Empresas como Red Hat, Intel, IBM, Texas Instruments, Broadcom, Samsung, Oracle e Google apareciam entre as organizações envolvidas. Os números pertencem àquele período e não devem ser apresentados como uma fotografia exata do desenvolvimento atual, mas mostram que a participação empresarial não é recente. Relatório da Linux Foundation de 2011.

Em 2017, outro levantamento contabilizou aproximadamente 15.600 desenvolvedores e mais de 1.400 empresas desde o início do acompanhamento por Git. Intel, Red Hat, Linaro, IBM, Samsung, SUSE, Google, AMD, Renesas e Mellanox estavam entre as principais organizações patrocinadoras de contribuições naquele relatório. Relatório da Linux Foundation de 2017.

O investimento empresarial acontece de várias formas:

• Salários de engenheiros que trabalham no kernel.
• Laboratórios de teste e integração contínua.
• Desenvolvimento de drivers.
• Correções de segurança.
• Manutenção de versões de longo prazo.
• Documentação e revisão de código.
• Disponibilização antecipada de hardware.
• Patrocínio de conferências e infraestrutura.
• Trabalho em compiladores e ferramentas de diagnóstico.

Essas empresas não investem apenas por simpatia ao software livre. Fabricantes precisam que seus processadores, GPUs, controladores e dispositivos funcionem bem. Provedores de nuvem querem melhor desempenho por servidor. Empresas de telecomunicações dependem de redes rápidas e previsíveis. Fabricantes de automóveis e eletrônicos precisam de um kernel adaptável e mantido por muitos anos.

A participação empresarial cria tensões. Cada organização possui interesses próprios, e determinadas mudanças podem favorecer um fabricante ou uma categoria de produto. O processo de revisão pública, a autoridade dos mantenedores e a licença GPL ajudam a impedir que uma única companhia transforme a árvore principal em produto exclusivo.

Linus Torvalds, poder técnico e comportamento controverso

Linus Torvalds é reconhecido por sua competência técnica e por sua capacidade de coordenar um projeto gigantesco. Sua forma de comunicação, porém, tornou-se uma das maiores controvérsias da história do kernel.

Durante anos, Linus publicou respostas agressivas, insultos e críticas pessoais em listas de discussão. Seus defensores argumentavam que o kernel exige padrões elevados e que críticas diretas evitam a integração de código ruim. O problema é que rigor técnico e humilhação pessoal não são a mesma coisa.

Em setembro de 2018, Torvalds reconheceu que seu comportamento havia prejudicado pessoas e anunciou uma pausa para buscar ajuda. O episódio acompanhou a adoção de um Código de Conduta mais explícito.

O Código de Conduta do kernel Linux passou a estabelecer regras contra insultos, ataques pessoais, assédio e outras formas de comportamento inadequado.

A mudança gerou resistência em parte da comunidade. Alguns temiam que as novas normas fossem usadas para controlar discussões técnicas. Outros afirmavam que um ambiente incapaz de distinguir análise de código e agressão pessoal afastava desenvolvedores qualificados.

A pausa de Linus não apagou os episódios anteriores, mas marcou uma mudança importante: o próprio criador do projeto admitiu que a autoridade técnica não justifica qualquer forma de tratamento.

GPLv2, GPLv3 e os limites da abertura

Outra disputa importante envolve a licença do kernel. Quando a GPLv3 foi publicada, surgiram discussões sobre uma possível migração.

Linus Torvalds se opôs à mudança. Uma das divergências estava relacionada às cláusulas da GPLv3 contra a chamada “tivoização”, situação em que um fabricante distribui software livre em um dispositivo, mas utiliza mecanismos técnicos para impedir a execução de versões modificadas pelo usuário.

O kernel continua sob GPLv2. Uma mudança completa também seria juridicamente muito difícil, porque o código possui contribuições protegidas por direitos autorais de milhares de pessoas e organizações.

A discussão revelou uma diferença filosófica. Para alguns integrantes do movimento de software livre, a liberdade do usuário inclui a possibilidade prática de executar uma versão modificada. Para Torvalds, a GPLv2 oferecia um equilíbrio mais adequado entre colaboração, disponibilidade do código e liberdade dos fabricantes para construir produtos.

Drivers proprietários e a relação difícil com fabricantes

O suporte a hardware também produziu conflitos. Durante muitos anos, empresas divulgaram poucos detalhes sobre seus dispositivos ou ofereceram apenas drivers proprietários.

Essa situação cria problemas para o kernel. Um módulo fechado pode deixar de funcionar após mudanças internas, impedir auditoria, dificultar correções de segurança e tornar a investigação de falhas mais complexa.

Linus protagonizou declarações bastante agressivas contra fabricantes que dificultavam o suporte ao Linux. O episódio mais famoso envolveu a NVIDIA em 2012. Embora tenha chamado atenção para um problema real de cooperação técnica, a forma usada por Torvalds também reforçou sua reputação de comunicação hostil.

A relação com fabricantes de hardware melhorou em muitas áreas. Existem drivers abertos para diferentes GPUs, processadores e aceleradores, mas a tensão entre código proprietário, firmware fechado, documentação restrita e desenvolvimento comunitário ainda não desapareceu.

O kernel que quase ninguém vê, mas quase todos utilizam

Um usuário pode passar anos usando Linux sem instalar uma distribuição em seu computador pessoal.

O kernel está presente no Android, em servidores web, roteadores domésticos, televisores, equipamentos industriais, sistemas de entretenimento automotivo, plataformas de nuvem e supercomputadores. Ele aparece em placas minúsculas e em máquinas com milhares de processadores.

Sua força não está apenas no fato de ser gratuito. O Linux reúne quatro características difíceis de combinar:

• Código-fonte disponível.
• Grande diversidade de arquiteturas e dispositivos.
• Processo contínuo de revisão.
• Investimento de empresas que competem entre si.

Também existem fragilidades. O código acumulado durante décadas é complexo. Mantenedores experientes podem ficar sobrecarregados. Novos desenvolvedores precisam compreender regras técnicas e sociais pouco óbvias. Empresas nem sempre mantêm por tempo suficiente os componentes que introduzem. A pressão por suporte rápido ao novo hardware pode entrar em conflito com estabilidade e qualidade.

O significado do Linux 7.2

Chegar ao Linux 7.2 não significa que o projeto esteja pronto ou próximo de uma forma definitiva. Um kernel nunca fica completo porque o hardware, as ameaças de segurança e as aplicações continuam mudando.

A versão 0.01 precisava do Minix para ser instalada, reconhecia poucos dispositivos e trazia um teclado finlandês incorporado ao código. A versão 7.2 precisa coordenar processadores com arquiteturas híbridas, caches complexos, aceleradores, máquinas virtuais, contêineres, armazenamento criptografado, redes de alta velocidade e cargas de inteligência artificial.

Existe uma continuidade entre esses dois extremos. O projeto ainda é desenvolvido por meio de código compartilhado, revisão técnica e discussões públicas. Linus Torvalds continua ocupando uma posição central, mas o Linux já não pode ser compreendido como a obra de uma única pessoa.

Sua história é a história de uma comunidade que aprendeu a lidar com crescimento, empresas, conflitos, licenças, egos, segurança e mudanças constantes de hardware. É justamente essa combinação imperfeita que transformou o antigo hobby de um estudante em uma das infraestruturas mais importantes da computação moderna.