Capítulo 3. Escolher uma distribuição Debian

# Capítulo 3. Escolher uma distribuição Debian

Existem muitas distribuições Debian diferentes. Escolher a distribuição Debian apropriada é uma decisão importante. Esta secção cobre alguma informação útil para utilizadores que querem fazer a melhor escolha apropriada para o seu sistema e também responde a perguntas possíveis que pode surgir durante o processo. Não lida com "porque deve escolher Debian" mas em vez disso "qual distribuição de Debian".

Para mais informação sobre as distribuições disponíveis leia Secção 6.1, “Quantas distribuições Debian existem?”.

## 3.1. Qual distribuição Debian (stable/testing/unstable) é melhor para mim?

A resposta é um pouco complicada. Depende realmente daquilo que pretende fazer. Uma solução seria perguntar a um amigo que corre Debian. Mas isso não significa que você não pode ter uma decisão independente. De facto, você deverá ser capaz de decidir assim que acabar de ler este capítulo.

- Se a segurança ou a estabilidade são tudo o que é importante para si: Instale a stable. ponto final. Este é o método mais preferido.

- Se você é um novo utilizador a instalar numa máquina de secretária, comece com stable. Algum do software é antigo, mas é o ambiente com menos bugs para trabalhar. Você pode facilmente para o mais moderno unstable (ou testing) assim que estiver um pouco mais confiante.

- Se você é um utilizador com muita experiência no sistema operativo e não se importa com um bug estranho de vez em quando, ou atém mesmo com quebra geral do sistema, use a unstable. Tem o melhor e mais recente software, e os bugs são geralmente corrigidos com rapidez.

- SE você está a correr um servidor, especialmente se for um com fortes requerimentos de estabilidade ou esteja exposto à Internet, instale stable. Esta é de longe a escolha mais forte e segura.

As seguintes questões fornecem (esperamos) mais informação nestas escolhas. Após ler esta FAQ completa, e se ainda não conseguir tomar uma decisão, fique pela distribuição stable.

### 3.1.1. Você pediu-me para instalar stable, mas em stable algum hardware não é detetado/não funciona. O que devo fazer?

Tente pesquisar na web usando um motor de busca e veja se alguém foi capaz de o pôr a funcionar em stable. A maioria do hardware deve funcionar bem com stable. Mas se você possuir algum hardware criado muito recentemente, esse pode não funcionar com stable. Se for este o caso, poderá querer instalar/actualizar para testing ou unstable.

Para portáteis, http://www.linux-on-laptops.com/ é uma boa página web para ver de mais alguém consegue fazê-lo funcionar sob Linux. Esta página web não é específica a Debian, mas mesmo assim é um tremendo recurso. Desconhecemos se existe tal página web para computadores de secretária.

Outra opção seria perguntar na lista de mail utilizador-debian ao enviar um email para debian-user@lists.debian.org. As mensagens podem ser postadas na lista mesmo sem a subscrever. Os arquivos podem ser lidos através de https://lists.debian.org/debian-user/. A informação sobre subscrição à lista pode ser encontrada na localização dos arquivos. Você é fortemente encorajado a postar as suas questões na lista de mail em vez de em irc. As mensagens na lista de mail são arquivadas, assim a solução para o seu problema pode ajudar outros com o mesmo problema.

### 3.1.2. Irão existir diferentes versões de pacotes em diferentes distribuições?

Sim. Unstable tem as versões mais recentes (últimas). Mas os pacotes em unstable não estão bem testados e podem ter bugs.

Por outro lado, stable contém versões antigas de pacotes. Mas estes pacotes estão bem testados e é menos provável que contenham bugs.

Os pacotes em testing ficam entre estes dois extremos.

### 3.1.3. As distribuições stable realmente contêm pacotes antigos. Basta olhar para Kde, Gnome, Xorg ou até mesmo o kernel. São muito antigos. Porquê?

Bem, você pode estar certo. A idade dos pacotes em stable dependem de quando o último lançamento foi feito. Como existi tipicamente mais de 1 ano entre lançamentos você pode descobrir que a stable contém versões antigas dos pacotes. No entanto, foram testados por dentro e por fora. Pode-se dizer com confiança que os pacotes não têm bugs severos conhecidos, buracos de segurança, etc... Os pacotes em stable integram-se perfeitamente com outros pacotes stable. Estas características são muito importantes para servidores de produção que têm de trabalhar 24 horas por dia, 7 dias por semana.

