Debian ou Ubuntu: qual escolher para servidores?

Por que Debian e Ubuntu se separaram

Debian e Ubuntu se separaram em 2004 por causa do calendário, não do código. O Debian lança uma versão estável quando a equipa de lançamento considera que ela está pronta. O Ubuntu prometeu uma nova versão a cada seis meses, numa data definida antecipadamente. Por isso, obtém uma cópia do ramo de desenvolvimento do Debian, congela-a, corrige o que está avariado e lança a versão.

Vinte e dois anos depois, os dois ainda partilham o formato dos pacotes e as ferramentas que o gerem. A maior parte do trabalho de empacotamento necessário para ambos é feita uma única vez. O que não partilham é um calendário, um contrato de suporte ou uma opinião única sobre o que deve fazer parte de uma instalação predefinida. Essa é a distinção útil ao escolher um sistema operativo para um servidor, porque separa as diferenças cosméticas das que lhe podem custar uma tarde.

De onde veio o Ubuntu

Ian Murdock fundou o Debian Project em 16 de agosto de 1993. Em 2004, o Debian era a maior distribuição mantida por voluntários existente, mas era lento. O Debian 3.0 "woody" foi lançado em 19 de julho de 2002, e o sucessor, Debian 3.1 "sarge", só chegou em 6 de junho de 2005. Passaram-se quase três anos entre duas versões estáveis. Durante esse intervalo, quem quisesse software atual num servidor Debian não tinha uma solução com suporte do próprio Debian.

Em abril de 2004, Mark Shuttleworth convidou cerca de uma dúzia de desenvolvedores do Debian para o seu apartamento em Londres, a fim de planearem um sistema baseado no Debian com um calendário fixo, e fundou a Canonical Ltd para os empregar. A primeira versão, Ubuntu 4.10 "Warty Warthog", chegou seis meses depois, em 20 de outubro de 2004. O número da versão corresponde à data de lançamento: 4.10 significa outubro de 2004, e 26.04 significa abril de 2026.

O Ubuntu nunca foi um fork no sentido habitual. Um fork copia uma base de código uma vez e depois afasta-se do projeto original. O Ubuntu volta a copiar o Debian em cada ciclo. Os pacotes são obtidos do Debian unstable, o branch de desenvolvimento contínuo que o Debian chama sid, e essa cópia é atualizada automaticamente durante as primeiras semanas de cada ciclo do Ubuntu. Depois do import freeze, um desenvolvedor do Ubuntu tem de importar manualmente cada pacote adicional e justificá-lo de acordo com as regras do freeze. A árvore genealógica mais ampla das distribuições Linux contém muitos forks reais. Este não é um deles. É um downstream permanente.

O que os dois projetos ainda partilham

A parte partilhada é muito maior do que a parte diferente. Ambos utilizam o formato de pacotes .deb, com dpkg por baixo e apt por cima, e ambos seguem a Debian Policy quanto à localização dos ficheiros e à forma como os pacotes declaram as dependências. A documentação de desenvolvimento da própria Ubuntu estima que cerca de quatro em cada cinco pacotes-fonte são copiados do Debian sem qualquer alteração. Um maintainer que corrige um bug no Debian está também a corrigi-lo para os utilizadores do Ubuntu, normalmente sem que nenhum dos lados se aperceba.

Quando o Ubuntu altera um pacote, a cadeia de versão indica-o. O 1.2.3-4 do Debian passa a 1.2.3-4ubuntu1, e esse sufixo assinala a alteração local, a que ambos os projetos chamam delta. O Ubuntu publica o delta completo de todos os pacotes que altera e envia os patches para o sistema de acompanhamento de pacotes do Debian. Assim, um maintainer do Debian pode ver o que foi feito no downstream e integrá-lo, se quiser.

A questão de saber se isso é suficiente é discutida desde 2005. Vale a pena expô-la claramente, sem tomar partido. Do lado do Debian, a queixa está relacionada com o destino do esforço: a Canonical paga a pessoas para trabalharem no downstream, o downstream reúne os utilizadores e a atenção, e enviar uma correção de volta para o upstream exige trabalho adicional que ninguém é pago para fazer. Do lado do Ubuntu, um prazo de seis meses não é compatível com um projeto que não tem prazo, pelo que esperar pelo Debian nem sempre é uma opção. As duas afirmações são verdadeiras. Nenhuma impediu que os pacotes continuassem a circular.

Lançar quando estiver pronto, em vez de seguir uma data no calendário

