História das distribuições Linux: de onde elas vieram

O que uma distribuição Linux realmente é

A história das distribuições Linux começa com uma lacuna: o kernel Linux, por si só, não faz nada que uma pessoa possa utilizar. Arranca e deteta o hardware. Depois para. Alguém tem de adicionar um userland, decidir como o software é instalado e atualizado e garantir que continuará a corrigi-lo durante anos. Uma distribuição é esse conjunto de decisões, mais o grupo de pessoas que continua a mantê-la.

Tem cinco partes. Altere qualquer uma delas e terá uma distribuição diferente, mesmo quando a maioria dos binários é igual:

• Um kernel, numa versão escolhida pelo projeto, com os patches e drivers adicionados.
• Um userland: a biblioteca C, a shell, o sistema init e os comandos padrão.
• Um formato de pacotes e a ferramenta que o instala.
• Uma política de releases: o que pode mudar, com que frequência e durante quanto tempo cada release recebe correções.
• Pessoas: responsáveis pela manutenção dos pacotes, uma equipa de segurança e alguém que responda quando um pacote deixa de funcionar.

O kernel é a parte partilhada, por isso duas distribuições Linux estão muito mais próximas entre si do que qualquer uma delas está de outro Unix. Vale a pena ter isto presente ao comparar Linux e FreeBSD como plataformas de servidor, em que o kernel e o userland base são desenvolvidos por um único projeto e lançados em conjunto. No Linux, essas peças vêm de upstreams separados, e a distribuição é o elemento que as faz funcionar em conjunto.

Histórico das distribuições Linux em três famílias

Três projetos iniciados em 1993 e 1994 deram origem a famílias: Slackware, Debian e Red Hat. Atualmente, quase todas as imagens disponíveis num painel de controlo de VPS pertencem a uma dessas famílias ou são derivadas de uma delas. Uma distribuição derivada herda o formato dos pacotes, a organização do sistema de ficheiros e, normalmente, as práticas de lançamento. Por isso, uma derivada de Debian continua a comportar-se como Debian mesmo depois de a marca desaparecer.

As distribuições independentes merecem uma linha própria, porque não derivaram de nenhum outro projeto. Arch, Gentoo, Alpine, NixOS e Void criaram o seu próprio gestor de pacotes e as suas próprias regras. Duas delas, Arch e Alpine, acabaram por aparecer na lista de imagens do seu fornecedor, por motivos que nada tinham que ver com o ambiente de trabalho.

1992: as distribuições antes das famílias