Por outro lado, os pacotes em testing ou unstable podem ter bugs escondidos, buracos de segurança etc. Mais ainda, alguns pacotes em testing e unstable podem nem trabalhar como se pretende. Geralmente as pessoas que trabalham só num computador preferem ter o conjunto de pacotes mais recente e mais moderno. Unstable é a solução para este grupo de pessoas.

Como pode ver, estabilidade e inovação são dois opostos do espectro. Se for necessário estabilidade: instale a distribuição stable. Se quer trabalhar com os pacotes mais recentes, então instale unstable.

### 3.1.4. Se Eu decidir mudar para outra distribuição, posso fazê-lo?

Sim, mas é um processo sem retorno. Você pode mudar de stable --> testing --> unstable. Mas a direcção inversa não é "possível". Portanto é melhor ter certezas se está a planear a instalar/actualizar para unstable.

Na verdade, se você for um "expert" e estiver disposto a gastar algum tempo e se for realmente cuidadoso e se souber o que está a fazer, então poderá ser possível ir de unstable para testing e depois para stable. OS scripts do instalador não foram desenvolvidos para fazer isso. Portanto no processo, os seus ficheiros de configuração poderão ser perdidos e ....

### 3.1.5. Pode dizer-me se devo instalar stable, testing ou unstable?

Não. Este é um problema muito subjetivo. Não existe resposta perfeita pois ela depende das suas necessidades de software, da sua aceitação de lidar com possíveis defeitos, e da sua experiência em administração de sistemas. Aqui estão algumas dicas:

- Stable é uma rocha. Não tem quebras e tem suporte de segurança completo. Mas pode não trazer suporte para o software mais recente.

- Testing tem software mais actualizado que Stable, e tem quebras menos frequentes que Unstable. Mas quando quebra, pode demorar muito tempo até que as coisas sejam retificadas. Por vezes podem ser dias e podem ser meses noutras alturas. Também não tem suporte de segurança permanente.

- Unstable tem o software mais recente e muita muitas vezes. Como consequência, pode quebrar a qualquer altura. No entanto, as correções são retificadas em muitos casos em poucos dias e tem sempre os lançamentos mais recentes do software empacotado para Debian.

Quando decidir entre testing e unstable tenha em mente que podem existir alturas que seguir testing pode ser benéfico em oposto a unstable. Um dos autores deste documento experimentou tal situação devido à transição do gcc de gcc3 para gcc4. Ele estava a tentar instalar o pacote `labplot` numa máquina que seguia unstable e não podia ser instalado em unstable pois algumas das suas dependências tinham feito a transição para gcc4 e outras não. Mas o pacote em testing podia ser instalado pois os pacotes de transição de gcc4 ainda não tinham passado para testing.

### 3.1.6. Você está a falar que testing tem quebras. O que quer dizer com isso?

Por vezes, um pacote pode não dar para instalar através das ferramentas de gestão de pacotes. Por vezes, um pacote pode nem sequer estar disponível, talvez tenha sido removido (temporariamente) devido a bugs ou dependências não satisfeitas. Por vezes, um pacote instala mas não se comporta da maneira apropriada.

Quando estas coisas acontecem, diz-se que a distribuição está quebrada (pelo menos para esse pacote).

### 3.1.7. Porque é que a testing pode ficar quebrada durante meses? As correções introduzidas em unstable não fluem directamente para testing?

As correções de bugs e melhoramentos introduzidos na distribuição unstable passam para testing após um certo número de dias. Digamos que este limiar é de 5 dias. Os pacotes em unstable vão para testing apenas quando não existem bugs RC reportados a eles. Se existir um bug RC aberto ao pacote em unstable, ele não irá para testing após 5 dias.

A ideia é que, se um pacote tem problemas, eles serão descobertos por pessoas que usam unstable e serão corrigidos antes de entrar em testing. Isto mantêm testing num estado utilizável na maioria do tempo. Em geral é um conceito brilhante, se mo perguntar. Mas as coisas não são sempre tão simples. Considere a seguinte situação:

- Imagine que está interessado no pacote XYZ.

- Vamos assumir que a 10 de Junho, a versão em testing é XYZ-3.6 e em unstable é XYZ-3.7.

- Após 5 dias, XYZ-3.7 de unstable migra para testing.

- Assim a 15 de Junho, ambos testing e unstable têm XYZ-3.7 nos seus repositórios.

- Digamos que, o utilizador da distribuição testing vê que um novo pacote XYZ está disponível e actualiza o XYZ-3.6 para XYZ-3.7.

- Agora a 25 de Junho, alguém a usar testing ou unstable descobre um bug RC no XYZ-3.7 e reporta-o no BTS.

