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.

A que tudo indica, o pombo correio mais querido do mundo do Software Livre deve suportar o envio e o recebimento de mensagens offline para a rede MSN dentro de pouco tempo. É isso que se pode concluir através do roadmap do projeto, a partir do item Activate MSNPv14, versão do protocolo MSN que implementa este recursos. Alguns mensageiros instantâneos como o Emesene já utilizam tal versão do protocolo e o tradicional Pidgin é retrógrado nesse sentido. Talvez se deva pela implementação ser considerada de baixa prioridade (minor) como consta nesta roadmap.

A conclusão pode ser tirada pelo número de tickets da implementação do MSNPv14 na plataforma Trac do Pidgin. Dos 4 tickets (= pendências) desta novidade, apenas um resta ser resolvido. Este ticket corresponde a incapacidade de se remover contatos após a fusão da nova versão do protocolo. Mas, não quero aqui lançar falsas esperanças: há quase 1 ano acompanho esse processo e pouquíssimas colaborações são feitas. Quando abordei developers do projeto tentando persuadí-los a dar mais atenção para a questão, as respostas mais delicadas que recebi foram ‘use Jabber‘. Bem, se apenas dizer isso bastasse, eu não teria mais contatos no MSN e não estaria preocupado com isso. Mas somente com amplas manifestações na lista de e-mail do projeto é que podem saltar aos olhos dos desenvolvedores a importância e a urgência de tal recurso. Portanto, convido todos a fazerem tais manifestações.

Essa situação depõe contra o Linux e outros sistemas operacionais livres. Já vi muitas pessoas debocharem do Linux dizendo algo como ‘ué, mas nem com mensagem offline o Linux é compatível ?‘. É um raro quesito em que Windows fanboys têm razão. Eu dependo do Pigdin por conta dos múltiplos protocolos, por isso não migro para o Emesene. Mas tenho que ter a irritante rotina de logar conta por conta que tenho do MSN no Emesene para ler as mensagens offline. Pelo menos, acho isso menos pior do que o uso de scraps do Orkut para recadinhos assíncronos. Como costumo dizer, scrapbook não é porta de geladeira.

foto por Dave Golden

Lembram-se da Novell que levou 30 dias para responder um e-mail de alguém querendo contratar seus serviços ? Menina má: não só a empresa me provocou enorme decepção e agora parece que tem buscado causar minha profunda irritação.

Poucas coisas na internet conseguem ser mais detestáveis que SPAM. Também, poucas coisas conseguem depor mais contra uma empresa como a prática do SPAM. Pois bem, eu tentei fazer um orçamento de uma solução em Software Livre da Novell e além de terem levado 30 dias para responder, agora passei a receber SPAM desta empresa.

Hoje em menos de 1h recebi dois e-mails não solicitados e enviados em massa da Novell, assinados por Ana Dos Santos (ADosSantos@novell.com) e Marcus Almeida (MALMEIDA@novell.com). Em ambos, oferecendo serviços de treinamento em administração de servidores SUSE e mais especificamente no primeiro, os preços variam de R$1.200,00 a R$3.600,00. Será que um treinamento desse nível e com esse preço depende de SPAM para fazer sucesso ? Duvido muito. Como disse antes, só depõe contra.

A senhora Ana dos Santos eu nunca tive contato na minha vida, nem sabia que existia. Mas o Marcus Almeida já fez um tardio mas educado contato comigo, relatado no meu post anterior. Mas o que me chama atenção no e-mail dele é o aviso de rodapé:

Importante: Esta mensagem deve ser lida e utilizada apenas pelo destinatário ao qual é enderecada e pode conter informacões confidenciais ou sob algum tipo de restricão de divulgacão sob as penas
da lei.

Confidentiality Notice: This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law.

Ou seja, não basta mandar SPAM, tem que ameaçar judicialmente caso o conteúdo seja publicado ? Essa cara-de-pau acho que nem empresas startups de fundo de quintal gerida por adolescentes têm.

Este post é uma resposta a outro post escrito por Oheremita em seu blog em julho deste ano. Nele, Oheremita nota algo que usualmente deixamos escapar: lembramos com detalhes de muitos filmes que já vimos, até os que não gostamos. Mas dificilmente lembramos do conteúdo que aprendemos na escola, as vezes, a até a matéria que foi vista essa semana. E conclui dizendo:

Hoje temos a “tecnologia”, efeitos especiais, podemos criar dinossauros como se fossem de verdade, naves espaciais, mundos imaginários, gerras cataclísmicas (…). Penso que se usarmos nossa capacidade e transformarmos nossa escola, de inspetora para orientadora, e a tecnologia das artes cênicas, mais notadamente o cinema, para ensinar aos nossos filhos, poderemos dar mais um passo rumo a uma civilização…

Realmente, hoje a escola parece mais inspecionar do que orientar. É que o mundo mudou muito mais rápido do que ela consegue entender e nesse descompasso quem mais perde é o professor e o aluno. Mas não foi a escola que, de repente, se tornou desinteressante. Foi o mundo que passou a ser muito mais interessante que a escola.

O professor hoje raramente dispõe mais do que 5 cores de giz para utilizar no quadro negro enquanto o aluno tem no bolso da calça um display LCD da ordem de milhões de cores acoplado em um celular repleto de jogos. Um mero prato de arroz, feijão e bife tem muito menos sabor do que os biscoitos ultravitaminados, hipercoloridos que explodem na boca, deixam a língua azul e ainda com direito a brinquedinho novo no final. Tanto os professores como os pais cairam numa luta desleal contra a parafernália atual que desvia a atenção de nossos jovens e os viciam. Vício ? Sim, vício por estímulo.

