Como instalar Debian Unstable (Sid)

Para quem é destemido e quer testar as últimas novidades do mundo Linux, ensinamos a instalar o sistema que os desenvolvedores do Debian utilizam, o Debian Unstable (Sid).

2 curtidas

Pergunta legitima, mas não é melhor usar uma distro Rolling Release pra isso? eu posso até estar enganado, mas possível do Sid ser até inferior nesse aspecto… seria mais por uma possível estabilidade, na medida do possível? uma menor chance do sistema quebrar?

3 curtidas

Fala, Luiz! Errei o tom na matéria, fiz algumas alterações. De fato, esta não é a melhor opção para testar as novidades do mundo Linux, no máximo, poderíamos dizer que é uma opção. De toda forma, fica a dica para que quer testar o sistema que desenvolvedores do Debian utilizam para testar bugs, mas como disse na matéria, não recomendo como sistema principal.

3 curtidas

Só quis chamar atenção para algo, que ao meu ver não condizia exatamente com a realidade, mas o artrigo em si está ótimo.

1 curtida

Tão estável como qualquer Rolling. Já usei Sid testing e até híbrido de várias formas e sempre foi de boa.

Porém faz mais sentido sim usar uma distro que já seja Rolling ou algo do tipo porque sempre é bom andar junto com a “filosofia padrão” do sistema.

1 curtida

É a partir do sid que o Ubuntu se baseia ou do stable?

Do testing, o sid seria as versões de 9 meses do ubuntu

Valeu!!!
Agora quero ver como subo meu 12.5 pro testing hehehe

1 curtida

Em Abril 2020, era mais ou menos assim:

«Instalei o Debian buster em 24 de Março 2020, pela manhã, e transformei em Debian testing no mesmo dia, à tarde, — antes de começar a instalar muitos pacotes (para minimizar o risco de problemas nessa transição ). — Este relato, iniciado em 10 Maio, é uma tentativa de recuperar e fixar os passos que segui, nesse processo».

Também anotei a experiência anterior, em 2016, mas escrevi detalhes demais.

1 curtida

Já li e reli – e fiquei com algumas dúvidas:

Curiosidade legítima – pois nunca experimentei “Sid / Unstable”:

O Sid / Unstable tem, mesmo, “as últimas novidades”? De verdade?

Minha experiência até hoje foi só com o “Testing” – e nunca chegou, nem perto, das “últimas novidades”. – Acho que o Debian é “conservador”, até nisso.

O Arch Linux migrou para o KDE Plasma 6 no início de Março – e nesses mais de 3 meses, o openSUSE Tumbleweed, o Fedora 40, o KDE Neon, o Mageia Cauldron, o Void, o Manjaro também já migraram – enquanto o Debian Testing ainda continua com Plasma 5.

O Void foi o penúltimo, e fez caca durante 2 ou 3 semanas, até se ajeitar. – Tudo bem, afinal, acho que o Void nem oferece ISO “sabor KDE” (foi “experiência maluca”, que fiz… com base numa página da documentação Void, que depois desapareceu).

O último foi o Manjaro, que resistiu bravamente durante meses – mas quando migrou para o KDE Plasma 6, foi a coisa mais suave e bonita que vi. – Parece ter aproveitado esse tempo para aprender com os tropeços das outras distros (pois o Arch, mesmo, não tropeçou. Apenas, não foi tão “suave”).

Tenho grandes expectativas, sobre como será a transição do Debian Testing para o KDE Plasma 6. – Já fiz um estoque de pipoca, mandei fazer uma revisão no microondas, encomendei um engradado de refri 2 litros etc. – porque prevejo muita diversão.

Ok, “Testing” não é “Sid / Unstable”, mas pelo que me lembro do labirinto da documentação do Debian, fiquei com a impressão de que a diferença não é muito grande: – Coisa de alguns dias, para um pacote passar do Unstable para o Testing – onde realmente será testado por mais tempo.

Posso estar enganado, claro! O labirinto do site Debian dá um nó nos neurônios que ainda me restam. É só por isso que coloco a dúvida.

Não uso “Unstable”, e sim “Testing” – mas já vou completar 8 anos nessa brincadeira, em Outubro (faltam só 4 meses), e nunca tive qualquer problema realmente sério. – Só 1 vez, adiantaram um pacote do KDE (mas não outros), e durante 2 ou 3 semanas, tive de fazer um pequeno malabarismo para carregar o ambiente KDE (encontrei a dica facilmente, pelo Google). – Depois de carregar, funcionava normalmente, e podia usar dias e dias seguidos, na maior tranquilidade. O tilt era só no final do boot / login.

Acho que isso depõe a favor: – Só 1 pequeno tilt, em quase 8 anos. – Não quero dizer que seja recomendável usar em máquina de produção. – Mas está longe de ser um pesadelo terrível.

Concordo inteiramente.

Numa distro que é “oficialmente rolling-release”, você está em boa companhia, com uma multidão de usuários, todos fazendo “a mesma viagem” – conversando em fóruns “populosos”, dia e noite – e um monte de desenvolvedores sempre atentos.

Só o fato de o Debian ter 2 ou 3 versões “estáveis”, e mais Testing, e mais Unstable / Sid, já fragmenta bastante a conversa (complica o Google), e restringe o número de desenvolvedores / mantenedores. – O número de usuários do “Sid / Unstable” é só 1 pequena fração – e existe sempre a tentação de lhe responderem que “isto é só para quem dá conta de se virar” (rs)… ou que “use por sua conta e risco”… ou “se não consegue lidar com isso, volte para o Stable”… ou algo assim.

Agora, sobre o ótimo artigo do @Ariel_Bonfim – fiquei com algumas dúvidas – exatamente porque só conheço “Testing”, e não o “Sid / Unstable”:

fazer o backup das fontes do apt para conseguir retornar ao estado anterior com mais facilidade utilizando os comandos:

sudo mv /etc/apt/sources.list /etc/apt/sources.list.old
sudo mv /etc/apt/sources.list.d /etc/apt/sources.list.d.old
sudo mkdir /etc/apt/sources.list.d

Na qualidade de “velho revisor de textos” (rs), o que vejo aí não é “fazer um backup” mas, sim, “mudar os nomes” (mv = mover, usado para “renomear”). – Tanto que, na última linha, orienta a “criar” de novo uma pasta sources.list.d

Depois, quando diz:

mude suas fontes do apt para apontar para instável (unstable). Para isso, abra o arquivo /etc/apt/sources.list com algum editor de texto

… na verdade, não vai “abrir”, mas criar um novo aquivo sources.list

Parece que estou com um “detalhismo”, mas quando se fala em “mudar as fontes”, espera-se “alterar” – e não, “Adicione as duas linhas abaixo ao aquivo de texto”.

Aqui, uma dúvida:

deb http://deb.debian.org/debian sid main contrib non-free

deb http://deb.debian.org/debian sid main contrib non-free-firmware

A segunda linha, não é uma repetição (parcial) da primeira? – Não seria o caso de juntá-las – acrescentando na primeira linha, a única coisa diferente que existe na segunda linha?

deb http://deb.debian.org/debian sid main contrib non-free non-free-firmware

Dúvida sincera, porque eu não habilitei non-free-firmware (então, não sei se dá para botar ambos na mesma linha; acho que sim) – e lembro apenas vagamente, que essa foi uma “transição” feita algum tempo atrás. – Aqui está uma explicação “não-oficial”:

Não, non-free e non-free-firmware não são os mesmos repositórios e se você quiser os dois, você precisa ativar ambos.

A decisão de criar non-free-firmware foi tomada porque o firmware muitas vezes não atende às Diretrizes de Software Livre do Debian. No entanto, em muitos casos é bastante complicado (se não impossível) ser substituído / evitado para ter um sistema utilizável. O software livre muitas vezes não consegue acompanhar os drivers, etc., necessários.

Foi também decidido que a opção de excluir non-free software que não seja um requisito básico para ter um PC em funcionamento deverá continuar presente. Assim, os respectivos pacotes de software permanecem no formato non-free .

Observe que o Bookworm non-free-firmware é uma parte padrão da mídia de instalação, mas non-free não é. Isto também é diferente das imagens de instalação anteriores, onde o software não-livre era geralmente excluído.

  • Como eu evito placa de vídeo, em especial Nvidia, e outros componentes de hardware “hostis” ao mundo GNU / Linux / FOSS etc., continuei sem habilitar non-free-firmware, e até agora não senti falta de nada.

Eu recomendaria mudar para um espelho localizado no Brasil – que costuma ser 2 vezes mais rápido (pelo menos!), do que a conexão submarina para outro continente:

deb http://ftp.br.debian.org/debian/ sid main contrib non-free non-free-firmware

Já tive longa experiência de lentidão, demora etc., com us.debian.org – que apareceu no meu sources.list, não sei como. – Pode ser que deb.debian.org tenha ligação direta para o Brasil, mas não custa nada prestar atenção, e caso veja baixas velocidades, substituir pelo espelho explicitamente localizado no Brasil.

  • Note que eu mantive um “/” no final de “.org/debian/” – Isso é outra das milhares de dúvidas que () o Debian me dá (rs). – Eu uso assim (há muitos anos), e funciona… pelo menos, até ontem. – Devo ter pegado isso na própria documentação oficial do Debian (ou do meu sources.list original, logo após instalar, em 2016), e acho que não faz a menor diferença. – No caso, serve para me lembrar sempre de que, até ali, é uma URL – e dali em diante, é uma espécie de “parâmetro” ou “sinalizador”… embora possa corresponder a uma continuação da URL (tipo, 3 continuações da URL, em 1 só linha).

Agora, diferenças que realmente não posso avaliar – porque “Testing” é diferente de “Sid / Unstable”. – Meu sources.list é assim:

deb http://ftp.br.debian.org/debian/ testing main contrib non-free

deb http://ftp.br.debian.org/debian/ testing-updates non-free contrib main

deb http://ftp.br.debian.org/debian/ testing-proposed-updates contrib non-free main

deb http://security.debian.org/debian-security/ testing-security non-free contrib main

Ignoro totalmente, se estou fazendo “a coisa certa” – ou sequer, “alguma coisa aceitável”. – Uso Debian desde 2009, e o “Testing” desde 2016", e até hoje não consigo ter certeza de nada.

Então, vamos lá – linha por linha:

  • testing
  • testing-updates
  • testing-proposed-updates
  • testing-security

Detalhes que consigo perceber:

  • Todas com main contrib non-free – (às vezes, uso o Synaptic para mexer em algum detalhe, e ele troca a ordem… mas nunca pegou fogo nem explodiu)

  • Só a última, deve apontar para o repositório “principal” security.debian.org – e acho que esse não tem “espelhos”, por uma questão de segurança. – Outras distros também mantêm a parte de “segurança” centralizada no repositório principal, sem direito a “espelhos” locais espalhados mundo afora.

Acho que Sid / Unstable não precisa de -updates (ou nem tem isso). – Lidar com “Debian Testing” já me causa tamanha confusão na cabeça, que evito prestar atenção quando leio algo sobre “Stable” ou “Sid / Unstable”, para não endoidar de vez. – Então, vou ficar só no “achismo”, mesmo, para não induzir nenhum colega a uma falsa certeza.

E -proposed-updates, tenho certeza de que é coisa específica do “Testing” – para continuar recebendo novidades, durante aquele período de “congelamento” que precede o lançamento da próxima versão “Stable”.

E -security – não lembro se existe para o “Sid / Unstable”. – Tenho só uma vaga impressão de que “não”, mas… como disse, evito prestar atenção em tudo que não seja “Testing”, para não acabar num manicômio. – Nada de “certeza”. Só “uma vaga impressão”.

Quanto à pasta /etc/apt/sources.list.d/ – nela tenho apenas google-earth-pro.list, cujo conteúdo é:

deb [arch=amd64] http://dl.google.com/linux/earth/deb/ stable main

Esse “stable” é sobre a versão do Google-Earth. – Nada a ver com meu Debian não ser “stable”. – Nesse arquivo, eu não mexo nunca. Fica do jeito que o Google disse que deve ser.

É a única distro em que não precisei instalar o Google Chrome – talvez porque o Google não tenha tido coragem de “deprecar” o Chromium do Debian. – Continua sincronizando, e tudo mais que “deprecou” em todos no Chromium e demais derivados, em todas as outras distros que conheço.

Agradeço se alguém puder lançar luzes sobre algumas dessas dúvidas. – Debian é um assunto, que tenho uma penca de dúvidas, nunca 100% resolvidas – e não canso de pedir esclarecimentos, a quem puder ajudar.

Vou instalar numa vm e ver como está hoje em dia

se não me engano, não existe testing-security, testing-updates e testing-proposed-updates no “testing”

Salve, @acvsilva

O Debian – distro, site, wiki, doc, forum etc. – é um universo onde nunca consigo ter certeza de nada.

Eu leio uma cambulhada de páginas, configuro (ou, respondo algo aqui no fórum) – depois, trato de esquecer, para não acabar de ficar doido. – Minha 2ª resposta, acima (Junho 2024), deve ter me custado 386 horas de leitura e tortura mental – e custaria outro tanto, se eu fosse conferir tudo de novo, hoje! – Ninguém merece… :wink: e também não recomendo a ninguém. Só não deleto, para não truncar a sequência do diálogo.

Pelos meus cálculos, 11 em cada 10 páginas do Debian mudaram (ou podem ter mudado), nesses 365+ dias.

A única coisa +/- válida, é minha 1ª resposta, acima (Abril 2024), pois nela apenas linkei meu relato de como instalei / configurei meu Debian Testing em Janeiro 2020.

  • Aquele relato de 2020 já deve ter me custado 3.988 horas de leitura, verificações, tortura mental etc., pois vivo corrigindo… e não altero nada, sem conferir tudo de novo. – Mas, é só um “registro”, coisa “datada” – sem qualquer garantia de que sirva para hoje, como se fosse uma “receita” para a eternidade.

  • Linkei lá, também, o registro de minha experiência anterior, de 2016 – que hoje está ainda mais desatualizada. – Não são “tutoriais”. São meros registros do que fiz (inclusive erros). – Às vezes podem ser úteis para mim. Se forem úteis para mais alguém, ótimo. Mas sem garantia.

  • Somando tudo, em Outubro próximo vai fazer 9 anos que esse meu “Debian Testing” funciona e me atende muito bem – exceto por algum caruncho escondido, que ainda não causou nenhum desastre. :ghost: Toc toc toc!

Dito isso…

Meu arquivo /etc/apt/sources.list.d/debian.sources atual:

# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://ftp.br.debian.org/debian/
Suites: testing
Components: main contrib non-free
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://ftp.br.debian.org/debian/
Suites: testing-updates
Components: non-free contrib main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://ftp.br.debian.org/debian/
Suites: testing-proposed-updates
Components: contrib non-free main

e o “pré-modernizado” /etc/apt/sources.list – antigo – mais simples de ler e entender:

deb http://ftp.br.debian.org/debian/ testing main contrib non-free

deb http://ftp.br.debian.org/debian/ testing-updates non-free contrib main

deb http://ftp.br.debian.org/debian/ testing-proposed-updates contrib non-free main

deb http://security.debian.org/debian-security/ testing-security non-free contrib main

… que são “a mesma coisa” – escrita de 2 maneiras diferentes.

Não posso afirmar que todas essas coisas existam.

Acabo de me convencer de que “testing-security” não tem “non-free”, nem “contrib” – pois a documentação afirma que:

“Contrib”, “non-free” and “non-free-firmware” aren’t official parts of the Debian Distribution and are not released, and thus not supported by the security team.

Não foi isso que você disse que não existe – mas foi o que verifiquei agora mesmo – e trato de registrar, para “fixar” na memória.

Quanto ao “testing-security”, diz a página que… “existe, e não existe” – ou seja, é como se não existisse, pero existe asi mismo:

A testing-security repository does exist, but it is usually empty, and it is very, very unlikely to not be empty. It is there primarily so that people who intend to stay with forky after the release can have forky-security in their SourcesList so that they receive security updates after the release happens.

However the repository may get updates for serious issues, especially during the later freeze time close to a new stable release, or during long transitions, so people who have testing in their SourcesList (rather than the latest code name) should also consider adding the testing-security repository.

Portanto, não faz mal a ninguém – e pode até fazer bem!

Mas isso, é o que os doc do Debian dizem hoje. – Não fiz backup do que diziam em 2020, ou em 2016. – Será que na época ensinavam errado, e depois corrigiram? Pode até ser.

Quanto ao testing-proposed-updates, é – ou era, quando incluí! – um local para continuar obtendo alguns updates, naquela etapa de “congelamento” que precede o lançamento da próxima edição “stable”.

Onde foi que li isso? – Deve estar linkado em algum dos meus registros. – Pode ser que a página que li (em 2016? em 2020?), já tenha sido alterada.

Ou talvez, eu fiz tudo errado, desde 2020, talvez desde 2016! – Tudo é possível!

Em todas as outras distros, ou eu entendo alguma coisa, ou não entendo. – No Debian, eu nunca tenho certeza!

Não inventei nenhum desses trens. Cada trem desses me custou horas e horas de tortura mental, naquele labirinto de páginas do Debian. – O Debian mudou de ideia, de lá para cá? Não duvido nada!

Só sei, que gastei um zilhão de horas me torturando naquele labirinto – em 2016, em 2020 – e o piá tem funcionado muito bem, nesses quase 9 anos.

o que eu quero dizer é que não existe pacotes em security-testing porque não faz sentido. não haverá correção de bug, pela equipe do debian, como há no stable. você pode colocar o repositorio que será aceito, mais nada. também não tem sentido testing-backports. use apenas o testing “comum”:

deb http://ftp.br.debian.org/debian/ testing main contrib non-free non-free-firmware

quando o forky congelar, daqui a 2 anos, vc acrescenta os demais repositórios. aí sim.

estou usando o testing aqui só com esse de cima e baixa tudo, com e sem bug. as correções que acontecerem o são pelos desenvolvedores. o testing jamais será trixie, como você bem sabe.

não tem lógica o pessoal do debian corrigir bug de pacotes que sumirão daí algum tempo. por exemplo, tá entrando agora o gnome 49 e o 48 vai embora. por quê corrigir bug deste se a próxima versão tá chegando?

e se o pacote for contrib ou non-free, aí é que não corrige mesmo, se não forem open source, já que as licenças restringem esse trabalho.

se houvesse um security-testing, seria somente do main.

Por partes:

Acabei de mostrar o link de uma página oficial do Debian dizendo que existe.

Faz sentido dizer: — “Se existisse”…?

Não faz sentido, ficar acrescentando / removendo repositórios, só porque em 1 determinado momento “não são úteis” – e em outro momento voltam a ser úteis. – Uso “Testing” de modo permanente.

Não falei de backports, em nenhum momento, até porque, não estou usando.

No entanto, lembro que isso já esteve “em foco”, em algum momento, nesses 9 anos. – Não lembro mais o contexto, nem qual utilidade. – Ou não servia para o meu caso (e não usei)… ou deixou de ser útil (e parei de usar). Sinceramente, não lembro mais.

Mas repito: – Não inventei nada, desde 2016. – Sempre segui as páginas de documentação do Debian – inclusive, quebrando a cabeça, com páginas contraditórias!

Não sei se estão revisando, simplificando, eliminando páginas incorretas / superadas / ou que não se aplicam mais. – Se estiverem fazendo isso, ótimo. Mas…

Eu costumo pesquisar, ler, estudar novamente, em 2 situações:

  1. Quando recebo mensagem dizendo que algo deve ser alterado. – Nestes casos, é comum também ver várias postagens, em vários fóruns, alertando para a mudança. – Aí, vou lá, vejo o que preciso alterar, e corrijo.

  2. Quando alguma coisa falha, e se torna evidente que preciso fazer alguma mudança de rumo – porque algo mudou, e nada mais será como antes.

Nunca imaginei que se tornaria! – Para ser sincero, ignoro os números (10, 11, 12, 13) e os apelidos. – Para falar deles, preciso verificar algum Print, algum arquivo, ou googlar.

Na minha cabeça, é só “Testing” – desde sempre – e para sempre.

Essa parte de “contrib”, “non-free” etc., de fato, eu simplesmente acrescentei – “por via das dúvidas” – porque a documentação é “fragmentada”. – Onde fala de uma coisa, jamais fala de outra – independente de “ter cabimento” ou “não ter cabimento”.

Nunca encontrei uma página que falasse de todas as coisas ao mesmo tempo – mesmo quando fizesse sentido.

O Debian não é feito para leigos. É para quem “vive” dele, “profissionalmente”, 24 horas por dia, 7 dias da semana. Não é o meu caso. Por isso, Debian não é minha distro principal. Acho muito mais confortável usar o Arch, o openSUSE, o Mageia, o Fedora etc. – ou o MX Linux (Debian Stable).

Então, se as páginas que falam dos repositórios não falam de “contrib”, “non-free” – mesmo nos casos em que isso tem cabimento (p.ex., o repositório principal) – eu adicionei logo “contrib” e “non-free” em todos os lugares, para não gastar outras 453 horas.

Nisto, sim, chutei sem dó nem piedade. – Não explodiu, durante 9 anos. – Continua funcionando perfeitamente! Então, por que eu iria queimar meus 2 neurônios com isso?

Agora, que estamos conversando sobre isso, e verifiquei que vários “contrib” e “non-free” são inócuos (não, “prejudiciais”) – agora, sim, tenho algum motivo para pensar nisso, e eliminar o “excesso”.

O pessoal fala mal do fórum do Arch – mas a verdade é que o fórum do Debian nunca foi flor que se cheire! – Se tiver melhorado, ótimo. Mas não tenho vontade de voltar lá.

Um dia, quem sabe, dou uma olhada.

Agradeço as dicas. – Não pense que não percebo as informações úteis que você tem me passado – só porque indiquei motivos para rejeitar algumas delas.

Foi ótimo saber disso! – Obrigado!

Vou ver o que mais posso enxugar.