História das distribuições Linux: Slackware, Debian e Red

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, escolher como o software é instalado e atualizado e comprometer-se a corrigi-lo durante anos. Uma distribuição é esse conjunto de escolhas, além do grupo de pessoas que continua a mantê-lo.

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 controladores que este adicionou.
• Um userland: a biblioteca C, a shell, o sistema init e os comandos padrão.
• Um formato de pacote 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: maintainers de 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 uma da outra do que qualquer uma delas está de outro Unix. É importante 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.

Uma história 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, os hábitos 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, montado por Owen Le Blanc no Manchester Computing Centre. Ele colocava o kernel e as ferramentas GNU (GNU's not Unix) em duas imagens de disquete, com um instalador orientado por menus. Existia porque fazer esse trabalho manualmente consumia um dia de trabalho.

O SLS (Softlanding Linux System), lançado por Peter MacDonald em 1992, foi além e adicionou o X (o X Window System) e suporte de rede TCP/IP. O SLS é a razão de a palavra distribuição ter o significado atual. Também tinha muitos erros e recebia pouca manutenção. Em 1993, duas pessoas decidiram corrigir o problema de forma independente. Uma delas o reconstruiu. A outra começou novamente, seguindo regras documentadas.

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

Patrick Volkerding lançou o Slackware 1.00 em 16 July 1993, desenvolvido a partir do SLS e com os bugs corrigidos. O projeto ainda é 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 sistema. Essa decisão isolada moldou todo o resto. Se a ferramenta não resolve dependências, o conjunto distribuído tem de ser coerente por construção, por isso os lançamentos são raros e conservadores. O Slackware 15.0 foi lançado em February 2022, seis anos depois do 14.2.

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

Debian, 1993: um contrato social e um pipeline com três suites

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

O Debian formalizou esses termos. O Debian Social Contract e as DFSG (Debian free software guidelines) foram adotados em July 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 diretrizes, contrib e non-free contêm o que não as cumpre, e o Debian 12 adicionou non-free-firmware para que um portátil com uma placa sem fios pudesse instalar o sistema sem procurar manualmente todos os componentes necessários.

As ferramentas são a outra herança. dpkg instala um pacote e recusa-se a prosseguir quando falta alguma dependência, apresentando dpkg: dependency problems prevent configuration of. O APT (advanced package tool), que se tornou a opção predefinida no Debian 2.1 em 1999, é a camada que determina o que mais deve ser transferido e por que ordem. Todos os comandos apt em todos os derivados do Debian descendem 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 o pacote tiver sido compilado nas arquiteturas de lançamento e não tiver recebido um novo bug crítico para o lançamento. A testing entra depois em freeze, a release team resolve o que resta, e a stable é lançada quando a lista de bugs é suficientemente curta. Não existe uma data fixa. É por isso que a stable do Debian parece antiga e funciona bem: os números de versão ficam fixos durante o 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 do 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 Devuan, que fez o seu primeiro lançamento em 2017. O Debian não foi a primeira distribuição a fazer essa mudança, nem a última, e os motivos pelos quais ela continuou a ocorrer, juntamente com as objeções que se revelaram corretas, são explicados em o relato de como o systemd substituiu o SysV init. Os derivados de maior dimensão são o Ubuntu, o Raspberry Pi OS, o Proxmox VE, o Kali e o Linux Mint.

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

Marc Ewing lançou a primeira versão do Red Hat Linux por volta do Halloween de 1994. A empresa de Bob Young comprou-a em 1995, e os dois criaram o primeiro negócio de Linux que vendia suporte em vez de software. A Red Hat abriu o capital em 11 August 1999. A IBM concluiu a aquisição da empresa em July 2019 por cerca de 34 billion dollars. Desde então, a distribuição contra a qual a maior parte do software empresarial é 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. Esta segunda propriedade 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: o Fedora Core 1, lançado em November 2003 como versão comunitária de desenvolvimento rápido, e o RHEL (Red Hat Enterprise Linux), que tinha começado como Advanced Server 2.1 em 2002, como versão paga e de desenvolvimento lento. A causa é simples. Um produto não pode ser simultaneamente o local onde se testam versões novas e a plataforma que um banco mantém inalterada durante dez anos. As duas partes continuam ligadas: uma versão principal do RHEL deriva de uma versão do Fedora, é estabilizada e depois congelada. A ferramenta de pacotes avançou no mesmo ciclo, de yum nos anos 2000 para dnf como padrão do Fedora em 2015, com rpm por baixo de ambas.

Por que o CentOS deixou de ser uma recompilação gratuita 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 servidores gratuita padrão durante uma década, e a Red Hat passou a gerir o projeto internamente 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 é uma recompilação. É o ramo a partir do qual são criadas as versões secundárias do RHEL. Por isso, 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. As alterações chegam antes aos utilizadores do que aos clientes pagantes da Red Hat.

Em 2021 surgiram duas recompilações. Rocky Linux foi iniciado por Gregory Kurtzer, que cofundou o CentOS. A AlmaLinux foi financiada pela CloudLinux. Em junho de 2023, a Red Hat deixou de publicar fontes do RHEL em qualquer local além do CentOS Stream e do portal dos clientes. O Rocky continuou a procurar criar recompilações idênticas. A AlmaLinux alterou o seu objetivo para a compatibilidade ABI (application binary interface). Isso significa que o software criado para RHEL é executado, sem uma promessa de que a lista de erros seja exatamente igual. Oracle, SUSE e CIQ criaram a OpenELA mais tarde nesse ano para publicar fontes partilhadas. Toda essa sequência, desde a divisão de 2003 até à alteração das fontes em 2023 e ao que cada recompilação promete atualmente, é descrita em o relato mais detalhado sobre Red Hat, CentOS, Rocky e AlmaLinux.

Se a lista de imagens de um fornecedor ainda indicar CentOS, descubra qual versão isso significa 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" é uma recompilação que o acompanha, com um ciclo 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: 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 qualificador. 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 o seu próprio procedimento, descrito em a atualização de 24.04 para 26.04.

Há um detalhe que apanha os administradores de servidores de surpresa todos os anos. O archive 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 segue 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 esteja exposto à Internet.

Arch, 2002: atualizações contínuas 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, pacman, e receitas de compilação que são scripts shell simples. O Arch não tem versões numeradas. Os meios de instalação são snapshots datados dos mesmos repositórios de atualização contínua. Assim, 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. Por isso, ler um PKGBUILD antes de o executar faz parte do trabalho.

As atualizações contínuas têm um modo de falha, e 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 existentes no disco. Os programas falham 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 entradas de notícias que informam quando é necessária intervenção manual antes de determinadas atualizações. Executar a atualização sem as ler pode deixar uma máquina sem arrancar.

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

Alpine: a pequena distribuição que os contentores tornaram conhecida

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

Os contentores tornaram-na popular. Uma camada base Alpine ocupa uma pequena fração do espaço de uma imagem 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 bugs 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 interpretador ELF não existe, porque o loader de glibc está ausente. Python é a outra surpresa frequente: wheels pré-compiladas para manylinux não são instaladas em musl. Por isso, pip tenta compilar a partir do código-fonte e para quando não existe nenhum compilador instalado. O padrão de wheels musllinux, introduzido em 2021, resolveu o problema para os projetos que publicam essas wheels, e para mais ninguém.

Como sistema operativo anfitrião numa VPS, Alpine instala rapidamente, ocupa pouco espaço e recebe atualizações depressa. Também coloca o sistema fora do caminho assumido pela maioria da documentação. Cada guia que diz para executar systemctl enable precisa de ser adaptado para rc-update add.

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

A versão mais recente altera o modelo de atualização, e não a lista de pacotes. Um sistema baseado em ostree mantém /usr apenas para leitura. Uma atualização é uma nova árvore completa do sistema de ficheiros, transferida, preparada e ativada no reboot seguinte. A árvore anterior permanece disponível como uma entrada de arranque. Assim, uma atualização com problemas pode ser revertida através do arranque pela versão anterior.

O Fedora Silverblue levou este modelo para o desktop em 2018, e o Fedora CoreOS levou-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 btrfs e transactional-update. Em 2024, a Red Hat adicionou um modo baseado em imagens ao RHEL, criado 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 abordagem 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 instalação com 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 são vantajosas quando existem muitas máquinas idênticas. Essa é a situação em que se encontra quando está a gerir vários servidores Linux em simultâneo e precisa de provar que cada um é igual aos restantes.

Por quanto tempo uma release é suportada?

A política de releases é a parte de uma distribuição com a qual você convive por mais tempo, e é publicada como um número de anos. Estas são as janelas de suporte das 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 oferece suporte a cada ramo 3.x durante 2 anos. Por isso, ele se adapta melhor a uma imagem de contêiner que você recompila com frequência do que a um host que permanece sem alterações. A equipe de segurança do Debian cobre uma release estável durante aproximadamente 3 anos. Depois, a equipe de LTS mantém as arquiteturas comuns por cerca de 5 anos no total. Uma Ubuntu LTS oferece 5 anos para os pacotes em main. Uma assinatura do Ubuntu Pro estende esse período para 10 anos, gratuitamente para uso pessoal em um número pequeno de máquinas. A RHEL 10 publica 10 anos. O complemento pago de suporte ao ciclo de vida estendido aumenta esse período para 13. A AlmaLinux 10 corresponde à janela da RHEL, com 10 anos e sem qualquer assinatura. Esse é o motivo principal da existência dessas recompilações.

O Arch não tem uma linha aqui, porque uma distribuição rolling não tem uma release para suportar. No Arch, o número relevante é por quanto tempo você pode deixar uma máquina sem alterações. Esse período é 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 podem ser 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, incluem AlmaLinux ou Rocky para quem usa software certificado para RHEL e deixam Alpine, Arch e Fedora mais abaixo. 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 o período médio em que um cliente mantém o servidor.

A escolha compromete mais do que um gestor de pacotes. Ela define a atualização que você fará daqui a três anos, e esse processo é completamente diferente em cada família. Debian e Ubuntu permitem atualizações de versão principais no próprio sistema. A família Red Hat faz esse processo 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 quais softwares você pode instalar sem adicionar um repositório de terceiros, quem fornece a correção quando surge uma entrada de CVE (common vulnerabilities and exposures) relacionada a algo que você executa e qual sistema init e biblioteca C os seus softwares futuros considerarão disponíveis.

Há ainda outro efeito que é fácil subestimar. A maioria das respostas publicadas na internet pressupõe um procedimento da família Debian ou da família Red Hat. Portanto, escolher uma distribuição fora dessas duas famílias significa traduzir instruções durante toda a vida 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 identifica a distribuição e ID_LIKE identifica a família. Assim, 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 do suporte em 30 June 2024. O projeto que continua, o CentOS Stream, é a branch a partir da qual são criadas as versões menores do RHEL. Por isso, recebe alterações antes do RHEL, e não depois. As reconstruções gratuitas que assumiram o papel antigo são AlmaLinux e Rocky Linux, ambas com períodos de suporte de dez anos.

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

Porque o número da versão fica congelado enquanto continuam a ser disponibilizadas correções. O Debian aplica patches de segurança à versão que lançou, em vez de importar uma versão upstream mais recente. Por isso, 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> apresenta as alterações incluídas nela. Avaliar a segurança de um servidor Debian pelos números de versão conduz sempre a uma conclusão errada.

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

Só se a atualizar segundo um calendário definido. Uma distribuição rolling pressupõe que todas as máquinas convergem para o conjunto atual de pacotes. Por isso, atualizar um pacote com pacman -Sy foo pode deixar bibliotecas incompatíveis e produzir erros como cannot open shared object file. Execute pacman -Syu regularmente, leia a página de notícias do projeto antes de cada execução e o sistema será estável. Se deixar passar 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 desfazer. /usr é montado como somente leitura. Uma atualização é preparada como uma árvore nova completa. A troca ocorre no reboot, e a árvore anterior é mantida como entrada de arranque para permitir o rollback. A máquina fica sempre totalmente atualizada ou totalmente desatualizada, sem um estado parcialmente aplicado. Deixa de ser possível instalar software editando ficheiros no local. Por isso, as aplicações passam para contentores ou para pacotes em camadas.