- O responsável de XYZ corrige este bug e e envia para unstable digamos em 30 de Junho. Aqui é assumido que o responsável demora 5 dias a corrigir o bug e a enviar a nova versão. O número 5 não deve ser tomado literalmente. Pode ser menos ou mais, dependendo da severidade do bug RC com que lidamos.

- Esta nova versão em unstable, XYZ-3.8 é agendada para entrar em testing a 5 de Julho.

- Mas a 3 de Julho outra pessoa descobre outro bug RC em XYZ-3.8.

- Digamos que o responsável do XYZ corrige este novo bug RC e lança a nova versão do XYZ após 5 dias.

- Assim a 8 de Julho, testing tem XYZ-3.7 enquanto unstable tem XYZ-3.9.

- Esta nova versão XYZ-3.9 é agora re-agendada para entrar em testing a 13 de Julho.

- Agora como você está a correr testing, e como o XYZ-3.7 tem bug, você pode provavelmente usar o XYZ apenas após 13 de Julho. Isto é, essencialmente você ficou com um XYZ quebrado cerca de um mês.

A situação pode ficar muito mais complicada. Se por exemplo, XYZ depender de outros 4 pacotes. Isto pode levar a uma distribuição testing não utilizável durante meses. Apesar do cenário em cima ser imaginário, coisas semelhantes podem ocorrer na realidade, apesar de serem raras.

### 3.1.8. A partir do ponto de vista do administrador, qual distribuição requer mais atenção?

Uma das principais razões de muita gente escolher Debian sobre outras distribuições de Linux é que requer muito pouca administração. As pessoas querem um sistema que apenas trabalhe. Em geral, pode-se dizer que stable requer muito pouca administração, enquanto que testing e unstable requerem constante manutenção pelo administrador. Se você está a correr stable, tudo o que precisa se preocupar é acompanhar as actualizações de segurança. Se estiver a correr testing ou unstable é boa ideia estar consciente de novos bugs descobertos nos pacotes instalados, novas correções bugs/funcionalidades introduzidas, etc.

### 3.1.9. O que acontece quando é feito um novo lançamento?

Esta questão não irá ajuda-lo a escolher uma distribuição Debian. Mas mas cedo ou mais tarde você irá enfrentar esta questão.

A distribuição stable é actualmente trixie; A próxima distribuição stable será chamada forky. Vamos considerar o caso particular do que acontece quando forky é lançada como a nova versão stable.

- oldstable = bookworm; stable = trixie; testing = forky; unstable = sid

- Unstable é sempre referida como sid independentemente se foi feito um lançamento ou não.

- Pacotes migram constantemente de sid para testing (i.e. forky). Mas os pacotes em stable (i.e. trixie) permanecem os mesmos excepto para actualizações de segurança.

- Após algum tempo testing fica congelada. Mas mesmo assim é chamada de testing. Neste ponto nenhum novo pacote de unstable pode migrar para testing a menos que inclua correções de bugs RC (release-critical).

- Quando a testing está congelada, todas as novas correções de bugs introduzidas têm de ver verificadas manualmente pelos membros da equipa de lançamento. Isto é feito para assegurar que não existirão nenhuns problemas severos desconhecidos na testing congelada.

- Os bugs RC em 'testing congelada' são reduzidos para zero ou, se maior que zero, os bugs são marcados como ignorados para o lançamento ou são diferidos para um lançamento pontual.

- A 'testing congelada' sem bugs será lançada como a nova versão stable. No nosso exemplo, este novo lançamento stable será chamado forky.

- Neste estado oldstable = trixie, stable = forky. Os conteúdos de stable e 'frozen testing' são iguais neste ponto.

- Uma nova testing é baseada na testing antiga.

- Os pacotes começam a vir de sid para testing e a comunidade Debian irá trabalhar no sentido de criar o próximo lançamento stable.

### 3.1.10. Eu tenho um computador/grupo a funcionar com Debian instalado. Como é que sei qual distribuição estou a correr?

Na maioria das situações isto é muito fácil de descobrir. Veja no ficheiro `/etc/apt/sources.list`. Deverá existir uma entrada semelhante a isto:

    deb http://deb.debian.org/debian/ unstable main contrib

O terceiro campo ('unstable' no exemplo acima) indica a distribuição Debian que o sistema está presentemente a acompanhar.

Você também pode usar lsb_release (disponível no pacote `lsb-release`). Se você correr este programa num sistema unstable irá obter:

    $ lsb_release  -a
    LSB Version:    core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32
    Distributor ID: Debian
    Description:    Debian GNU/Linux unstable (sid)
    Release:    unstable
    Codename:   sid