A data de lançamento do Debian é um resultado, não uma promessa. O Debian 12 "bookworm" foi lançado em 10 June 2023 e o Debian 13 "trixie" em 9 August 2025, com cerca de dois anos de intervalo, mas nada garante que o próximo intervalo seja igual. O atual ramo testing chama-se "forky" e não tem data de lançamento, porque o Debian só anuncia uma quando a contagem de bugs críticos para o lançamento indica que isso é possível.

A data do Ubuntu é uma promessa. É lançada uma versão a cada seis meses e, a cada quarta versão, em abril de um ano par, é lançada uma versão LTS (long term support). O Ubuntu 26.04 LTS "Resolute Raccoon" foi lançado em 23 April 2026, dentro do prazo. As versões entre elas são versões interim e recebem atualizações durante apenas nove meses. Por isso, não são adequadas para um servidor que prefere não reinstalar duas vezes por ano. A escolha entre versões Ubuntu LTS e interim num servidor resume-se a esse período de nove meses.

A cadência define o calendário de upgrades, e essa é a consequência mais prática da diferença. No Ubuntu LTS, sabe com anos de antecedência que o próximo upgrade no local ocorrerá em abril de um ano par. Assim, o upgrade do Ubuntu 24.04 para 26.04 podia ser planeado antes de o 26.04 existir. No Debian, acompanha os anúncios de freeze e agenda o trabalho quando a versão é efetivamente lançada.

O que mudou com o LTS

O Ubuntu 6.06 LTS "Dapper Drake" foi lançado em 1 de junho de 2006 e foi o primeiro LTS. Antes dele, o Ubuntu era um sistema de evolução rápida, substituído duas vezes por ano. Não é esse o tipo de sistema em que uma empresa baseia um servidor de produção. O LTS fez uma coisa importante: definiu uma data futura para o fim do suporte, suficientemente distante para permitir a criação de um plano. Essa foi a mudança que tornou o Ubuntu a distribuição de servidor padrão. A cadência de seis meses sustenta esse modelo, porque cada LTS é montado com base no trabalho já validado nas versões intermédias anteriores.

O Debian chegou ao mesmo resultado a partir de outra direção. A sua versão estável já evoluía lentamente, e o projeto Debian LTS prolongou o período de suporte de cada versão depois de a própria equipa de segurança do Debian deixar de prestar suporte.

Quem fornece suporte e durante quanto tempo

[
  {
    "label": "Debian stable",
    "support_duration": 3
  },
  {
    "label": "Debian LTS",
    "support_duration": 5
  },
  {
    "label": "Debian ELTS, paid",
    "support_duration": 10
  },
  {
    "label": "Ubuntu LTS",
    "support_duration": 5
  },
  {
    "label": "Ubuntu Pro ESM",
    "support_duration": 10
  },
  {
    "label": "Ubuntu Pro plus Legacy",
    "support_duration": 15
  }
]

A própria equipa de segurança do Debian cobre uma versão estável durante 3 anos. Depois disso, a equipa Debian LTS, que o Debian descreve como um grupo de voluntários e empresas, e não como uma das suas equipas oficiais de segurança e de versões, prolonga essa cobertura até 5 anos. A transição é visível nas datas atuais: o bookworm entrou em LTS em 11 June 2026 e tem cobertura até 30 June 2028, enquanto o bullseye termina o período de LTS em 31 August 2026. Depois desse ponto, a Freexian vende Extended LTS, ou ELTS, até 10 anos, mas apenas para o subconjunto de pacotes que os seus clientes pagantes utilizam efetivamente.

Uma versão Ubuntu LTS recebe 5 anos de manutenção de segurança padrão da Canonical. Uma subscrição Ubuntu Pro aumenta esse período para 10 anos através de ESM (expanded security maintenance), abrangendo main e universe, e o complemento Legacy prolonga-o até 15. Em August 2026, o Ubuntu Pro é gratuito para utilização pessoal em até cinco máquinas. Por isso, num único VPS, os dez anos são uma realidade sem necessidade de uma ordem de compra. O Pro também inclui o serviço livepatch, que é a opção suportada para aplicar live kernel patching num VPS sem reiniciar a cada atualização de segurança do kernel.

A estrutura por trás desses números é mais importante do que os próprios números. Com o Ubuntu, compra suporte à mesma empresa que desenvolve a distribuição. Com o Debian, não existe uma empresa desse tipo. Por isso, o suporte pago vem de terceiros, como a Freexian, do seu fornecedor de alojamento ou da sua própria equipa.

Sistemas de inicialização e a votação que encerrou a discussão