Veja como os sentidos da geração que hoje freqüenta a escola é bombardeada. No visual, quase tudo ou pisca ou brilha no escuro. Na audição, os mp3 players, os toques de celular, o surround na TV em casa. No tato os diversos tecidos, texturas, cama de mola, os infláveis, os emborrachados (e indestrutíveis). No paladar os biscoitos ultravitaminados, os refrigerantes, iogurtes. No olfato os perfumes, tanto as colônias para passar no corpo como também no cheiro artificial dos brinquedos. E raramente os sentidos são estimulados sozinhos: pense no quão forte é o gosto e o cheiro de um pacote de Cheetos, como são barulhentos e piscantes os brinquedos de camelô ou ainda os controles de videogame que tremem quando algo acontece na tela.

Nossos jovens são viciados em estímulos. Não me excluo disso: também sou. Estamos tão acostumado a ter nossos sentidos estimulados que poucas quantidades de estímulos são desinteressantes ou entediantes. É assim que o joguinho de celular é mais interessante que uma aula de Biologia. É assim que um pacote de Trakinas é mais interessante que o arroz e feijão.

Resta então uma dúvida cruel para a escola: como combater o desinteresse dos alunos ? Combatendo o vício dos estímulos, fazendo-os desacelerar o ritmo louco que vivemos hoje e tentando proporcionar a eles uma vida mais pacata (e até saudável) ou tornar o espaço da sala de aula também hiperestimulante para fisgar os alunos ? Me parece que a maioria tem optado por combater fogo com fogo: entrando na era do hiperestímulo.

Quem deslancha na ponta, como era de se esperar, é a rede privada não-tradicional. Cursos de inglês, por exemplo, já têm em redes inteiras datashow e computador em cada sala de aula, onde as aulas são ministradas com recursos multimídia do computador, permitindo interatividade sob o acompanhamento de um professor. Aos poucos também as escolas regulares estão entrando nessa onda, principalmente com a disseminação dos ‘Colégios e Cursos‘, pois, por terem uma cultura de pré-vestibular, trazem o perfil do professor showman, que usa microfone, que ensina coreografias, danças e músicas para fixação do conteúdo.

Qualquer que seja a abordagem, seja no desacelerar em busca de uma escola mais zen ou numa escola multimídia e jovem, a peça mais importante é o professor. Ele precisa ser capacitado para ambas abordagens e no caso da segunda, ela precisa ser feita com Software Livre.

Afinal, educação em tecnologia sem Software Livre não é educação: é adestramento. No máximo, treinamento. Uma escola que oferece uma formação para a atualidade não pode apenas tratar o computador como um o templo da dupla ‘Editor de texto e impressora‘. Da mesma forma como a escola tem que oferecer um letramento textual, permitindo que o aluno aprenda a ler, escrever, interpretar e se expressar, tem que também oferecer um letramento digital. Desmistificar a tecnologia, o funcionamento da internet, as novas relações humanas, financeiras e intelectuais estabelecidas através da internet e novos os paradigmas de propriedade intelectual. Por acaso existe algo melhor que Software Livre para fazer isso ? Acho que não

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

Faço um convite a toda comunidade que estiver no FISL 8.0 a assistir a minha apresentação (juntamente com o Leonardo Amaral e Daniervelin Renata) sobre o projeto TextoLivre – www.textolivre.org

Esse projeto oriundo da UFMG (com participação da USP e futuramente mais universidades), coloca o Software Livre nas atividades acadêmicas. É em essência um projeto de documentação onde as comunidades de distribuições Linux, outros sistemas ou Softwares Livres solicitam ao projeto Texto Livre que documentações, programas e outros materiais textuais sejam revisados, traduzidos ou testados pelos alunos ligados ao projeto. Estão atuando ou já atuaram no projeto alunos do curso de Letras, Biblioteconomia e Ciência da Computação, expansível a outros cursos também.

Se a sua distribuição favorita está carecendo de uma revisada na documentação ou seu software livre favorito não está apenas em português, o Texto Livre está oferecendo peopleware, mão-de-obra acadêmica para a produção destes textos com qualidade em Software Livre.

O projeto é uma via de mão dupla: é por a produção acadêmica a serviço da sociedade, a disposição do Software Livre e da inclusão digital como também capacitar os alunos engajados no projeto para o uso do Software Livre em suas pesquisas e cotidiano.

A palestra sobre o projeto será feita no dia 13/04, as 18h na sala Haskell dentro do evento. Para quem não estiver em Porto Alegre e participando do evento, haverá transmissão ao vivo pelo site da TV Software Livre. Recomendo muito a palestra a professores, funcionários e alunos de universidades que pretendem incluir o Software Livre nas atividades acadêmicas.

O portal Under-linux.org abraçou a causa do Texto Livre desde o início e tem sido o principal vetor de nossas publicações. Além da palestra, contaremos com um grupo de usuário no evento juntamente com o portal Under-linux. Receberemos todos os interessados para uma boa conversa e até firmar acordos de cooperação entre a comunidade acadêmica e a comunidade.

Espero vocês lá !

Abraços,

Kurt Kraut