No entanto, isto não é sempre tão fácil. Alguns sistemas podem ter ficheiros `sources.list` com múltiplas entradas correspondendo a diferentes distribuições. Isto pode acontecer se o administrador estiver a seguir pacotes diferentes de distribuições Debian diferentes. Isto é frequentemente referido como apt-pinning. Estes sistemas podem correr uma mistura de distribuições.

### 3.1.11. Eu estou actualmente a usar a versão stable. Posso mudar para testing ou unstable? Se sim, como?

Primeiro que tudo, por favor tenha em mente que a versão estável é aquele recomendada para servidores assim para computadores de secretária, não apenas você vai obter actualizações de segurança se estiver a correr stable mas também há menos alterações que possam potencialmente danificar o seu sistema ou sua configuração.

Se você está actualmente a correr stable, então no ficheiro `/etc/apt/sources.list` o terceiro campo será ou 'trixie' ou 'stable'. Se você deseja mudar para uma versão diferente, você precisa de mudar isto para a distribuição que quer correr. Se deseja correr testing, então mude o terceiro campo de `/etc/apt/sources.list` para 'testing'. Se deseja correr unstable, então mude o terceiro campo para 'unstable'.

Actualmente testing é chamada forky. Assim, se você mudar o terceiro campo de `/etc/apt/sources.list` para 'forky', então também irá estar a correr testing. Mas mesmo quando forky se tornar stable, você ainda vai estar a seguir forky.

Unstable é sempre chamada Sid. Assim, se você mudar o terceiro campo de `/etc/apt/sources.list` para 'sid', então você vai estar a seguir unstable.

AS ofertas actuais de Debian não oferecem actualizações de segurança para testing nem para unstable. A Equipa de Segurança Debian foco o seu trabalho na stable e old-stable. Contudo, tal como qualquer outro tipo de correções, as correções de segurança em unstable são feitas directamente para o arquivo principal e passam para testing em devido tempo. Assim se você está a correr unstable certifique-se que remove as linhas relativas a actualizações de segurança em `/etc/apt/sources.list`. Se você está interessado em saber que bugs de segurança conhecidos existem nestas versões das distribuições, você tem esta informação na lista de pacotes fonte vulneráveis em testing, e unstable.

Se existir um documente "release notes" para a distribuição que você está a actualizar (mesmo que ainda não tenha sido lançada) será inteligente revê-lo, pois pode fornecer informação sobre como se deve actualizar para ela. Você vai sempre encontrar as Notas de Lançamento de testing disponíveis no sítio web Debian mas dependendo de quão perto a versão testing está do lançamento o documento pode não cobrir todas as alterações e potenciais ratoeiras.

No entanto, assim que fizer as alterações de cima, você pode correr `aptitude update` e depois instalar os pacote que quiser. Note que instalar um pacote duma distribuição diferente pode actualizar automaticamente metade do seu sistema. Se você instalar pacotes individuais vai acabar com um sistema que corre uma mistura de distribuições.

Poderá ser melhor em certas situações fazer uma actualização total para a nova distribuição correndo apt full-upgrade, aptitude safe-upgrade ou aptitude full-upgrade. Leia os manuais do apt e aptitude para mais informação.

O manual de referência Debian fornece mais detalhes sobre correr testing e unstable na sua secção A vida com actualizações eternas.

### 3.1.12. Eu estou actualmente a seguir testing (forky). O que vai acontecer quando for feito um lançamento? Irei continuar a seguir testing ou a minha máquina irá correr a nova distribuição stable?

Depende das entradas no ficheiro `/etc/apt/sources.list`. Se você está actualmente a seguir testing, estas entradas são semelhantes a:

    deb http://deb.debian.org/debian/ testing main

ou a

    deb http://deb.debian.org/debian/ forky main

Se o terceiro campo em `/etc/apt/sources.list` for 'testing' então você vai estar a seguir testing mesmo após o lançamento ser feito. Assim após forky for lançada, você irá correr uma nova distribuição Debian a qual irá ter um nome de código diferente. As mudanças podem não ser aparentes no princípio mas serão evidentes assim que novos pacotes da unstable passem para a distribuição testing.

Mas se o terceiro campo conter 'forky' então você vai estar a acompanhar stable (pois forky irá ser a nova distribuição stable).

### 3.1.13. Ainda estou confuso. O que disse que Eu deveria instalar?

Um caso de duvida, a melhor aposta será a distribuição stable.

