Em seu blog, Ian Murdock, o fundador do Debian nos diz em ‘Como gerenciamento de pacotes mudou tudo‘ que:

Qual é o maior avanço que o Linux trouxe para a indústria ? Essa é uma pergunta interessante, e uma que na minha opinião tem uma resposta simples: Gerenciamento de pacote ou, mais especificamente, a capacidade de instalar e atualizar software através da rede de uma forma transparente, integrada e elegante, juntamente com o modelo distribuído de pacotes. (adaptado)

De fato, é um diferencial ímpar. Mas esta tecnologia do mundo GNU Linux está presa ao século passado. Os programas já compilados que instalamos nas nossas distribuições favoritas são produzidos em um processo artesanal que me remete as antigas linhas de montagem em que cada produto precisava ser manualmente embalado.

Divido aqui a comunidade de software livre em dois grandes tipos: aquela que desenvolve, que está engajada diretamente na produção de software, na programação dele. São projetos como OpenOffice, Gnome, Apache etc. Do outro lado, temos também as comunidades que distribuem esses softwares, que fazem as distribuições como Debian, Ubuntu, Fedora, ArchLinux etc. São grupos bem distintos com culturas bem distintas e integrados pela prática rococó do empacotamento.

Para efeito de conversa, pensemos no Apache, exemplo favorito de Sergio Amadeu. Quando o projeto Apache lança uma nova versão de seu software, ele lança apenas o código fonte. Cada usuário GNU Linux, para utilizá-lo, tem que baixar o código-fonte e prepará-lo para compilar. Tal tarefa não é uma das mais fáceis e exige tomada de decisão baseada em quesitos técnicos. Cada dependência, cada pedacinho que compõe o programa teria que ser separadamente baixado, compilado e configurado manualmente. Para ferramentas grandes como Gnome e KDE isso chega a levar dias. Por isso vou um pouco além de Murdock: eu diria que o GNU Linux seria insalubre se não fossem os sistemas de gerenciamento de pacotes. Tais sistemas permitem a mágica do único comando ou com um punhado de cliques, o Apache seja instalado já previamente compilado e pré-configurado para o uso mais comum.

Mas… como o pacote do Apache ou de qualquer outro software são gerados ? Eis o processo que me dá arrepios: assim que uma nova versão do software é lançada, um voluntário de cada distribuição GNU Linux existente tem que manualmente fazer o download da nova versão do programa, compilá-la, configurá-la e por tudo isso em um pacote, que por si só, o empacotamento não é um processo simples e como a compilação, exige um engajamento em questões técnicas profundas. De fato, é uma otimização. Uma pessoa faz o trabalho sujo uma vez para que as outras milhares possam queimar essas etapas demoradas e chatas.

- Oras Kurt, mas se é tão bom, do que estas reclamando ?

Bem, não posso dizer pelos outros, mas me sinto muito estúpido quando sou obrigado a fazer algo que uma máquina faria muito mais rápido e eficientemente do que eu. Se toda a internet funciona com máquinas independentes, sendo a intervenção humana resumida a alguns Homer Simpsons olhando LEDs piscarem, por que cada singelo software tem que ser manualmente baixado, compilado, configurado e empacotado ? É uma perda de material humano e de tempo.

De fato, a força do Software Livre está em sua construção colaborativa. Mas precisamos depositar força de trabalho naquilo que realmente demanda por um cérebro orgânico. Por que não criamos scripts e softwares que automaticamente criem pacotes para cada distribuição ? Por que precisamos depender de um voluntário para que tenhamos em nossa distribuição favorita um software ? Tal processo ineficiente gera distorções: algumas distribuições tem um pacote e outras não, algumas tem versões mas atuais outras com versões antiquérrimas. Se todos usamos GNU Linux, por que manter em um cenário tão desigual em termos de disponibilidade de software ?

Em vez de cada distribuição criar a cada lançamento de softwares um pacote para ele, basta cada distribuição criar uma única vez um script para empacotar o Apache e a cada nova versão deste software, o script detecta, baixa, compila, configura e põe no repositório devido (por exemplo, os testing ou development).

- Eu já pensei nisso, mas é algo difícil de se fazer…