A divergência técnica mais acentuada foi o sistema de inicialização, o primeiro processo que o kernel inicia e o supervisor de todos os serviços depois disso. O Ubuntu 6.10 "Edgy Eft", lançado em 26 October 2006, trouxe o Upstart, desenvolvido na Canonical. O Debian permaneceu no sysvinit durante anos, enquanto a discussão prosseguia. O Comité Técnico do Debian resolveu a questão com uma votação concluída em 11 February 2014, decidida pelo voto de desempate do presidente a favor do systemd para o Debian 8.

O Ubuntu seguiu a decisão poucos dias depois. A publicação de Shuttleworth sobre a decisão, intitulada "Losing graciously", apresentou claramente o motivo: o Ubuntu é essencialmente um membro da família Debian, por isso adotaria o resultado. O Ubuntu 15.04 trouxe o systemd como padrão em 23 April 2015, e o Debian 8 "jessie" fez o mesmo em 26 April 2015, três dias depois.

Essa convergência explica por que a maioria dos tutoriais de serviços pode ser usada nos dois sistemas sem alterações. Os ficheiros de unidade, systemctl e journalctl, comportam-se da mesma forma em ambos. O Debian 13 traz o systemd 257 e o Ubuntu 26.04 LTS traz o systemd 259. Portanto, a diferença entre eles nesse aspeto é o número da versão, não o design.

Snap e a parte que não é portável

O Ubuntu 16.04 LTS introduziu os pacotes snap em 2016, e o 18.04 foi a primeira versão a disponibilizar algumas aplicações predefinidas como snaps. Um snap é um pacote autónomo que inclui a sua própria cópia das dependências. Assim, um projeto upstream pode disponibilizar uma nova versão para todas as versões suportadas do Ubuntu ao mesmo tempo, sem esperar que o arquivo seja atualizado.

A razão por que nenhuma outra distribuição importante adotou os snaps como predefinição não é o formato. O cliente snapd comunica com uma única store, operada pela Canonical, e o lado do servidor dessa store não é open source. Assim, uma distribuição que adota snaps entrega parte da distribuição do seu software a outro fornecedor. O Debian não fez isso e não instala o snapd por predefinição.

É neste ponto que as instruções do upstream deixam silenciosamente de funcionar. O Certbot é o exemplo mais claro: a documentação do próprio projeto recomenda a instalação a partir de um snap e avisa que os pacotes da distribuição "tendem a ficar rapidamente desatualizados em distribuições do tipo LTS". Se seguir essa página no Ubuntu, tudo funciona. Se a seguir num servidor Debian com a instalação padrão, o primeiro passo não tem o que executar. O nosso próprio guia do Certbot para Nginx no Ubuntu 24.04 usa o pacote da distribuição por esse motivo.

Kernels, firmware e a questão do software não livre

O Contrato Social do Debian e as DFSG (diretrizes de software livre do Debian) definem o que pode entrar em main. Tudo o resto vai para contrib e non-free e, durante a maior parte da história do Debian, isso incluía os blobs de firmware binário de que o hardware comum de rede e armazenamento precisa para funcionar. Depois de uma Resolução Geral em 2022, o Debian 12 adicionou uma área de arquivo separada, non-free-firmware, e as imagens oficiais do instalador passaram a incluir esse firmware.

O Ubuntu tomou a decisão oposta desde o primeiro dia. O arquivo divide-se em main e restricted, mantidos pela Canonical e que incluem controladores proprietários, além de universe e multiverse, mantidos pela comunidade. Num VPS, o efeito é pequeno, porque o hardware virtual quase não precisa de firmware. Em hardware dedicado, é a diferença entre uma placa de rede que fica ativa e outra que não fica.

Os kernels divergem no mesmo eixo. Em agosto de 2026, o Ubuntu 26.04 LTS inclui o Linux 7.0 e o Debian 13 inclui o Linux 6.12. O Ubuntu também atualiza o kernel dentro de uma mesma LTS através das suas pilhas de habilitação de hardware, enquanto o Debian mantém uma série de kernels durante todo o ciclo de vida de uma versão stable e disponibiliza versões mais recentes através de backports. Uma versão mais recente oferece melhor suporte para dispositivos virtio e sistemas de ficheiros recentes. Uma versão mais antiga significa que o comportamento testado em janeiro continuará a ser o comportamento obtido em dezembro.

O que falha quando segue instruções destinadas ao outro

Na maioria dos casos, um guia escrito para uma distribuição funciona na outra. As falhas concentram-se em alguns pontos conhecidos.

• Os repositórios apt de terceiros são publicados por distribuição e por codename. Um fornecedor que suporta noble e jammy pode não publicar nada para trixie. A falha parece um problema de rede, mas resulta de uma decisão de suporte.
• Os PPAs do Launchpad são compilados apenas para séries específicas do Ubuntu. Adicionar um PPA ao Debian instala binários ligados às versões das bibliotecas do Ubuntu. Isso pode funcionar por acaso ou trazer uma parte significativa do runtime do Ubuntu para o sistema.
• Tudo o que pressupõe snapd, uma subscrição Ubuntu Pro ou o livepatch da Canonical não tem um passo equivalente no Debian. Essas secções do guia têm de ser substituídas, não adaptadas.
• As imagens predefinidas diferem no utilizador com que inicia sessão. As imagens do Ubuntu normalmente fornecem um utilizador ubuntu com sudo e sem palavra-passe de root. As imagens do Debian normalmente fornecem um utilizador debian. As imagens dos fornecedores variam. Verifique a sua imagem antes de alterar qualquer configuração de SSH.

Quando um repositório não tem uma suite para a sua release, o apt indica especificamente o problema:

E: The repository 'https://download.example.com/linux/debian forky Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Essa mensagem significa que o fornecedor nunca publicou pacotes para o seu codename. O mirror não está avariado e uma nova tentativa não resolverá o problema. O fornecedor suporta a sua release ou não suporta.

Então, qual deve escolher?

Escolha Ubuntu LTS quando quiser uma data de atualização que possa marcar no calendário com anos de antecedência e um único fornecedor a quem possa comprar suporte. Escolha Debian stable quando quiser uma instalação predefinida mais pequena, sem uma única empresa no caminho, e uma base que mude lentamente o suficiente para ser previsível.

Tudo o resto é transferível. Ambos usam apt, seguem a Debian Policy e executam as mesmas aplicações a partir do mesmo formato de pacote, por isso as competências acompanham-no. Se vem de Red Hat ou Fedora, os equivalentes dos comandos dnf e apt permitem fazer a correspondência nos dois sentidos. Se estiver a comparar estas duas opções com as outras imagens disponíveis no momento da implementação, o nosso guia para escolher um sistema operativo para o seu VPS apresenta-as lado a lado com o resto da lista.

FAQ

O Ubuntu é um fork do Debian?

Não. Um fork copia uma base de código uma vez e passa a mantê-la separadamente. O Ubuntu volta a importar pacotes do Debian unstable no início de cada ciclo de seis meses, e a documentação de desenvolvimento do Ubuntu estima que cerca de quatro em cinco pacotes-fonte sejam copiados sem modificações. O Ubuntu é um derivado permanente do Debian. Por isso, o conhecimento sobre empacotamento Debian é transferido para o Ubuntu sem alterações, e uma correção feita no Debian normalmente chega aos utilizadores do Ubuntu sem trabalho adicional.

Os tutoriais do Ubuntu funcionam no Debian?

Normalmente, e as exceções são previsíveis. Ambos usam apt, ambos usam systemd e ambos seguem a Debian Policy. Por isso, a gestão de pacotes e de serviços é semelhante. O que pode falhar são os procedimentos ligados à infraestrutura da Canonical: passos de instalação baseados em snap, PPAs do Launchpad, comandos do Ubuntu Pro e repositórios apt de terceiros publicados apenas para codinomes do Ubuntu. Quando um repositório não tem uma suite para a sua versão, o apt informa que ele "does not have a Release file". Isso significa que o fornecedor nunca compilou o pacote para o seu codinome.

Quanto tempo duram as atualizações de segurança do Debian e do Ubuntu?

Uma versão Ubuntu LTS recebe 5 anos de manutenção de segurança padrão da Canonical, 10 com uma subscrição Ubuntu Pro e até 15 com o complemento Legacy. Uma versão Debian stable recebe 3 anos da equipa de segurança do Debian e 5 anos contando o período LTS que se segue. O Extended LTS pago da Freexian chega a 10 anos, mas apenas para os pacotes solicitados pelos seus clientes.

Qual é melhor para um servidor: Debian ou Ubuntu?

Nenhum é melhor em geral. A escolha depende sobretudo do calendário de atualizações e do suporte. O Ubuntu LTS é adequado para um servidor em que a data da atualização tenha de ser previsível e em que seja necessário adquirir suporte de um único fornecedor. O Debian stable é adequado para um servidor em que uma instalação padrão menor e um ritmo de alterações mais lento sejam mais importantes do que um calendário fixo. Ambos executam o mesmo software a partir do mesmo formato de pacote. Por isso, a escolha não limita o que pode alojar.