## 3.2. Mas então e Kali, Knoppix, Linux Mint, Ubuntu, e outros?

Estas distribuições não são Debian; elas são baseadas em Debian. Apesar de terem muitas semelhanças e coisas comuns entre elas, também há diferenças cruciais.

Com o decorrer dos anos, foram desenvolvidas muitas distribuições que reutilizam e/ou recompilam pacotes Debian e também adicionam pacotes personalizados seus. A maioria das distribuições foram criadas para audiências ou objectivos específicos. De acordo com a Distrowatch, Debian gerou mais de 420 derivações e mais de 120 delas estão activas à data desta escrita.

Todas estas distribuições têm os seus próprios méritos e são apropriadas para um conjunto específico de utilizadores. Para mais informação, leia Derivações de Debian disponível no sítio web de Debian. Você pode encontrar uma lista completa de derivações de Debian, incluindo aquelas que já não estão sob desenvolvimento activo em Censos de derivações de Debian na Wiki.

### 3.2.1. Eu sei que Kali/Knoppix/Linux Mint/Ubuntu/... são baseadas em Debian. Portanto, após instalar uma no disco rijo, posso usar as ferramentas de pacotes do 'apt' nela?

Estas distribuições são baseadas em Debian, mas não são Debian. Você vai poder usar as ferramentas de pacotes do apt ao apontar o ficheiro `/etc/apt/sources.list` para os repositórios destas distribuições. Em alguns casos algumas distribuições podem até ter gestores adicionais de pacotes que são usados em vez do apt.

Na maioria das situações se você ficar com uma distribuição você deve usar isso e não misturar pacotes de outras distribuições. Muitos problemas comuns surgem a pessoas que correm uma distribuição e tentam instalar pacotes Debian de outras distribuições. O facto de eles usarem o mesmo formato e nome (.deb), não os torna imediatamente compatíveis.

Por exemplo, Knoppix é uma distribuição Linux desenhada para arrancar como um live CD enquanto Debian é desenhada para ser instalada no disco rijo. Knoppix é ótimo se desejar saber se determinada peça de hardware funciona, ou se deseja experimentar como "se sente" um sistema GNU/Linux' etc., Knoppix é bom para objectivos de demonstração enquanto Debian é desenhada para correr 24/7. Mais do que o número de pacotes disponíveis e o número de arquitecturas suportadas por Debian são muito mais do que no Knoppix.

Se você quer Debian, é melhor instalar Debian a partir de Debian e siga. Apesar de ser possível instalar Debian através de outras distribuições, como a Knoppix, o procedimento requer conhecimentos de expert. Se você está a ler esta FAQ, Eu presumo que você é novato em ambos Debian e Knoppix. Neste caso poupe-se de montes de sarilhos depois e instale Debian desde o princípio.

### 3.2.2. Eu instalei Kali/Knoppix/Linux Mint/Ubuntu/... no meu disco rijo. Agora tenho um problema. O que devo fazer?

Você é aconselhado a não usar os fóruns Debian (sejam listas de mail ou IRC) a pedir ajuda em derivados de Debian pois as pessoas lá podem basear as suas sugestões assumindo que você está a correr um sistema Debian. Estas "correções" podem não ser apropriadas para o que você está a correr, e podem até tornar o problema pior.

Use primeiro os fóruns da distribuição específica que está a usar. Se não obter ajuda ou a ajuda que obter não corrigir o problema você pode querer tentar perguntar em fóruns Debian, mas tenha o conselho do parágrafo anterior em mente.

### 3.2.3. Estou a usar Kali/Knoppix/Linux Mint/Ubuntu/... e agora quero usar Debian. Como é que Eu migro?

Considere a mudança de uma distribuição baseada em Debian para Debian tal como uma mudança de um sistema operativo para outro. Você deve fazer uma cópia de salvaguarda de todos os seus dados e re-instalar o sistema operativo do zero. Você não deve tentar "actualizar" para Debian usando as ferramentas de gestão de pacotes pois pode acabar com um sistema não utilizável.

Se todos os seus dados de utilizador (isto é, a sua `/home`) está sob uma partição separada, migrar para Debian é bastante simples, você apenas precisa de dizer ao sistema de instalação para montar (mas não re-formatar) essa partição ao reinstalar. Mesmo assim é recomendado fazer salvaguardas dos seus dados, assim como da configuração do seu sistema anterior (isto é `/etc/` e, talvez `/var/`).

Capítulo 2. Obter e instalar Debian GNU/Linux |  | Capítulo 4. Problemas de compatibilidade