É difícil porque cada comunidade de desenvolvimento adota padrões diferentes. Tal diversidade atrapalha a construção destes scripts e intrisicamente seu funcionamento. O que venho aqui neste artigo propor de novo é um Acordo de Cooperação Tecnológica (ACT). Se conseguirmos padronizar o modus operandi das comunidades que desenvolvem software livre e das que distribuem, esses scripts funcionariam com tranquilidade. Mas, jamais para criar um padrão único para todas as distribuições e sim acordos de duas partes envolvidas: uma distro e um software combinam um padrão para que o empacotamento possa ser realizado. É a criação de um acordo, uma promessa de se deter a um padrão e não criar um padrão único. Exemplificando: é combinar qual vai ser o uniforme de um colégio e não que todos os colégios do mundo tenham o mesmo uniforme.

Nesse acordo, os projetos de softwares livres que possuem comunidade sólidas, como os que eu mencionei ao longo deste artigo, entrariam em acordo de cooperação com os responsáveis das distribuições que os utiliza ou os distribuem automaticamente instalados (como é o caso do Gnome para Ubuntu) para estabelecer algumas regras, algumas guidelines para o lançamento de novas versões. Onde fica que o arquivo XPTO, como que é a estrutura de XYZ, onde se armazenará o metadata da descrição do programa etc… de forma que:

a) A comunidade que desenvolve o software se compromete a seguir certos padrões no lançamento de seu código fonte, estabelecidos em consenso interno e com as comunidades das distribuições.

b) Cada distribuição assinante do acordo se compromete em desenvolver e manter scripts que façam o empacotamento automático.

- E se o script em algum momento falhar ?

É aí que finalmente deve entrar a força de trabalho humana, lendo os logs do script para detectar o erro, e providenciar a correção dele junto a comunidade que desenvolve o software ou reparando o bug do script para que ele volte a ser autônomo. Também o acordo não iria engessar os desenvolvedores e arrastá-lo para padrões artificiais. Na verdade, ninguém precisa mudar de padrão. Apenas eles precisam ser estabelecidos, listados, fixados, para que os scripts possam ser construídos e funcionarem. Dessa forma, estaremos construindo toda uma cadeia produtiva de lançamento de software livre, caminhando para mais um salto evolutivo nos sistemas operacionais GNU Linux.

UPDATE: Tenho ciência que algumas distribuições mais voltadas para a compilação no ambiente do usuário (como Gentoo e ArchLinux) têm automações parecidas. Não estou aqui sugerindo um processo na relação entre o usuário e o processo de instalação de softwares e sim no processo de empacotamento que a maioria das distribuições Linux fazem entregando ao usuário binários já compilados em forma de pacotes que dependem de intervenção humana. Se observarmos os dados do Distrowatch retirados hoje, temos como distribuições mais populares:

1- PCLinuxOS – RPM
2- Ubuntu – DEB
3- OpenSUSE – RPM
4- Fedora – RPM
5- LinuxMint – DEB
6- Sabayon – Portage
7- Mandriva – RPM
8- Debian – DEB
9- Mepis – DEB
10- Damn Small Linux – DEB
11- CentOS – RPM

Excetuando o Sabayon, todos utilizam essa abordagem manual na criação de pacotes.

Enquanto a natureza não dá saltos, me parece que a internet vive dando os seus. E mais precisamente dois saltos: os de informação e de organização. Lá no início da década de 90, quando as conexões eram discadas e os sites tinham apenas umas duas imagens e fundo cinza, a internet começou a ser povoada em um salto por informações mas com uma grande dificuldade: só era possível acessar um site se você já soubesse o endereço dele. Surgiram então os primeiros catálogos de sites, onde os seus mantenedores declaravam sua existência aos organizadores do catálogo e sites como o brasileiro cade.com.br apareceram, construindo um salto de organização.

Até que de catálogo em catálogo, eram tantos que era difícil escolher por qual procurar. Outro revés era a raridade de se obter informações atualizadas, já que elas dependiam de uma ação ativa do mantenedor do site catalogado. Tivemos então o salto de informações nesses catálogos e tudo tornou a ficar mais confuso. Como cada salto de informação exige posteriormente um salto de organização, o salto subseqüente foi o advento dos web crawlers, os tais sites de busca que sozinhos varrem a internet em busca de dados e os organizam em uma página de resultados. Advento esse que atingiu seu ápice na atualidade com a multimilionária Google.

É possível aplicar essa lógica de saltos para as mais diversas áreas da internet. Mas, o que gostaria de tratar aqui hoje são os saltos dos downloads. De início, eram de forma centralizada: um determinado site hospedava arquivos de acordo com a escolha de seus criadores e disponibilizava os links para download. Dentre vários saltos, destaco o surgimento das redes P2P, que permitiram que qualquer internauta também distribuísse conteúdo, não apenas os detentores de sites na internet. Mas depois da febre e o desmonte do Napster, uma série de programas e redes de transferência de arquivos surgiram promovendo uma intensa fragmentação e desorganização. Numa mesma rede tínhamos várias cópias do mesmo arquivo, algumas com mais fontes para download, outras com menos… até algumas cópias falsas, com vírus e outras pragas.