O MCC Interim Linux surgiu em fevereiro de 1992, compilado por Owen Le Blanc no Manchester Computing Centre. Reunia o kernel e as ferramentas GNU (GNU's not Unix) em duas imagens de disquete, com um instalador orientado por menus. Existia porque fazer isso manualmente consumia um dia de trabalho.

O SLS (Softlanding Linux System), lançado por Peter MacDonald em 1992, foi mais longe e acrescentou o X (the X Window System) e a rede TCP/IP. O SLS é a razão pela qual a palavra distribuição tem o significado atual. Também tinha muitos bugs e recebia pouca manutenção. Em 1993, duas pessoas decidiram corrigir esses problemas separadamente. Uma reconstruiu a distribuição. A outra começou de novo, seguindo regras escritas.

Slackware, 1993: a família mais antiga ainda mantida

Patrick Volkerding lançou o Slackware 1.00 em 16 de julho de 1993, criado a partir do SLS com os bugs corrigidos. O projeto continua a ser mantido, o que faz dele a distribuição Linux sobrevivente mais antiga.

Um pacote Slackware é um arquivo tar comprimido que contém um script de instalação. Não existe resolução de dependências: nada verifica se a biblioteca necessária para o novo pacote já está instalada no disco. Essa decisão única definiu todo o resto. Se a ferramenta não resolver dependências, o conjunto distribuído tem de ser coerente por construção. Por isso, os lançamentos são pouco frequentes e conservadores. O Slackware 15.0 chegou em fevereiro de 2022, seis anos depois do 14.2.

A família é pequena. Os primeiros lançamentos do SUSE, em meados dos anos 1990, foram baseados no Slackware, antes de o projeto seguir o seu próprio caminho com o YaST e, mais tarde, com o formato de pacotes RPM. Esta última parte confunde algumas pessoas. O SUSE e o openSUSE usam pacotes RPM, mas não são derivados do Red Hat. O formato foi reutilizado. A linhagem não.

Debian, 1993: um contrato social e um fluxo de três suites

Ian Murdock anunciou o Debian em 16 de agosto de 1993, três semanas depois do Slackware e pelo mesmo motivo. O nome combina o nome da sua companheira, Debra, com o seu próprio. O Debian Manifesto surgiu em janeiro de 1994 e estabeleceu os termos: esta distribuição seria mantida de forma aberta por voluntários, não por uma empresa.

O Debian formalizou depois esses termos. O Debian Social Contract e as DFSG (Debian free software guidelines) foram adotados em julho de 1997, e as DFSG tornaram-se a base da Open Source Definition em 1998. Um documento escrito para definir o que pertence a uma distribuição acabou por estabelecer uma categoria de licenças para todo o setor. É também por isso que o seu sources.list tem componentes: main contém software que cumpre as guidelines, contrib e non-free contêm o que não cumpre, e o Debian 12 adicionou non-free-firmware para que um laptop com uma placa wireless pudesse instalar o sistema sem procurar manualmente todos os pacotes necessários.

As ferramentas são a outra herança. dpkg instala um pacote e recusa-se a continuar quando falta alguma dependência, apresentando dpkg: dependency problems prevent configuration of. O APT (advanced package tool), que se tornou a ferramenta predefinida com o Debian 2.1 em 1999, é a camada que determina o que mais deve ser obtido e em que ordem. Cada comando apt em cada derivada do Debian descende desse trabalho.

O processo de lançamento tem três suites e uma regra. Um maintainer envia um pacote para unstable, com o codename permanente sid. Um script migra o pacote para testing após aproximadamente 5 a 10 dias, se este tiver sido compilado nas arquiteturas da versão e não tiver adquirido nenhum novo bug crítico para o lançamento. Depois, testing entra em freeze, a equipa de release resolve o que falta e stable é lançada quando a lista de bugs fica suficientemente curta. Não existe uma data fixa. É por isso que Debian stable parece antigo e funciona bem: os números das versões ficam parados no freeze, enquanto as correções de segurança continuam a ser integradas nessas versões.

A governação também está formalizada, com um líder de projeto eleito e resoluções gerais vinculativas. Em 2014, esse mecanismo escolheu o systemd como sistema init predefinido, e as pessoas que discordaram criaram o fork Devuan, que fez o seu primeiro lançamento em 2017. As derivadas de maior dimensão são Ubuntu, Raspberry Pi OS, Proxmox VE, Kali e Linux Mint.

Red Hat, 1994: RPM e a divisão entre Fedora e RHEL

Marc Ewing lançou o primeiro Red Hat Linux por volta do Halloween de 1994. A empresa de Bob Young comprou-o em 1995, e os dois criaram o primeiro negócio de Linux que vendia suporte em vez de software. A Red Hat entrou na bolsa em 11 August 1999. A IBM concluiu a aquisição da empresa em July 2019 por cerca de 34 mil milhões de dólares. Desde então, a distribuição contra a qual a maioria dos softwares empresariais é certificada pertence à IBM.

A contribuição técnica duradoura é o RPM (Red Hat package manager), escrito por Erik Troan e Marc Ewing para o Red Hat Linux 2.0 em 1995. Um RPM declara as suas dependências e é produzido a partir de um ficheiro spec, uma receita de compilação que qualquer pessoa pode executar. Foi esta segunda propriedade que tornou possíveis as reconstruções independentes do produto empresarial da Red Hat.

O Red Hat Linux 9, lançado em 2003, foi a última versão da linha original. A empresa dividiu-a em duas: Fedora Core 1, em November 2003, como versão comunitária de lançamento rápido, e RHEL (Red Hat Enterprise Linux), que tinha começado como Advanced Server 2.1 em 2002, como versão paga e de evolução lenta. A causa é simples. Um produto não pode ser simultaneamente o local onde novas versões são testadas e a plataforma que um banco mantém sem alterações durante dez anos. As duas metades estão ligadas: uma versão principal do RHEL deriva de uma versão do Fedora, é estabilizada e depois congelada. A ferramenta de pacotes evoluiu no mesmo calendário, de yum nos anos 2000 para dnf como padrão do Fedora em 2015, com rpm subjacente a ambas.

Por que o CentOS deixou de ser um rebuild gratuito do RHEL

O CentOS começou em 2004 com uma tarefa simples: obter os pacotes-fonte publicados pela Red Hat, remover as marcas comerciais, recompilá-los e distribuir o resultado gratuitamente. Tornou-se a distribuição de servidor gratuita padrão durante uma década, e a Red Hat integrou o projeto em 2014.

Em 8 de dezembro de 2020, a Red Hat anunciou que o CentOS Linux 8 terminaria em 31 de dezembro de 2021, oito anos antes da data publicada, e que o nome continuaria como CentOS Stream. O Stream não é um rebuild. É o ramo a partir do qual são criadas as versões menores do RHEL, portanto fica à frente do RHEL, em vez de ficar atrás dele. Para uma máquina que pretende manter durante anos, ficar à frente é a direção errada, porque recebe alterações antes dos clientes pagantes da Red Hat.

Surgiram dois rebuilds em 2021. O Rocky Linux foi iniciado por Gregory Kurtzer, que foi cofundador do CentOS. O AlmaLinux foi financiado pela CloudLinux. Em junho de 2023, a Red Hat deixou de publicar fontes do RHEL em qualquer lugar além do CentOS Stream e do seu portal de clientes. O Rocky continuou a procurar rebuilds idênticos. O AlmaLinux alterou o seu objetivo para a compatibilidade ABI (application binary interface), o que significa que o software criado para RHEL funciona, sem a promessa de que a lista de bugs corresponda linha a linha. A Oracle, a SUSE e a CIQ criaram a OpenELA mais tarde nesse ano para publicar fontes partilhadas.

Se a lista de imagens de um fornecedor ainda indicar CentOS, descubra a que variante se refere antes de criar sistemas com base nela.

cat /etc/os-release

NAME="CentOS Stream" é um ramo de desenvolvimento contínuo que antecede o RHEL. NAME="AlmaLinux" ou NAME="Rocky Linux" é um rebuild que o acompanha, com uma janela de dez anos.

Ubuntu, 2004: um snapshot do Debian unstable num calendário

O Ubuntu 4.10 foi lançado em 20 de outubro de 2004, financiado por Mark Shuttleworth. A relação com o Debian é mecânica, não sentimental. Cada ciclo começa por importar pacotes do Debian unstable para a nova versão do Ubuntu. Essas importações continuam até ao Debian Import Freeze, a meio do ciclo. Depois disso, o Ubuntu mantém as suas próprias alterações. Muitos pacotes do Ubuntu são o pacote Debian mais um delta, e o changelog indica qual.

A outra metade é o calendário. O Debian é lançado quando está pronto. O Ubuntu é lançado em abril e outubro, e o número da versão corresponde à data: o 24.04 foi lançado em abril de 2024. A cada segunda versão lançada em abril é uma LTS (long term support), que é o que um fornecedor quer dizer quando lista o Ubuntu sem qualificadores. A escolha entre as duas versões para um servidor é o tema de escolher entre versões Ubuntu LTS e interim, e a passagem de uma LTS para a seguinte tem um procedimento próprio, descrito em a atualização do 24.04 para o 26.04.

Há um detalhe que chama a atenção dos administradores de servidores todos os anos. O arquivo do Ubuntu está dividido em componentes. main é mantido pela Canonical durante todo o período de suporte. universe é mantido pela comunidade, e a cobertura de segurança é uma promessa diferente. apt install não mostra nada sobre essa diferença. Um comando mostra-a:

apt-cache policy nginx

Uma linha de repositório terminada em /main significa que a equipa de segurança da Canonical é responsável por esse pacote. Uma linha terminada em /universe significa que a comunidade é responsável. Verifique isto em tudo o que estiver exposto à Internet.

Arch, 2002: rolling releases e o custo de uma atualização parcial

Judd Vinet lançou o Arch 0.1 em 11 March 2002, com um gestor de pacotes que escreveu de raiz, pacman, e receitas de compilação que são scripts shell simples. O Arch não tem versões lançadas. Os meios de instalação são snapshots datados dos mesmos repositórios rolling. Por isso, uma máquina instalada em 2019 e atualizada todas as semanas executa o mesmo Arch que uma máquina instalada hoje. O AUR (Arch user repository) contém receitas de compilação contribuídas pelos utilizadores. São receitas, não pacotes revistos. Ler um PKGBUILD antes de o executar faz parte do trabalho.

O modelo rolling tem um modo de falha. Ele é sempre causado pelo próprio administrador. Instalar um único pacote com pacman -Sy foo atualiza a base de dados de pacotes e instala depois um binário novo, ligado a bibliotecas mais recentes do que as instaladas no disco. Os programas falham então desta forma:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

A operação suportada é pacman -Syu, que atualiza tudo em conjunto. O projeto também publica notícias que indicam quando é necessária intervenção manual antes de determinadas atualizações. Executar a atualização sem as ler pode deixar uma máquina que não arranca.

Por isso, o Arch é uma escolha inadequada para um servidor que pretende ignorar. Uma máquina atualizada semanalmente funciona bem. Uma máquina atualizada uma vez, um ano depois, apresenta todas as intervenções adiadas numa única execução.

Alpine: uma distribuição pequena que os contentores tornaram famosa

A Alpine surgiu por volta de 2005 como um fork do LEAF (Linux embedded appliance framework), que por sua vez derivava do Linux Router Project. Natanael Copa criou-a para appliances, não para desktops. Substitui a maior parte do userland habitual: usa musl em vez da biblioteca GNU C, BusyBox em vez dos utilitários principais GNU, OpenRC em vez de systemd e apk como gestor de pacotes. A Alpine 3.0, lançada em 2014, foi a versão que passou a usar musl.

Os contentores tornaram-na popular. Uma camada base Alpine ocupa uma fração do espaço de uma base Debian ou Ubuntu. Por isso, a partir de 2016, tornou-se uma imagem base comum, e muitas pessoas que nunca instalaram Alpine passaram a executá-la diariamente.

O custo é que musl não é glibc, e a diferença manifesta-se em erros que parecem não ter relação. Um binário ligado a glibc falha na Alpine com uma mensagem que leva as pessoas a procurar um ficheiro que já existe:

sh: ./myapp: not found

O programa existe. O seu interpretador ELF não existe, porque o carregador de glibc está ausente. Python é outra fonte habitual de surpresas: os wheels pré-compilados para manylinux não instalam em musl. Por isso, pip tenta compilar a partir do código-fonte e para quando não existe um compilador instalado. O padrão de wheels musllinux, criado em 2021, resolveu o problema para os projetos que publicam esses wheels, mas não para os restantes.

Como sistema operativo anfitrião numa VPS, Alpine instala-se rapidamente, recebe atualizações depressa e afasta-o do caminho assumido pela maioria da documentação. Todos os guias que indicam executar systemctl enable precisam de ser adaptados para rc-update add.

A geração imutável: atualizações atómicas e servidores baseados em imagens

O ramo mais recente altera o modelo de atualização em vez da lista de pacotes. Um sistema baseado em ostree mantém /usr apenas para leitura. Uma atualização é uma árvore completa do sistema de ficheiros, descarregada, preparada e ativada no próximo reboot. A árvore anterior permanece disponível como uma entrada de arranque, pelo que uma atualização defeituosa pode ser revertida fazendo reboot para a versão anterior.

O Fedora Silverblue trouxe esse modelo para o desktop em 2018, e o Fedora CoreOS trouxe-o para os servidores em 2019, depois de a Red Hat ter comprado a CoreOS em 2018. O Flatcar Container Linux deu continuidade ao Container Linux original quando este foi descontinuado em 2020. O openSUSE MicroOS obtém o mesmo resultado através de snapshots do btrfs e transactional-update. Em 2024, a Red Hat adicionou um modo baseado em imagens ao RHEL, construído sobre bootc, no qual o sistema operativo é distribuído como uma imagem de contentor e uma máquina é atualizada apontando-a para uma nova tag. O Talos Linux vai mais longe e remove completamente a shell e o SSH: a máquina é configurada através de uma API, pelo que não existe nada em que iniciar sessão. O NixOS, lançado pela primeira vez em 2007, segue uma direção diferente. Todo o sistema é criado a partir de uma única configuração declarativa, e as gerações anteriores continuam disponíveis para arranque.

É provável que o seu fornecedor não disponibilize nenhuma destas opções como uma imagem de um clique, porque espera que sejam configuradas no primeiro arranque pelo Ignition ou pelo cloud-init, e não por um administrador a editar ficheiros através de SSH. Estas opções compensam quando existem muitas máquinas idênticas. Essa é a situação em que se encontra quando está a gerir vários servidores Linux ao mesmo tempo e precisa de provar que cada um é igual aos restantes.

Por quanto tempo uma release recebe suporte?

A política de releases é a parte de uma distribuição com a qual convive durante mais tempo e é publicada como um número de anos. Estas são as janelas de suporte para as 5 releases de servidor atuais.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

O Alpine suporta cada branch 3.x durante 2 anos. Por isso, é mais adequado para uma imagem de contentor que reconstrói com frequência do que para um host que deixa sem alterações. A equipa de segurança do Debian cobre uma release stable durante cerca de 3 anos. Depois, a equipa LTS mantém as arquiteturas comuns durante aproximadamente 5 anos no total. Uma Ubuntu LTS oferece 5 anos para os pacotes em main. Uma subscrição Ubuntu Pro prolonga esse período para 10 anos, gratuitamente para uso pessoal num pequeno número de máquinas. A RHEL 10 publica 10 anos. O add-on pago extended life cycle support prolonga esse período para 13 anos. A AlmaLinux 10 corresponde à janela da RHEL de 10 anos sem qualquer subscrição. Esse é precisamente o motivo pelo qual as reconstruções existem.

O Arch não aparece nesta tabela porque uma distribuição rolling não tem uma release para suportar. O número relevante para o Arch é o tempo durante o qual pode deixar uma máquina sem alterações. Esse tempo é medido em semanas.

Por que a lista de imagens do seu VPS é assim

Um provedor disponibiliza as imagens que os clientes pedem pelo nome e que são instaladas sem intervenção no hypervisor. Por isso, quase todas as listas começam com uma versão LTS do Ubuntu e uma versão stable do Debian, acrescentam AlmaLinux ou Rocky para quem tem software certificado para RHEL e deixam Alpine, Arch e Fedora mais abaixo na página. Depois de entender o que é um VPS e como a imagem chega ao disco, o padrão fica claro: o provedor escolhe sistemas operacionais que suportam uma instalação sem intervenção e permanecem suportados por mais tempo do que a maioria dos clientes mantém o servidor.

A escolha compromete mais do que o gestor de pacotes. Ela define a atualização que você executará daqui a três anos, e esse processo difere completamente entre as famílias. Debian e Ubuntu permitem atualizações de versão principais no próprio sistema. A família Red Hat faz isso por meio de leapp. O Arch não tem atualização de versão porque não tem versões. No Alpine, o processo consiste em editar /etc/apk/repositories e executar apk upgrade --available. A escolha também define qual software você pode instalar sem adicionar um repositório de terceiros, quem disponibiliza a correção quando surge uma entrada de CVE (common vulnerabilities and exposures) referente a algo que você executa e qual sistema init e biblioteca C o software futuro presumirá que estão disponíveis.

Há ainda outro efeito que é fácil subestimar. A maioria das respostas publicadas na internet presume um procedimento da família Debian ou da família Red Hat. Por isso, escolher outra família significa traduzir instruções durante toda a vida útil da máquina. Escolha a família cuja política de versões corresponda à frequência com que você aceita intervir no servidor e mantenha essa escolha. Alterar os pacotes instalados é fácil. Alterar a distribuição subjacente exige reconstruir o servidor.

FAQ

Em que família de distribuições Linux está o meu servidor?

Execute cat /etc/os-release. O campo ID indica a distribuição e ID_LIKE indica a respetiva família; por isso, uma máquina Ubuntu apresenta ID_LIKE=debian e uma máquina AlmaLinux apresenta ID_LIKE="rhel centos fedora". O gestor de pacotes é outra forma de confirmar. apt e dpkg indicam a família Debian, dnf e rpm indicam a família Red Hat, apk indica Alpine e pacman indica Arch.

O CentOS ainda é uma versão gratuita do RHEL?

Não. O CentOS Linux 8, a última reconstrução com esse nome, terminou em 31 December 2021, e o CentOS Linux 7 chegou ao fim de vida em 30 June 2024. O projeto que continua, CentOS Stream, é o ramo a partir do qual são criadas as versões minor do RHEL. Por isso, recebe alterações antes do RHEL, e não depois. As reconstruções gratuitas que assumiram o papel anterior são AlmaLinux e Rocky Linux, ambas com períodos de suporte de dez anos.

Porque é que o Debian stable disponibiliza números de versão tão antigos?

Porque o número de versão fica congelado enquanto as correções continuam a ser disponibilizadas. O Debian aplica patches de segurança à versão que lançou, em vez de importar uma versão upstream mais recente. Assim, um pacote identificado como 2.4.57-2+deb13u1 pode incluir uma correção publicada na semana passada. O sufixo depois da versão upstream é a revisão Debian, e apt changelog <package> lista o que foi incluído nela. Avaliar a segurança de um servidor Debian pelos números de versão dá sempre uma resposta errada.

Devo executar uma distribuição rolling release, como Arch, numa VPS?

Apenas se a atualizar regularmente. Uma distribuição rolling pressupõe que todas as máquinas convergem para o conjunto de pacotes atual. Por isso, atualizar um pacote com pacman -Sy foo pode deixar bibliotecas incompatíveis e gerar erros como cannot open shared object file. Execute pacman -Syu regularmente e consulte a página de notícias do projeto antes de cada execução. Assim, o sistema mantém-se estável. Se o deixar sem atualizações durante um ano, a primeira atualização torna-se a mais arriscada.

O que muda realmente numa distribuição imutável ou atómica?

Muda o momento em que as atualizações são aplicadas e a forma de as reverter. /usr é montado como somente leitura, uma atualização é preparada como uma árvore nova e completa, e a mudança ocorre no reboot. A árvore anterior é mantida como uma entrada de arranque para rollback. Obtém uma máquina que está totalmente atualizada ou totalmente não atualizada, sem um estado parcialmente aplicado. Em contrapartida, deixa de instalar software através da edição de ficheiros no local. As aplicações passam, por isso, para contentores ou pacotes em camadas.