Archive for April, 2007
FISL 8.0: The sourceforge.net: Open Source Infrastructure
Author: Cecilia Fernandes14 Apr
Numa palestra com o gerente geral do SourceForge, Ross Turk, aprendemos um pouco mais sobre o website criado em 1999 cuja meta é disponibilizar espaço para projetos opensource de todo o mundo.
Logo no início, tivemos uma noção da grandiosidade do site e soubemos que o Brasil é o sexto país com maior tráfego no SourceForge.
Na sequência, fizemos um passeio em alta velocidade pelas entranhas do website. Aprendemos que a chave do sucesso é a distribuição de serviços e de armazenagem em máquinas pequenas e médias - a verba pra equipamente não é tão grande assim.
O site utiliza PHP, MySQL, PostgreeSQL, Phyton, Apache Lucene, Hivemind, Nagios, etc. A filosofia é simples: se tem ferramentas para determinado fim e elas já são muito boas, não há porque re-inventar. “Não é bonito, mas é funcional,” disse Ross.
O sistema SourceForge pode não ter a beleza de um pré-estruturado e com partes próprias, mas é estável e roda em hardware mínimo.
Claro que há efeitos colaterais como a velocidade de buscas ser menor e conter partes altamente complexas e confusas, mas para serve bem para lidar com as partes operacional, empresarial, editorial e funcional. Lidando muito bem com hardware e recursos limitados e com as limitações de software.
Na seção de perguntas, Ross ainda afirmou que o SourceForge pretende, agora, se tornar mais atrativo para desenvolvedores, incluindo ferramentas tais como testes automatizados. O foco será em developer tools.
Posts Relacionados:
FISL 8.0: Wireless Meshing with OLPC
Author: Cecilia Fernandes14 Apr
Segue o resumo da palestra de ontem “Wireless Meshing with OLPC”. Para aqueles que não estão familiarizados com a sigla, vale explicar que OLPC é um dos laptops educacionais que competem nas licitações estaduais. O “One Laptop Per Child” XO é o modelo mais comentado e, temos que dizer, atrai a simpatia de qualquer um que passe por ele. Em uma breve ocasião, faremos uma notícia explicando as diferenças entre os concorrentes.
De volta à palestra, em densos 35 minutos, Javier Cardona comentou sobre a utilização de meshing nos OLPCs.
Mesh routing são protocolos de roteamento que funciona em redes parcialmente conexas de mesh. Isso sifnifica que um laptop liga a outro, que, por sua vez se liga a outro e assim se forma a rede - não precisam estar todos conversando com um central.
Esse protocolo tem as vantagens de ser auto-configurado e ser capaz de realizar “meta-reparos”, mas tem a desvantagem de ser visivelmente lento.
Atualmente, o projeto está em processo de rascunho e tem apenas uma pequena porção implementada.
Um OLPC conectado à internet se torna um Mesh Portal e disponibiliza internet para outros OLPCs em se range de alcance. Esses, se comunicam com a internet e com outros OLPCs que não estão na área de cobertura do Portal, que passam a disponibilizar de rede também e assim consecutivamente.
Até o momento, o OLPC com Wireless Meshing é capaz de descobrir caminhos que eventualmente o liguem à internet e escolher a melhor rota para transmitir informações com base na força da conexão. Em breve, ele levará em conta, também, a bateria disponível nos laptops no caminho. Ele é capaz de identificar de onde vêm os pedidos de informação e devolvê-las pro lugar certo - menos trivial do que parece.
No fim da palestra, ouve uma demonstração da rede em mesh usada pra enviar um sinal musical para outro. Três XOs foram usado na demonstração sobre área de cobertura. Um deles saiu da área de cobertura, enquanto os outros se mantiam lado a lado. Quando a música cessou, o segundo foi caminhando até a meia distância entre a fonte e o falante da música e pudemos ver a rede de mesh funcionando.
Após a grande sessão de aplausos, a palestra se encerrou.
Posts Relacionados:
FISL 8.0 Participando na Comunidade Mundial: A experiência real de desenvolvedores
Author: Cecilia Fernandes13 Apr
É realmente interessante quando o fato de a maior parte dos palestrantes terem faltado acrescenta tanto valor a uma discussão. Na ausência de Gilmar Souza, Vinícius e Yara Senger, o presente Bruno Souza reuniu uma equipe de figuras internacionais importantes para discutir como participar ativamente das comunidades opensource. Eia a lista dos participantes:
- Ross: gerente geral do SourceForge
- Roger: líder da Mobile Embeded Community
- Ray: Responsável pelo Open JDK
- Rick: Responsável pelo Open JDK
- Tom: Responsável pela portabilidade para Linux do JDK
- Simon: Responsável pelo Opensource Office da Sun
Seguindo uma introdução de Bruno, cada convidado teve seu tempo para expor sua resposta para a pergunta: “O que você precisa fazer para se envolver em projetos opensource?”
Ross sustentou que utilizar o SourceForge é uma excelente maneira de iniciar. É grátis, tem inúmeros projetos opensource à dispósição e é uma vitrine onde seus códigos ficam visíveis.
Roger e Ray se complementaram dizendo que, para participar, é preciso se inteirar do que acontece, participar em fóruns dando sugestões e, finalmente, desenvolvendo - ainda que começando do básico. É preciso conhecer e ser conhecido, eles dizem. Tom apenas concorda.
Simon não fugiu à tese, mas seus argumentos arrancaram aplausos da platéia. Segundo Simon, você é apaixonado por aquilo que te irrita. “Quando algo te irritar, não vire as costas e vá embora. Descubra soluções que resolvem o problema.”
Ross diz que você estude e tente e erre até conseguir encontrar as 3 linhas que debugavam um problema, mesmo que para isso você passe por 100.000 outras. Ajuda a entender o processo e a expandir conhecimentos em debug.
Numa discussão extremamente interessante e descontraída, os convidados aumentaram ainda mais a paixão dos ouvintes pelo software opensource e a vontade de trabalhar em projetos… principalmente os que te irritam!
Posts Relacionados:
FISL 8.0 - Infraestrutura de Sistemas Distribuídos (Google)
Author: Jonas Abreu13 Apr
A missão autoproclamada da Google todos já conhecem. “Organizar e tornar acessível toda a informação do mundo”. Mas como isso funciona de verdade? Nós também não sabemos, mas essa palestra ilustrou algumas das idéias por trás desse trabalho hercúleo. O GFS, MapReduce e BigTable.
O GFS, ou Google File System - Sistema de Arquivos da Google - é um sistema de arquivos de altíssima escalabilidade e com grande tolerância a falhas. mas porquê eles perderam tempo desenvolvendo um novo sistema de arquivos? Bom, as aplicações que eles rodam ultrapassam todos os limites normais de trabalho com dados. Normalmente você não tem que ordenar e indexar centenas de Terabytes de dados. Mas eles têm. Além disso, eles possuem milhões de consultas diárias a esses dados, precisando de uma grande banda para de leitura e gravação, além de grande confiabilidade. Mas como ele funciona? Basicamente, ele possui um servidor principal, que é para quem você envia a consulta. Esse servidor não possui os dados, mas ele possui informações sobre como esses dados estão espalhados em diversas outras máquinas (muitas vezes milhares de máquinas comuns como os PCs que temos em casa). A partir daí, este servidor lhe diz em que máquina você deve conectar e você recebe os dados. Ele também é inteligente o bastante para saber quando uma máquina “morre” (quebra) e uma nova deve ser “despertada” (ativada) para suprir a perda. Ele também coordena toda a inserção (ou remoção) de uma máquina e o sistema de replicamento de “chunks” (pedaços da informação) entre diversas máquinas (para evitar problemas com a “morte” de uma máquina).
MapReduce é a união de duas técnicas usadas em diversos sistemas da Google (como Busca, Ads, Froggle, Maps, Orkut, etc). A Map (que mapeia os dados de alguma forma) e a Reduce (que condensa os dados de alguma forma). Um exemplo é o indexador de páginas da Google, que pega cada página html e primeiramente aplica a Map, gerando uma espécie de frequência relativa das palavras no texto. Logo após, é aplicado o Reduce, que condensará essas frequências gerando o índice de páginas. Essa é apenas uma aplicação (das 1845 que usam o MapReduce). Além disso, MapReduce também é uma biblioteca que permite que o programador apenas construa as suas funções de Map e Reduce e não se preocupe em como que isso deve ser feito em um sistema distribuído como o GFS. Devido à grande utilização, em março de 2005, a Google já tinha usado 1 milênio de horas-máquina com operações de MapReduce.
BigTable, como o próprio nome já diz, é uma tabela grande. Mas como estamos falando da Google, é uma tabela gigantesca. Este é o banco de dados que a Google usa. Mas não pense que estamos falando de um banco de dados como o Oracle ou MySQL. A BigTable é bem mais simples e bem mais complicada. Ela é mais simples porque não precisa manter relacionamentos entre os dados, o que consome a maior parte do processamento em um banco de dados. Mas também é mais complicada pois foi desenvolvida para lidar com Terabytes de dados espalhados em milhares de máquinas. Ela é indexada atravéz de uma string qualquer (pode ser número, url ou qualquer outra coisa) e tem acesso direto à qualquer uma de suas posições (acesso assíncrono). Mas porque eles não usam um banco de dados já existente? Em parte por causa do custo, mas o maior motivo é que as aplicações deles são time-critical (tempo é um fator crítico). Ninguém quer esperar três segundos pela resposta de uma busca no Google. Se tivessem utilizado um banco de dados convensional, não seria possível fazer otimizações de baixo nível. Sem contar que “eles acham muito divertido implementar as coisas a partir do zero”. Outro suporte que a BigTable possui, é o timestamp, que permite que seus registros sejam associados de acordo com uma data e seja possível recuperar dados de datas antigas.
Posts Relacionados:
