Por que o Debian é como é hoje?
(blog.liw.fi)- As práticas únicas do Debian vêm das escolhas acumuladas por um grande sistema operacional de uso geral com 30 anos de história para manter por muito tempo qualidade, segurança e os princípios do software livre
- Em vez de ser uma distribuição para um uso específico, busca ser uma distribuição de uso geral adequada para a maioria das pessoas e dos objetivos, e os critérios centrais para incluir pacotes são se o software é livre e se pode ser mantido com qualidade
- A Constituição, o Contrato Social e o DFSG surgiram depois que a operação mais solta dos primeiros anos mostrou seus limites, institucionalizando a tomada de decisão democrática e poderes limitados para a liderança
- A política de builds autocontidos e de evitar bibliotecas empacotadas junto serve como uma estratégia de manutenção que permite correções urgentes de segurança, rebuilds e portabilidade para novas arquiteturas sem depender de repositórios externos ou de dependências duplicadas
- O processo de admissão de membros, os codinomes de lançamento e o ritmo lento de mudanças são a forma como um projeto com milhares de pacotes e uma base instalada de dezenas de milhões de máquinas administra confiança, custos de espelhamento e custos de consenso
O sistema operacional que o Debian busca ser
- O Debian busca ser um sistema operacional de alta qualidade, seguro e de uso geral, composto apenas por software livre e de código aberto que funcione na maioria dos computadores usados ativamente
- O objetivo de ser um sistema operacional de uso geral significa que o Debian deve ser adequado para a maioria das pessoas na maioria dos propósitos
- Não pode servir para todas as situações, mas é uma meta que vale a pena perseguir
- Isso leva a decisões diferentes das de distribuições focadas em objetivos específicos, como desktop, servidor, jogos ou pesquisa científica
- A decisão de empacotar ou não um software depende menos da finalidade dele e mais dos critérios abaixo
- se o software é software livre
- se o Debian consegue mantê-lo como um pacote de alta qualidade
Constituição e governança
- O Debian é próximo de uma organização de código aberto explicitamente democrática
- Os procedimentos de tomada de decisão são bem definidos
- Um Debian Project Leader é eleito todos os anos
- Os poderes do líder do projeto são estritamente limitados, e muitos dos poderes normalmente associados à liderança são explicitamente delegados a outras pessoas
- Os primeiros Debian Project Leaders eram, na prática, ditadores com plenos poderes até decidirem sair por conta própria
- Depois que um líder do projeto passou dos limites, houve reação e ele deixou o cargo; como resultado, a democracia foi introduzida
- O Debian define as regras do projeto em uma Constituição oficial
- O sistema atual de regras vem da experiência dos primeiros anos, quando menos regras e menos burocracia não funcionaram bem no Debian
Contrato Social e Debian Free Software Guidelines
- Em meados dos anos 1990, antes da introdução do termo “open source”, “free software” já era definido pela Free Software Foundation, mas havia bastante margem para interpretação
- O Debian queria regras mais claras e criou as Debian Free Software Guidelines (DFSG), tornando-as parte do Contrato Social
- O Contrato Social é o documento-base em que o Debian promete o que ele é e o que faz para si mesmo e para o mundo
- O DFSG faz parte dele
- A Constituição do Debian torna intencionalmente difícil alterar o Contrato Social
- Regras mais detalhadas tornam mais claro o que o Debian aceitará e simplificam as discussões relacionadas
- O DFSG mais tarde se tornou a base da Open Source Definition
O princípio de builds autocontidos
- O Debian insiste no princípio de ser autocontido (self-contained)
- Tudo o que o Debian empacota deve ser compilado usando apenas dependências que estão dentro do próprio Debian
- Tudo que está no Debian deve ser compilado pelo próprio Debian
- Esse princípio pode gerar bastante trabalho extra
- Muitas ferramentas modernas de linguagens de programação partem do pressuposto de baixar dependências de repositórios online no momento do build
- No Debian, esse método não é permitido
- A razão principal é que dependências externas podem desaparecer depois
- O Debian não controla repositórios de pacotes de terceiros
- Se um pacote ou um repositório inteiro desaparecer, o Debian pode não conseguir recompilar aquele pacote
- Rebuilds são necessários para upgrades de compiladores, correções de falhas de segurança, portabilidade para novas arquiteturas e aplicação de correções de bugs
- Sem ser autocontido, no momento de uma correção urgente de segurança dezenas de milhares de pacotes e todas as suas dependências precisariam estar disponíveis, então o Debian prefere empacotar todas as dependências
Por que evitar bibliotecas empacotadas junto
- O Debian evita usar cópias de bibliotecas ou de outras dependências incluídas dentro do software que está sendo empacotado
- Muitos projetos upstream consideram mais fácil agrupar ou fazer vendor das dependências
- Do ponto de vista do Debian, isso pode gerar várias cópias de uma biblioteca popular
- Se essa biblioteca tiver um problema de segurança ou outro problema sério, será preciso encontrar e corrigir todas as cópias
- Em um problema urgente de segurança, isso desperdiça um tempo valioso
- No caso do zlib, o Debian encontrou dezenas de cópias empacotadas junto dentro do arquivo e precisou fazer um esforço considerável para garantir que os pacotes do Debian usassem apenas a versão do zlib empacotada no próprio Debian
- Por isso, o Debian faz esse trabalho com antecedência na etapa de empacotamento, para que os pacotes dentro do Debian usem as versões de bibliotecas empacotadas pelo próprio Debian antes que uma emergência aconteça
- Desenvolvedores upstream às vezes querem lidar apenas com a versão empacotada junto que eles mesmos validaram, então essa abordagem ocasionalmente gera atrito com o Debian
Processo de admissão de membros
- Como sistema operacional, o Debian é grande, complexo e amplamente usado, então precisa confiar em seus membros
- Essa confiança é especialmente importante para quem faz upload de novos pacotes
- Por causa das limitações técnicas do Linux nos anos 1990, todos os pacotes Debian tinham acesso root completo durante a instalação
- Todos os desenvolvedores Debian podiam potencialmente se tornar usuário root em qualquer máquina que executasse Debian
- Como o Debian roda em dezenas de milhões de máquinas, isso representa um grande poder
- Novos membros são verificados de várias formas
- Idealmente, devem ter participado da comunidade de desenvolvedores Debian por tempo suficiente para serem conhecidos por outras pessoas
- Devem construir confiança dentro da comunidade
- Esse processo pode ser bastante frustrante para quem quer participar do Debian, especialmente para quem está acostumado a projetos open source menores
Codinomes de lançamento
- O Debian dá um codinome a cada grande lançamento
- Essa prática surgiu originalmente para reduzir o custo de espelhamento do arquivo de pacotes do Debian
- Em meados dos anos 1990, durante a preparação do lançamento do Debian 1.0, diretórios eram criados com o nome da versão, sem usar codinomes
- Como o desenvolvimento de uma nova versão leva tempo, o diretório “1.0” era criado com antecedência
- Uma editora de CD-ROM produziu em massa, antes da conclusão do Debian 1.0, discos marcados como “1.0”
- Como resultado, quem recebeu o CD-ROM do Debian 1.0 acabou recebendo algo que não era de fato o 1.0
- A solução simples teria sido preparar tudo em um diretório como “1.0-not-released” e, após o lançamento, renomeá-lo para “1.0”
- Mas, se o nome do diretório mudasse, todos os mirrors teriam de baixar novamente o lançamento inteiro, e isso tinha um custo alto para o tamanho do Debian na época
- Naquele momento, a escala era de “centenas de pacotes” e “dezenas de MB”
- Depois, a estrutura pool foi adicionada ao arquivo do Debian
- Os arquivos de todos os lançamentos ficam na mesma árvore de diretórios, e os arquivos de metadados especificam quais arquivos pertencem a cada lançamento
- Essa estrutura facilita o espelhamento
- Hoje talvez fosse possível abandonar os codinomes e usar apenas números de versão, mas não dá para saber se isso interessaria ao Debian
Por que o Debian muda devagar
- O Debian é um projeto muito grande, e projetos grandes mudam devagar
- Mudanças que afetam muitos pacotes podem exigir trabalho de centenas de voluntários, então dificilmente avançam rápido
- Alguns trabalhos podem ser resolvidos por poucas pessoas, e o Debian tem procedimentos que tornam isso possível
- Por exemplo, quando uma nova versão do GNU C compiler é enviada, o trabalho de encontrar as correções necessárias em outros pacotes normalmente pode ser feito por um pequeno grupo
- Outra razão para a lentidão das mudanças é a necessidade de formar consenso
- O consenso exige discussões amplas
- Essas discussões levam tempo e só raramente podem ser encurtadas
- Os desenvolvedores Debian tendem a ser conservadores em decisões técnicas
- Muitas vezes preferem soluções que não exijam mudanças em larga escala
1 comentários
Opiniões do Hacker News
Self-contained e ausência de bibliotecas empacotadas junto são conceitos importantes que parte do ecossistema ignorou por considerá-los trabalhosos demais.
Só depois de sofrer novamente com os problemas resultantes é que passaram a usar termos como “cadeia de suprimentos de software”, e como o Debian sempre fez as coisas de um modo que evita esse tipo de problema desde o início, sofreu menos com as mesmas dores.
Para distribuir software entre várias distribuições e sistemas operacionais, empacotar dependências junto é razoável; já do ponto de vista de quem mantém uma distribuição, bibliotecas compartilhadas, nas quais basta aplicar um patch de segurança uma única vez, são claramente melhores.
No nível do sistema operacional, há movimentos como Nix e Silverblue; no nível das aplicações, Snaps e Flatpak. Não sei qual é a solução, mas parece que o Debian também terá de fazer algo em breve.
Para usar outras versões, seria preciso testar cuidadosamente e corrigir os bugs encontrados; não sei se o Debian tem recursos para isso. No fim, acaba usando combinações de bibliotecas não verificadas e torcendo para dar certo, mas não acho que vá funcionar assim.
Há muito tempo, firmwares públicos vindos do repositório linux-firmware são distribuídos apenas como binários, sem serem compilados a partir do código-fonte, e provavelmente há outros casos parecidos no arquivo.
O Debian também não remove sistematicamente arquivos gerados de todos os tarballs para recriá-los; especialmente em IA/ML, talvez nem seja possível obter os dados de treinamento, e o custo de treinar de novo também pode ser inviável.
https://wiki.debian.org/EmbeddedCopies
Algumas organizações de software open source não são apenas um pouco impressionantes; elas são surpreendentes a ponto de mostrar que, como forma de colaboração entre pessoas, podem ser muito superiores ao modelo corporativo típico.
Uso Debian há muito tempo, mas não conhecia bem a organização, e este texto foi uma boa introdução.
A IETF também é uma organização que praticamente criou a internet, mas não tem membros e simplesmente funciona; é surpreendente que organizações assim não sejam mais conhecidas.
Também são interessantes as Guerras de Protocolos, em que o mundo corporativo competiu com a IETF tentando controlar o modo como a internet funciona: https://en.wikipedia.org/wiki/Protocol_Wars
Houve uma época em que a OSI anunciava todo mês um projeto para substituir partes da internet, como o TCP, por protocolos X., mas o que sobreviveu e prosperou foi basicamente o X.509.
Fico pensando se essas organizações democráticas de colaboração são, na prática, muito superiores ao modelo corporativo tradicional.
Em termos de escala econômica, a receita da IETF ou do Debian não se compara à de empresas, mas, do ponto de vista de contribuidores e criadores, surge a pergunta: “quem se beneficia?” — e os contribuidores vão apenas se mantendo.
Parece valer a pena experimentar se modelos como os da IETF ou do Debian conseguem competir com o modelo corporativo; nas Guerras de Protocolos, isso de fato funcionou uma vez.
Nos grupos de trabalho da IETF há muitos engenheiros de fornecedores corporativos querendo colaborar por interoperabilidade, enquanto a ISO se parece mais com uma organização tradicional, verticalizada e liderada por governos.
Usei Ubuntu por uns 13 anos e migrei para Debian este ano; estou gostando bastante.
Antes, eu achava que o modelo de empacotamento com atualizações globais não era a abordagem tecnicamente mais sólida, porque era difícil saber o que estava acontecendo e às vezes surgiam conflitos de versões.
Mas, com o tempo, passei a valorizar muito a estabilidade do Debian e a boa-fé do projeto.
Às vezes, o propósito e os objetivos de um projeto importam mais do que a superioridade técnica.
Tenho reclamações sobre algumas escolhas técnicas, como a forma como daemons são iniciados automaticamente após a instalação, mas os benefícios da consistência geral dos pacotes e upgrades pesam mais.
O Apt também é um gerenciador de pacotes realmente excelente.
Ele é rápido mesmo no estado padrão e também dá suporte a cenários relativamente exigentes, como manter o sistema em stable e usar apenas o Nginx em uma versão mais nova vinda de backports.
Gosto da sensação de poder receber novos recursos apenas em um ou dois pacotes importantes, enquanto o resto permanece estável e tedioso.
O principal motivo é que ele usa tecnologia tediosa, antiga, mas que funciona bem, e não preciso mais ver netplan, snapd nem systemd-resolver.
A menos que você puxe coisas do Sid ou faça algo divertido como atualizar libc6, se tudo foi instalado via apt, conflitos de versão normalmente não deveriam aparecer.
LIW deixou de fora uma parte importante: o Debian é uma organização voluntária, então ninguém pode obrigar voluntários a fazer algo que eles não queiram fazer.
Pessoas não coagidas criam uma estrutura democrática frouxa e rotativa para tomar decisões, e a autossuficiência que vem do uso cuidadoso de recursos parece ser o núcleo da organização.
Para mim, esse conflito mudou permanentemente a ideia do que é o “Debian”, e se isso foi bom ou ruim depende de quem você ouve.
Mesmo nesse tipo de organização, se você não fizer o que outras pessoas mandam, naturalmente acaba sendo posto para fora.
Às vezes imagino ter uma fortuna tão grande que nunca mais precisaria me preocupar com dinheiro
Nesses momentos, sempre fico planejando para quais projetos open source eu doaria, e o Debian está sempre entre os primeiros candidatos
Agora só falta o dinheiro; claro, enquanto isso, continuo doando ao Debian
Seria bem mais divertido
O Debian pode ser excelente, mas tem problemas de suporte a drivers, e parece reconhecer isso apenas de forma passiva
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
“Reconhecemos que alguns usuários precisam de programas que não estejam em conformidade com as Debian Free Software Guidelines. Criamos áreas contrib e non-free no arquivo FTP para esse tipo de software.”
Há 1 ou 2 anos rodei Debian em algumas máquinas, mas uma atualização de WiFi chegou e tudo parou de funcionar; depois de olhar opções como rollback, simplesmente mudei para Ubuntu — na prática, Kubuntu — e funcionou bem, sem problemas
O Debian 12 chegou até a criar um repositório non-free-firmware dedicado, para que puristas do software livre pudessem abrir uma exceção apenas para drivers não livres necessários ao uso do hardware
Se o sistema já estiver instalado, ativar o repositório non-free e instalar linux-firmware, ou um pacote firmware-* mais específico para o hardware, deve resolver
Trabalhei com Ian Murdock em Purdue na época do primeiro lançamento
Ele era administrador de sistemas e desenvolvedor, e eu era web designer da biblioteca
Ele acreditava de verdade no jeito GNU/Linux e em software “livre como liberdade de expressão”
O impulso inicial veio da dificuldade de empacotamento e gerenciamento de pacotes, e talvez essa tenha sido sua maior contribuição
Ele também era entusiasmado com uma ideia parecida com uma infraestrutura P2P chamada Network-of-Workstations, ou NOW, mas ela nunca decolou de fato
Bruce Perens, a quem ele passou o bastão, é o líder autoritário mencionado no texto
Eu gosto dele; é um estilo de gestão da velha guarda, como o de Linus Torvalds, e esse estilo funciona em projetos grandes e complexos com muitos voluntários
A época antiga de Linux e Debian foi realmente divertida e, embora eu não tenha me envolvido tão profundamente quanto outras pessoas, sinto saudade daquele período
Hoje em dia entrou gente demais com cheiro de dinheiro, mas é assim que as coisas são
O manifesto do Ian explica tudo: https://www.debian.org/doc/manuals/project-history/manifesto...
Nunca ouvi essa história e o Google não ajuda
A trajetória dele depois de sair, até sua morte, parece bastante instável
É mais antigo do que eu
Debian é como a Toyota
Confiável, mas tedioso — e ainda por cima feito por voluntários
Por causa das políticas do Debian, às vezes é oferecida uma versão bastante limitada do RetroArch, em vez da versão real
O RetroArch tem um recurso próprio de gerenciamento de pacotes chamado “Core Updater”, que baixa e instala emuladores na forma de arquivos de biblioteca, mas o Debian o proíbe por considerar que isso contorna todo o sistema do gerenciador de pacotes
Ainda assim, se você instalar as dependências do pacote-fonte do Debian e depois compilar o código-fonte original, é possível compilar por conta própria um RetroArch com todos os recursos
Aprendi isso da forma difícil tentando rodar Kodi e RetroArch, mas, fora isso, é um ótimo sistema operacional
Pessoalmente, gosto do Debian e o uso por causa de seus princípios e de sua estabilidade
Já ouvi usuários de outras distribuições e alguns projetos upstream reclamarem que o Debian “modifica” os pacotes
Queria entender se isso é mesmo verdade e, se for, certamente deve haver bons motivos
Primeiro, patches que fazem o software se comportar da forma que o Debian espera: armazenar configurações em /etc/, não fazer downloads adicionais durante a execução e usar bibliotecas do sistema em vez de bibliotecas empacotadas junto com o programa
Segundo, backports de segurança
O Debian congela os recursos no momento do lançamento e fornece apenas atualizações de segurança, mas hoje muito software empacota correções de segurança junto com novos recursos em novos lançamentos
Quando esses dois tipos se combinam, a diferença entre o 1.2 do Debian e o 1.2 “de verdade” cresce, e fica difícil lidar com relatos de bugs
Por exemplo, recebe-se um relatório de bug do 1.2-Debian, mas o projeto upstream só dá suporte ao 1.4 “de verdade”, junto com um conjunto atualizado de bibliotecas
Terceiro, um método que hoje quase desapareceu: casos em que o Debian aplica patches por julgar que pode melhorar o software
Isso chegou a causar problemas como a remoção de aleatoriedade em chaves SSH: https://github.com/g0tmi1k/debian-ssh
Uma é o modelo de versões incrementais, como o Chrome, em que quase não há lançamentos separados só para correções de bugs, e as correções entram nas novas versões
A outra é um modelo centrado em versões principais, como no versionamento semântico: existem as versões 1 e 2, e, mesmo depois da versão 2, sai uma 1.1 contendo apenas correções de bugs para a versão 1
O Debian basicamente só funciona bem com o segundo modelo
Como mantém a estabilidade da API, ele não se encaixa bem com softwares desenvolvidos no primeiro modelo
Para contornar isso, o Debian faz backport das “correções” da versão 3 para a versão 1 e cria seu próprio 1.debian-2
O problema é que agora o projeto upstream passa a receber bugs sobre um comportamento que ele nunca lançou
O Debian tem a liberdade de fazer isso, mas o projeto upstream também tem a liberdade de reclamar da carga de trabalho extra que o Debian lhe impõe
Se necessário, aplica patches em projetos upstream que não atendem a essas expectativas, e a possibilidade de fazer exatamente isso é uma parte essencial do software livre
Basta ver https://www.debian.org/security/2008/dsa-1571