Isso pedia por um salto de organização… e esse salto veio com os torrents. Agora ficou mais fácil dar validade e identificar um arquivo (ou o conjunto deles) para download. Com a troca do arquivo .torrent, que contém as informações sobre como localizar um arquivo para download, várias pessoas poderiam baixar com consciência e controle o mesmíssimo arquivo através da lógica P2P. Esse salto de organização, juntamente com a massificação da banda larga, eclodiu a troca de conteúdo multimídia na internet (muitas vezes de forma ilícita), o que rende até hoje lutas judiciais contra sites indexadores de torrents.

Mas os torrents já estão sofrendo um salto de informação. São inúmeros os sites para buscar torrents e já fica difícil dentre eles distinguir os arquivos em duplicata que nos interessam. Outro fator que vem a atrapalhar é a cada vez mais popular prática dos provedores de acesso à internet de diminuir a velocidade dos torrents, o que aparentemente já acontece no Brasil em algumas regiões atendidas pelo Virtua. Skavurzka !

Eis que os apresento um senhor salto de organização: o metalink. A lógica é bem parecida com o torrent: um arquivo bem pequeno que contém as informações sobre como baixar o(s) arquivo(s) desejado(s). Mas o prefixo ‘meta’ já denuncia: esse arquivinho agrega informações sobre como efetuar o download de um mesmo arquivo nas mais diversas fontes: HTTP, FTP, torrent (P2P) e ed2k (P2P). Ele reune as formas centralizadas e descentralizadas de transmissão de arquivos. É basicamente a reunião das outras formas existentes de download de arquivos numa só.

Imaginemos o download de uma ISO do Ubuntu. Este mesmíssimo arquivo com seus mais de 600MiB está em dezenas de mirrors HTTP e FTP pelo mundo, em redes do eMule/aMule e certamente em torrents. Através do metalink, você poderá receber pedacinhos desta ISO vinda de todas essas fontes, balanceando a carga entre elas e obviamente atingindo um maior teto de velocidade.

Já existem implementações do metalink para as plataformas Windows, Linux e Mac. Com destaque para o Windows, onde essa tecnologia foi aderida nos populares ‘gerenciadores de download’, como o GetRight e FlashGot. Os criadores do metalink solicitam ajuda dos usuários que gostarem da lógica do sistema para solicitarem aos desenvolvedores do Firefox, Opera, wget, cURL e até do Ubuntu para que incorporem o metalink em seus produtos e o utilize como meio de distribuição. De acordo com site metalinker.org, destes, apenas o wget já possui um planejamento para a compatibilidade com o metalink.

Falando em Ubuntu, na plataforma Launchpad já foi levantado o uso do metalink pela distribuição mas ainda falta um maior apoio da comunidade pela sua implementação. O que é bem simples, já que não há a necessidade de rodar alguma aplicação server-side como os trackers dos torrents pois o metalink utiliza os trackers já existentes no mundo para sua conectividade com a rede torrent.

Sites de downloads devem se beneficiar muito com esta tecnologia. João Pinto, desenvolvedor do site de downloads de programas para Ubuntu getdeb.net me revelou hoje que planeja, no futuro, oferecer o metalink como forma de download dos programas disponibilizados no site. Os cerca de 100GiB trafegados por dia atualmente no site são dividos entre 4 mirrors de grupos de apoio ao Software Livre. Com o metalink, os usuários que fazem os downloads poderiam contribuir cedendo sua banda para upload, equilibrando a equação.

Alguns sistemas operacionais livres já estão sendo distribuídos de forma oficial ou não oficial por metalinks, como Linux Mint, OpenSUSE, TrueBSD, GoboLinux, PC-BSD e a lista segue. Sugiro que atendamos ao pedido do pessoal do metalink e comecemos a divulgar em nossas comunidades o uso dessa ferramenta.

Abraços,

Kurt Kraut

Ó ceus, será que apenas eu gosto do look laranja-cítrico do Ubuntu ? Todo screenshot de um desktop em uso que vejo por aí fazem questão de depenar o Ubuntu Vitamina C em tons de cinza e azul, arght. Parece uma Síndrome de Henry Ford: ‘Você terá o sistema da cor que quiser, contanto que ele seja azul‘.

Parabéns ao pessoal do Debian-BR-CDD pelo verde-esperança.