Como várias pessoas estava solicitando auxílio para utilização do Ruby Bandwidth Monitor (RBM) e também eu estava fazendo várias alterações nele, agora que está em um estágio um pouco mais usável e com alguns recursos, vou descrever o método de instalação do Ruby e Libpcap-Ruby e onde alterar o código-fonte do rbm.rb para informar os parâmetros (que ainda não consigo enviar por linha de comando).
Tenho utilizado o RBM, constantemente, em sistemas Debian, tanto Etch (stable) como Lenny (testing), com Ruby1.8 e Libpcap-Ruby1.8, para instalá-los faça o seguinte, como root:
#apt-get install ruby1.8 libpcap-ruby1.8
Antes de iniciar, o RBM é utilizado em computadores que servem como roteadores de uma rede, fazendo NAT da rede interna para acesso a uma rede externa como a internet. Em todas as minhas configurações, sempre tenho a eth0 como dispositivo conectado à internet e eth1 para a rede interna.
Feito isto o sistema já estará pronto para rodar o RBM, para baixar o código-fonte, vá em http://www.katyphotoart.com/ruby/rbm.rb e para visualizar o codigo-fonte com a sintaxe colorida vá em http://www.katyphotoart.com/ruby/rbm.rb.html, portanto wget nele:
$wget http://www.katyphotoart.com/ruby/ruby.rb
Edite o arquivo e altere as variáveis globais que estão definidas a partir da linha 24 até a linha 29, onde explico a função de cada uma:
* $gateway_ip: o número de ip atribuído à interface que comunica-se com a rede interna, ou seja, o ip do gateway dos clientes.
* $device: dispositivo (eth0, eth1, etc) que comunica-se com a rede interna. Em uma próxima versão vai ser necessário informar só o dispositivo que o RBM será capaz de obter o $gateway_ip
* $sort_by: como explicado no código-fonte, indica por qual dos campos será classificado o resultado, ip (ou nome de máquina), traffic_in ou traffic_ou (para tráfegos de download ou upload), packets_in ou packets_out (para número de pacotes de download ou upload). Colocando um "-" (hífen) antes do parâmetro, a ordem de classificação será descendente, exemplo, "-ip".
* $refresh: o tempo em segundos para acúmulo e exibição dos resultados.
* $pcapoptions: para adicionar argumentos extras à biblioteca libpcap (responsável pela captura de pacotes), no estilo tcpdump. Digamos que eu queira obter somente o tráfego do cliente com ip 192.168.1.20, $pcapoptions terá como valor "host 192.168.1.20". Surigo a leitura do manpage do tcpdump para maiores detalhes.
* $nameshow: permite mostrar nome de máquina (obtida através do arquivo /etc/hosts) em detrimento ao número ip. Para tanto, defina o valor desta variável como "hostname", qualquer outro valor significa que deve ser exibido o número ip. (Em uma versão futura pretendo utilizar chamadas ao dns para conversão de nomes se isto mostrar-se realmente útil)
Feitas as alterações no código-fonte, basta rodar o programa, como root (pois é necessário para que a interface seja posta em modo promíscuo pela biblioteca libpcap):
#ruby1.8 rbm.rb
Para cancelar a execução do programa tecle a combinação CTRL+C.
Logo em seguida vou seguir a sugestão do keynes (eu acho) e permitir a exibição de "10.0.0.30" (exemplo), ao invés de "010.000.000.030" como acontece agora.
Era isto pessoal, qualquer dúvida é só perguntar
quinta-feira, 31 de janeiro de 2008
quarta-feira, 30 de janeiro de 2008
Ruby Bandwidth Monitor versão 0.02
Boa tarde gente!
Corrigi a atribuição do endereço mac para os clientes que estava errado, acrescentei a possibilidade de fazer resolução de nomes com base no arquivo /etc/hosts, para isto basta que se edite o código fonte e seja alterado o valor da variável global @nameshow para "hostname".
Era isto por enquanto. Como de costume o código está em http://www.katyphotoart.com/ruby/rbm.rb.html
Abraços
Corrigi a atribuição do endereço mac para os clientes que estava errado, acrescentei a possibilidade de fazer resolução de nomes com base no arquivo /etc/hosts, para isto basta que se edite o código fonte e seja alterado o valor da variável global @nameshow para "hostname".
Era isto por enquanto. Como de costume o código está em http://www.katyphotoart.com/ruby/rbm.rb.html
Abraços
terça-feira, 29 de janeiro de 2008
Argumentos em linha de comand e pcaplet (para captura de pacotes)
Estou voltando ao problema relatado anteriormente com o intuito de alguma alma me ajudar nesta questão. Perdi mais de uma hora eu acho para descobrir, a duras penas, que não posso fazer captura de pacotes com o pcaplet quando envio argumentos por linha de comando. Explicando melhor, considerem o código abaixo em um arquivo de nome cap.rb:
01 #!/usr/bin/env ruby
02 require 'pcaplet'
03 cap = Pcaplet.new("-i eth0 -s 128")
04 filter = Pcap::Filter.new('ip', cap.capture)
05 cap.add_filter(filter)
06 cap.close
Se simpleste eu rodá-lo com "ruby1.8 cap.rb" beleza, não é gerado nenhum erro, mas se eu rodo-o assim "ruby1.8 cap.rb argumento", simplesmente o programa para a execução na linha 03 e retorna a mensagem de erro "setfilter: syntax error".
Estava precisando enviar parâmetros por linha de comando para facilitar a vida de quem precisa enviar parâmetros à uma aplicação.
Assim que eu conseguir algum progresso neste sentido posto aqui, senão fico aguardando a sugestão de quem quiser me ajudar.
01 #!/usr/bin/env ruby
02 require 'pcaplet'
03 cap = Pcaplet.new("-i eth0 -s 128")
04 filter = Pcap::Filter.new('ip', cap.capture)
05 cap.add_filter(filter)
06 cap.close
Se simpleste eu rodá-lo com "ruby1.8 cap.rb" beleza, não é gerado nenhum erro, mas se eu rodo-o assim "ruby1.8 cap.rb argumento", simplesmente o programa para a execução na linha 03 e retorna a mensagem de erro "setfilter: syntax error".
Estava precisando enviar parâmetros por linha de comando para facilitar a vida de quem precisa enviar parâmetros à uma aplicação.
Assim que eu conseguir algum progresso neste sentido posto aqui, senão fico aguardando a sugestão de quem quiser me ajudar.
Mais de 80% dos meus leitores usam Firefox
Tive que voltar pra dar esta boa-nova a vocês. Conforme o relatório do Google Analytics, meu leitores usam:
* 80,14% Firefox
* 11,42% IE
* 5,59% Mozilla
* 1,48% Opera
* 0,57% Safari
Se somarmos os 80,14 com 5,59, são quase 86% de usuário do Mozilla Firefox. Viva o software livre e de código aberto.
Até logo
Atualização do utilitário para controle de banda e novo nome
Buenas gente, tive um tempo vago hoje e fiz algumas atualizações no utilitário pra controle de banda, seguindo algumas sugestões que me passaram por comentário. A primeira atualização acho que foi quanto ao nome, agora passa a se chamar Ruby Bandwidth Monitor (RBM) e as demais:
* Paginação dos resultados
* Classificação em ordem ascendente e descendente por todos os campos
* Parâmetros informados no início do arquivo rbm.rc (notas a seguir)
* Somatórios
Não consegui de maneira alguma passar argumentos através da linha de comando e processar com ARGV sem receber a mensagem de erro "setfilter: parse error" na linha "cap = Pcaplet.new("-i #{$device} -s 128")" e este erro só ocorre porque tento passar argumentos pela linha de comando, então, por enquanto, tive que manter os parâmetros no código-fonte mesmo e são eles:
* $device: nome do dispositivo de rede a ser monitorado. Ex: eth0, eth1
* $gateway_ip: número ip da interface que será monitorada, em uma próxima versão vou tentar obter este número automaticamente, através do dispositivo informado
* $sort_by: pode ser ip,mac,traffic_in,traffic_out,packets_in e packets_out para classificação em ordem ascendente e com o ascréscimento de um "-" (hífen) logo antes (ex: "-ip") para classificação em ordem descendente
* $refresh: tempo em segundos para atualização dos resultados
Basicamente utilizo, Debian i486, Ruby 1.8, libpcap-ruby1.8 e tenho instalado em meu sistema a biblioteca libpcap0.8.
Quanto à biblioteca libpcap-ruby para CentoOS fico devendo por enquanto, mas vou procurar algum sistema RedHat pra testar.
Quanto ao iptraf, tenho usado ele seguidamente, o único problema é que ele não totaliza o tráfego por ip e quanto ao MRTG, realmente seria a solução ideal, mas eu quis iniciar este projeto com dois propósito, aprender um pouco de Ruby e ter um utilitário simples, que não demandasse muitas configurações e fosse bem direto ao assunto. Realmente não saberia como fazer para o MRTG me oferecer as mesmas informações que propus com o RBC, assim, tão simples e rápido.
Obrigado a todos pelos comentários, sugestões e críticas, o próximo passo acredito que seja fazer resolução de nomes para quem desejar assim (e eu desejo :-)).
Código-fonte em: http://www.katyphotoart.com/ruby/rbm.rb.html
Até logo
[]'s
* Paginação dos resultados
* Classificação em ordem ascendente e descendente por todos os campos
* Parâmetros informados no início do arquivo rbm.rc (notas a seguir)
* Somatórios
Não consegui de maneira alguma passar argumentos através da linha de comando e processar com ARGV sem receber a mensagem de erro "setfilter: parse error" na linha "cap = Pcaplet.new("-i #{$device} -s 128")" e este erro só ocorre porque tento passar argumentos pela linha de comando, então, por enquanto, tive que manter os parâmetros no código-fonte mesmo e são eles:
* $device: nome do dispositivo de rede a ser monitorado. Ex: eth0, eth1
* $gateway_ip: número ip da interface que será monitorada, em uma próxima versão vou tentar obter este número automaticamente, através do dispositivo informado
* $sort_by: pode ser ip,mac,traffic_in,traffic_out,packets_in e packets_out para classificação em ordem ascendente e com o ascréscimento de um "-" (hífen) logo antes (ex: "-ip") para classificação em ordem descendente
* $refresh: tempo em segundos para atualização dos resultados
Basicamente utilizo, Debian i486, Ruby 1.8, libpcap-ruby1.8 e tenho instalado em meu sistema a biblioteca libpcap0.8.
Quanto à biblioteca libpcap-ruby para CentoOS fico devendo por enquanto, mas vou procurar algum sistema RedHat pra testar.
Quanto ao iptraf, tenho usado ele seguidamente, o único problema é que ele não totaliza o tráfego por ip e quanto ao MRTG, realmente seria a solução ideal, mas eu quis iniciar este projeto com dois propósito, aprender um pouco de Ruby e ter um utilitário simples, que não demandasse muitas configurações e fosse bem direto ao assunto. Realmente não saberia como fazer para o MRTG me oferecer as mesmas informações que propus com o RBC, assim, tão simples e rápido.
Obrigado a todos pelos comentários, sugestões e críticas, o próximo passo acredito que seja fazer resolução de nomes para quem desejar assim (e eu desejo :-)).
Código-fonte em: http://www.katyphotoart.com/ruby/rbm.rb.html
Até logo
[]'s
domingo, 27 de janeiro de 2008
Ruby: Utilitário para verificação de controle de banda
Várias vezes procurei por algum utilitário que me auxiliasse na verificação do controle de banda do meu roteador. Precisava de algo que mostrasse o consumo de banda tanto de entrada quanto de saída de cada cliente (download e upload). Como utilizo o htb-tools este tem o htb ethX stats que, para mim, era quase perfeito, a não ser por não mostrar a taxa de transferência de saída.
Como estou interessado no aprendizado de Ruby, decidi aventurar-me em criar um utilitário com as características que precisava.
Outrora pesquisei como utilizar a biblioteca pcap com Java, mas desanimei-me logo em seguida nem lembro porque e descontinuei o projeto que nem havia iniciado. A uns dois dias atrás, deparei-me com um artigo da Linux Magazine que mostrava a utilização da biblioteca Pcap através do Perl para fazer uma espécie de log de utilização de banda por cliente e resolvi procurar se não havia a disponibilização de algum bind de pcap para Ruby. Gratamente fui surpreso que existia e meti a mão na massa.
Estou apanhando um monte, pois se nem sei direito como programar em Ruby, nunca antes havia brincado com pcap, a não ser algumas poucas vezes, indiretamente com tcpdump.
Gostaria só de compartilhar com quem esteja interessado, esta minha primeira versão "pré-alfabeto" e tentarei melhorá-lo com o tempo, pois ainda tenho que alterar o fonte para mudar alguns parâmetros e tenho utilizado algumas técnicas que devem causar calafrios na maioria dos bons programadores.
Ainda não pude colocar o htb-gen em ação, mas este utilitário vai ser muito interessante para monitorar as taxas de transferências dos meus clientes.
Apelidei-o de Ruby Bandwidth Control
Abraços a todos.
Como estou interessado no aprendizado de Ruby, decidi aventurar-me em criar um utilitário com as características que precisava.
Outrora pesquisei como utilizar a biblioteca pcap com Java, mas desanimei-me logo em seguida nem lembro porque e descontinuei o projeto que nem havia iniciado. A uns dois dias atrás, deparei-me com um artigo da Linux Magazine que mostrava a utilização da biblioteca Pcap através do Perl para fazer uma espécie de log de utilização de banda por cliente e resolvi procurar se não havia a disponibilização de algum bind de pcap para Ruby. Gratamente fui surpreso que existia e meti a mão na massa.
Estou apanhando um monte, pois se nem sei direito como programar em Ruby, nunca antes havia brincado com pcap, a não ser algumas poucas vezes, indiretamente com tcpdump.
Gostaria só de compartilhar com quem esteja interessado, esta minha primeira versão "pré-alfabeto" e tentarei melhorá-lo com o tempo, pois ainda tenho que alterar o fonte para mudar alguns parâmetros e tenho utilizado algumas técnicas que devem causar calafrios na maioria dos bons programadores.
Ainda não pude colocar o htb-gen em ação, mas este utilitário vai ser muito interessante para monitorar as taxas de transferências dos meus clientes.
Apelidei-o de Ruby Bandwidth Control
Abraços a todos.
quinta-feira, 24 de janeiro de 2008
Controle de banda para provedor wireless com pouco link para upload
Olha que suamos a camiseta e mesmo assim eu ainda não estou com plena confiança de que está bom. Como sugeria professor de Teoria Geral de Administração, a Administração trata da forma como se gerencia/controla recursos finitos, pois para recursos infinitos não precisamos de gerenciamento/controle.
Pois bem, para download temos bastante banda, não quer dizer que não precisemos de Administração para ela, mas não estamos em um estado tão crítico, mas para upload a coisa está um tanto mais complicada.
Tenho usado htb para Administração de banda desde o princípio (mas a história de como iniciamos o projeto do provedor vai ficar para outros posts), auxiliado pelo htb-tools. Conseguir afinar o arquivo de configuração do htb-tools que será a base para a geração das regras "tc" não parecia tão complicado a princípio, pois claro até então os recursos eram como se fossem quase infinitos, mas agora temos uma grande carteira de clientes e meu upload está me dando trabalho. Se fosse simplesmente atribuir 24kbps para cada cliente e que o htb se virasse com o resto seria o ideal, mas como o htb vai saber qual a melhor de atribuir burst? Como EU vou saber o que isto, burst, significa e como funciona?
A resposta é que não sei e ainda vou continuar pesquisando a este respeito para poder afinar ainda mais minhas configurações e conseguir realmente oferecer serviços de ótima qualidade.
Só escrevi isto tudo aqui porque vai que aparece alguma alma caridosa que já tenha passado por isto e tenha como auxiliar-me nesta demanda. Encontrei o projeto htb-gen e pretendo experimentá-lo a semana que vem.
Abraços a todos.
Pois bem, para download temos bastante banda, não quer dizer que não precisemos de Administração para ela, mas não estamos em um estado tão crítico, mas para upload a coisa está um tanto mais complicada.
Tenho usado htb para Administração de banda desde o princípio (mas a história de como iniciamos o projeto do provedor vai ficar para outros posts), auxiliado pelo htb-tools. Conseguir afinar o arquivo de configuração do htb-tools que será a base para a geração das regras "tc" não parecia tão complicado a princípio, pois claro até então os recursos eram como se fossem quase infinitos, mas agora temos uma grande carteira de clientes e meu upload está me dando trabalho. Se fosse simplesmente atribuir 24kbps para cada cliente e que o htb se virasse com o resto seria o ideal, mas como o htb vai saber qual a melhor de atribuir burst? Como EU vou saber o que isto, burst, significa e como funciona?
A resposta é que não sei e ainda vou continuar pesquisando a este respeito para poder afinar ainda mais minhas configurações e conseguir realmente oferecer serviços de ótima qualidade.
Só escrevi isto tudo aqui porque vai que aparece alguma alma caridosa que já tenha passado por isto e tenha como auxiliar-me nesta demanda. Encontrei o projeto htb-gen e pretendo experimentá-lo a semana que vem.
Abraços a todos.
Os sentidos para uma compreensão do mundo
E se desconsiderássemos nossos sensores como visão, olfato e audição seríamos ainda capazes de compreender o mundo?
Cada pessoa tem um mundo para si. Suas percepções ao longo do tempo e do presente lhe dá a noção de mundo. Sendo assim cada pessoa tem um mundo diferente, "vê" o mundo de forma diferente. Realmente eu acredito nisto.
O interessante é que jamais poderemos crer que conseguiremos compreender plenamente qualquer um de nossos semelhantes. Qualquer pequena diferença de compreensão, de um detalhe que seja, pode fazer uma diferença enorme no final da cadeia de pensamentos e conclusões.
Mas o mais incrível é que mesmo assim pensamos parecidos quando fazemos parte de uma mesma cultura, religião, partido político ou ideologia qualquer. Estas "orientações" conseguem milagrosamente, com uma receita simples, domesticar nossos cérebros e direcioná-los a um fim comum. Certamente que não haverá pensamentos e conclusões iguais, mas a grosso modo podemos dizer que pensamos parecidos.
Então o que une as pessoas se elas sabem (ou acho que deveriam saber), que ninguém a compreenderá plenamente? Acredito que está em primeiro lugar o amor. É o amor que me faz acreditar que serei feliz para sempre com minha noiva quando casarmos, pois embora pensemos diferente em alguns pontos, ou melhor em muitos pontos e às vezes bem diferente, é a certeza de que ela me complementa e que basta que nos aceitemos e nos entreguemos um para o outro e seremos felizes.
E porque pessoas de diversos partidos, religiões, culturas, etnias se unem todo ano em Porto Alegre para festejar, antes de tudo, o software livre e de código aberto? Acredito que seja porque há o "amor" ou um sentimentos grandioso que nos faz acreditar que esta forma de se posicionar no mundo nos faz e nos fará felizes.
Que Deus nos direcione, cada vez mais para um mundo maravilhoso, livre e feliz, onde possamos fazer as diferenças não se tornarem oposição à construção de nosso paraíso e que o amor, ah! belo e doce amor, esteja sempre presente nos corações dos que querem se apaixonar.
Katy TE AMO, porque somos diferentes, mas temos em comum, o amor um pelo outro.
Cada pessoa tem um mundo para si. Suas percepções ao longo do tempo e do presente lhe dá a noção de mundo. Sendo assim cada pessoa tem um mundo diferente, "vê" o mundo de forma diferente. Realmente eu acredito nisto.
O interessante é que jamais poderemos crer que conseguiremos compreender plenamente qualquer um de nossos semelhantes. Qualquer pequena diferença de compreensão, de um detalhe que seja, pode fazer uma diferença enorme no final da cadeia de pensamentos e conclusões.
Mas o mais incrível é que mesmo assim pensamos parecidos quando fazemos parte de uma mesma cultura, religião, partido político ou ideologia qualquer. Estas "orientações" conseguem milagrosamente, com uma receita simples, domesticar nossos cérebros e direcioná-los a um fim comum. Certamente que não haverá pensamentos e conclusões iguais, mas a grosso modo podemos dizer que pensamos parecidos.
Então o que une as pessoas se elas sabem (ou acho que deveriam saber), que ninguém a compreenderá plenamente? Acredito que está em primeiro lugar o amor. É o amor que me faz acreditar que serei feliz para sempre com minha noiva quando casarmos, pois embora pensemos diferente em alguns pontos, ou melhor em muitos pontos e às vezes bem diferente, é a certeza de que ela me complementa e que basta que nos aceitemos e nos entreguemos um para o outro e seremos felizes.
E porque pessoas de diversos partidos, religiões, culturas, etnias se unem todo ano em Porto Alegre para festejar, antes de tudo, o software livre e de código aberto? Acredito que seja porque há o "amor" ou um sentimentos grandioso que nos faz acreditar que esta forma de se posicionar no mundo nos faz e nos fará felizes.
Que Deus nos direcione, cada vez mais para um mundo maravilhoso, livre e feliz, onde possamos fazer as diferenças não se tornarem oposição à construção de nosso paraíso e que o amor, ah! belo e doce amor, esteja sempre presente nos corações dos que querem se apaixonar.
Katy TE AMO, porque somos diferentes, mas temos em comum, o amor um pelo outro.
quinta-feira, 17 de janeiro de 2008
Que caminho seguir? Java, C++, Python ou Ruby
Esta eterna questão me toma, não consigo chegar à decisão. Quanto a Java pretendo continuar estudando-a e é certo que logo em seguida, assim que chegar meu notebook, devo iniciar um projeto J2EE pra consumo próprio. Vou utilizar, certamente, o framework MVC do ilustríssimo Sérgio, o Mentawai, que já citei anteriormente nas postagens referente ao meu TCC. Quanto à persistência ainda não defini, bom, mas vou deixar estes detalhes pra mais tarde, quando realmente iniciar o projeto.
Sempre tive muita vontade de ser um programador C, tanto é que muitas e muitas vezes implementei pequenos programinhas em C, nada avançado, mas só para poder dizer que sabia programar em C. Estou achando muito interessante o KDE4, embora eu seja, atualmente, usuário Gnome, mas não posso deixar de admitir que sempre admirei o KDE e o QT (depois que a Trolltech passou a disponibilizá-lo, também, sob GPL). Se o tempo me permitir, tentarei iniciar alguns estudos, sem muita ambição, em C++ e quero utilizar o Kdevelop, o tutorial do Antonio Larrosa (http://developer.kde.org/~larrosa/tutorial.html) e este (http://www.beginning-kdevelop-programming.co.uk/) do Andrew Ward.Por fim, ainda paira a indecisão sobre começar os estudos em Python ou em Ruby, a inclinação está, atualmente, para o lado do Ruby por causa do Rails.
Gostaria mesmo de saber que vantagens teria o Python sobre o Ruby, pois se, afinal, eu não encontrar nenhuma, acredito que definitivamente Python não será minha opção como linguagem de "altíssimo nível".
terça-feira, 15 de janeiro de 2008
2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 005
Vou tentar segui uma sugestão anônima para criação de frases mais curtas de agora em diante. Quem sabe assim, meus textos possam ser melhores compreendidos. Bom, mas se nem eu mesmo, às vezes, me entendo, como fazer meus leitores compreenderem-me plenamente? (Adorei a expressão "meus leitores"). ;-)
Até que enfim eu tinha conseguido superar o problemão de "adormecimento" esporádico do cluster e agora ele funcionava "a mil". Ainda havia um detalhe que não consegui resolver até o final do trabalho e vou relatá-lo resumidamente (a minha moda) para que, quem sabe, alguém possa me dizer o que estava havendo.
Um computador cliente, em uma sessão de testes, fazendo requisições por, digamos 10 minutos, nunca conseguia fazer com que o cluster (nos primeiros testes somente um computador, o primário), chegasse próximo a 100% de uso da CPU. E não era porque o cliente era fraco, pois normalmente não exigia mais de 30% de CPU do cliente neste tipo de teste, enquanto que o cluster não chegava a 80%. Cheguei até a tentar virtualização com Xen para fazer com que um computador rodasse várias instâncias servidoras tentando obter o máximo de sua performance, mas não adiantou em nada. Para ilustrar mais um pouco e tentarem compreender o problema, se eu utilizasse 2 computadores clientes, cada um ocuparia no máximo 20% de sua CPU (média) durante 10 minutos de teste e o cluster, então, passava de 80%. Se no teste fosse utilizado 3 computadores clientes, cada um também usava em média 20% da CPU, mas então o cluster já era carregado a mais de 90%. Nunca entendi isto, procurei razões, gargalos de rede ou de entrada/saída, mas não encontrei.
Estava na responsabilidade de conseguir computadores clientes, para meu cluster de 3 nós, que fossem capazes de "sugar" o máximo de sua capacidade e graças a Deus consegui isto para praticamente todos os meus teste, só um, entre diversas configurações de teste é que não consegui obter, com 3 computadores clientes, 100% de uso da CPU do cluster na configuração de 3 nós.
Até agora ainda Java parece algo pouco irrelevante para o Trabalho de Conclusão, mas lá por maio ele tornou-se peça fundamental. Como nesta época eu já tinha o cluster funcionando (até tive que refazê-lo logo após usar xen, pois consegui destruir com todos os arquivos de configuração do primário), e estava sobrando tempo para algo a mais.
Foi aí que meu orientador de TCC, Alexandre Timm, fez-me aceitar que o mais importante do meu TCC não era o cluster e sim as ferramentas para medição de performance que eu tinha iniciado como um instrumento simples para poder comparar os resultados em diversos tipos de configuração do cluster: 1 nós, 2 nós, 3 nós, entre outros detalhes, para apurar se realmente um cluster obteria alguma vantagem em relação a um computador só.
Que ótimo que este modelo de cluster trazia bons resultados, imagina se eu tivesse perdido meses pesquisando e iniciado o projeto, comprado computadores para verificar que não servia pra melhorar a performance, no máximo para alta disponibilidade, eu teria ficado muito decepcionado.
Era incrível, pois o cluster já tinha failover e failback funcionando. Era desligar o primário "na marra" que o secundário assumia suas funcões, a base de dados postgresql não ficava comprometida e somente a performance é que ficava diminuída. Colocava o primário no ar e este reassumia suas funções, atualizando em disco tudo aquilo que estava desatualizado (somente a partição da base de dados, que era a única coisa realmente mutante do cluster) era automagicamente atualizada e o cluster retomava sua capacidade máxima. Inclusive se um nó parasse de funcionar, o cluster reconhecia e se regulava.
Voltando ao Java, passei então a aprimorar todos os componentes que estava utilizando, separando-os e melhorando a troca de informações entre eles. Eu tinha então:
Aprendi muito sobre Java, tive que usar extensivamente Thread (algo que era totalmente obscuro pra mim), e confirmei que Java é uma ótima plataforma, mesmo em intensa carga jamais "arriou", no máximo apresentou problemas que eu custei muito a saber o que era, hehehe, mas por causa de um módulo de memória que pifou e fazia a aplicação web (na verdade o tomcat), simplesmente sumir da memória.
Estava na transição entre Java 5 e Java 6, e mesmo sendo beta, utilizei Java 6 em praticamente todo o trabalho.
Algo muito engraçado que ocorria era que em testes, distante do meu laboratório, um Athlon 64 3000+ com Debian Sarge, podia processar algo como 30% a mais de requisições que um Athlon 64 3500+ com Windows XP. Este Athlon 64 3000+ era o servidor (ainda é), de banco de dados da prefeitura e o Athlon 64 3500+ era o notebook do meu colega que jamais teve intenção de se ligar ao mundo livre e simplesmente ignorava-o por não lhe fornecer as ferramentas que ele precisava. Então, por causa disto, muitas e muitas vezes "arriava-me" nele por um "simples" Athlon 64 3000+ sem bem mais poderoso, com Linux, que seu ínfimo Athlon 3500+ com ruindous.
Chegou o dia da apresentação do TCC para a banca e era, basicamente, demonstrar como fôra todo o planejamento e construção do cluster, bem como das ferramentas para medição de performance que tinham se tornado tão ou mais importante que o próprio cluster para o escopo do trabalho. Sempre tive muita dificuldade para falar em público, imagina na defesa do TCC!
Minha namorada (na época, hoje noiva. TE AMO), levou uma filmadora para o local da apresentação, mas pedia a ela para não filmar, pois saberia que dificultaria mais ainda meu rendimento. Antes da demanda, a todo momento verificava se ela não estava tentando me enrolar, mas para minha surpresa, quando iniciei a apresentação foi como se minhas vistas se fechassem a tudo, só vinha a minha cabeça parcelas do meu trabalho ancoradas por tópicos de uma apresentação do OpenOffice.org Impress preparada para isto. Consegui consumir mais que 45 minutos e eu achava que poderia falar tudo em menos de 15. Aliás, seriam somente 15 minutos de apresentação por TCC se mais do que somente eu, formando, estivesse terminando a graduação naquele semestre.
Ah! A Katy, sem que eu percebesse, fez toda a filmagem da apresentação e foi um sarro só rever minha performance. Como eu sou ruim de apresentação!
Acredito que este relato sobre meu TCC, Gnu/Linux e Java termine por aqui, a não ser que me venha a cabeças mais algumas coisas interessantes que ocorreram neste período.
Até que enfim eu tinha conseguido superar o problemão de "adormecimento" esporádico do cluster e agora ele funcionava "a mil". Ainda havia um detalhe que não consegui resolver até o final do trabalho e vou relatá-lo resumidamente (a minha moda) para que, quem sabe, alguém possa me dizer o que estava havendo.
Um computador cliente, em uma sessão de testes, fazendo requisições por, digamos 10 minutos, nunca conseguia fazer com que o cluster (nos primeiros testes somente um computador, o primário), chegasse próximo a 100% de uso da CPU. E não era porque o cliente era fraco, pois normalmente não exigia mais de 30% de CPU do cliente neste tipo de teste, enquanto que o cluster não chegava a 80%. Cheguei até a tentar virtualização com Xen para fazer com que um computador rodasse várias instâncias servidoras tentando obter o máximo de sua performance, mas não adiantou em nada. Para ilustrar mais um pouco e tentarem compreender o problema, se eu utilizasse 2 computadores clientes, cada um ocuparia no máximo 20% de sua CPU (média) durante 10 minutos de teste e o cluster, então, passava de 80%. Se no teste fosse utilizado 3 computadores clientes, cada um também usava em média 20% da CPU, mas então o cluster já era carregado a mais de 90%. Nunca entendi isto, procurei razões, gargalos de rede ou de entrada/saída, mas não encontrei.
Estava na responsabilidade de conseguir computadores clientes, para meu cluster de 3 nós, que fossem capazes de "sugar" o máximo de sua capacidade e graças a Deus consegui isto para praticamente todos os meus teste, só um, entre diversas configurações de teste é que não consegui obter, com 3 computadores clientes, 100% de uso da CPU do cluster na configuração de 3 nós.
Até agora ainda Java parece algo pouco irrelevante para o Trabalho de Conclusão, mas lá por maio ele tornou-se peça fundamental. Como nesta época eu já tinha o cluster funcionando (até tive que refazê-lo logo após usar xen, pois consegui destruir com todos os arquivos de configuração do primário), e estava sobrando tempo para algo a mais.
Foi aí que meu orientador de TCC, Alexandre Timm, fez-me aceitar que o mais importante do meu TCC não era o cluster e sim as ferramentas para medição de performance que eu tinha iniciado como um instrumento simples para poder comparar os resultados em diversos tipos de configuração do cluster: 1 nós, 2 nós, 3 nós, entre outros detalhes, para apurar se realmente um cluster obteria alguma vantagem em relação a um computador só.
Que ótimo que este modelo de cluster trazia bons resultados, imagina se eu tivesse perdido meses pesquisando e iniciado o projeto, comprado computadores para verificar que não servia pra melhorar a performance, no máximo para alta disponibilidade, eu teria ficado muito decepcionado.
Era incrível, pois o cluster já tinha failover e failback funcionando. Era desligar o primário "na marra" que o secundário assumia suas funcões, a base de dados postgresql não ficava comprometida e somente a performance é que ficava diminuída. Colocava o primário no ar e este reassumia suas funções, atualizando em disco tudo aquilo que estava desatualizado (somente a partição da base de dados, que era a única coisa realmente mutante do cluster) era automagicamente atualizada e o cluster retomava sua capacidade máxima. Inclusive se um nó parasse de funcionar, o cluster reconhecia e se regulava.
Voltando ao Java, passei então a aprimorar todos os componentes que estava utilizando, separando-os e melhorando a troca de informações entre eles. Eu tinha então:
- uma aplicação web rodando em cada nós do cluster;
- uma aplicação cliente rodando em cada computador cliente
- uma aplicação console que coordenava todos os computadores clientes, iniciando uma sessão de teste simultaneamente e obtendo e armezanando os resultados verificados pelos clientes
- uma aplicação que chamei de gráficos para comparar resultados de testes
Aprendi muito sobre Java, tive que usar extensivamente Thread (algo que era totalmente obscuro pra mim), e confirmei que Java é uma ótima plataforma, mesmo em intensa carga jamais "arriou", no máximo apresentou problemas que eu custei muito a saber o que era, hehehe, mas por causa de um módulo de memória que pifou e fazia a aplicação web (na verdade o tomcat), simplesmente sumir da memória.
Estava na transição entre Java 5 e Java 6, e mesmo sendo beta, utilizei Java 6 em praticamente todo o trabalho.
Algo muito engraçado que ocorria era que em testes, distante do meu laboratório, um Athlon 64 3000+ com Debian Sarge, podia processar algo como 30% a mais de requisições que um Athlon 64 3500+ com Windows XP. Este Athlon 64 3000+ era o servidor (ainda é), de banco de dados da prefeitura e o Athlon 64 3500+ era o notebook do meu colega que jamais teve intenção de se ligar ao mundo livre e simplesmente ignorava-o por não lhe fornecer as ferramentas que ele precisava. Então, por causa disto, muitas e muitas vezes "arriava-me" nele por um "simples" Athlon 64 3000+ sem bem mais poderoso, com Linux, que seu ínfimo Athlon 3500+ com ruindous.
Chegou o dia da apresentação do TCC para a banca e era, basicamente, demonstrar como fôra todo o planejamento e construção do cluster, bem como das ferramentas para medição de performance que tinham se tornado tão ou mais importante que o próprio cluster para o escopo do trabalho. Sempre tive muita dificuldade para falar em público, imagina na defesa do TCC!
Minha namorada (na época, hoje noiva. TE AMO), levou uma filmadora para o local da apresentação, mas pedia a ela para não filmar, pois saberia que dificultaria mais ainda meu rendimento. Antes da demanda, a todo momento verificava se ela não estava tentando me enrolar, mas para minha surpresa, quando iniciei a apresentação foi como se minhas vistas se fechassem a tudo, só vinha a minha cabeça parcelas do meu trabalho ancoradas por tópicos de uma apresentação do OpenOffice.org Impress preparada para isto. Consegui consumir mais que 45 minutos e eu achava que poderia falar tudo em menos de 15. Aliás, seriam somente 15 minutos de apresentação por TCC se mais do que somente eu, formando, estivesse terminando a graduação naquele semestre.
Ah! A Katy, sem que eu percebesse, fez toda a filmagem da apresentação e foi um sarro só rever minha performance. Como eu sou ruim de apresentação!
Acredito que este relato sobre meu TCC, Gnu/Linux e Java termine por aqui, a não ser que me venha a cabeças mais algumas coisas interessantes que ocorreram neste período.
sexta-feira, 11 de janeiro de 2008
2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 004
Enquanto eu não conseguia verba para comprar componentes e dispor de mais máquinas para exigir o máximo do cluster, comecei a desenvolver um centro de controle parar realização dos testes, o console, ele seria o responsável por controlar as máquinas clientes, fazendo com que elas iniciassem uma sessão de teste ao mesmo tempo, procurando obter resultados mais precisos possíveis para um intervalo de tempo, pois disparar cada clientes "a mão", mesmo que eu tivesse três braços para iniciar e parar três clientes, ainda assim acredito que alguns centésimos de segundos teria de diferença entre um teste e outro, o que ocasionaria diferenças de resultado que eu estava disposto a eliminar.
Tudo parecia estar indo bem, já conseguia comandar os clientes através do console e neles eu apreciava em tempo real os tempos de resposta e o número de requisições atendidas por segundo. Mas como se sofre quando não se conhece os detalhes "ocultos" das tecnologias com que se trabalha, foi justamente o que ocorreu, quando eu não consegui colocar o cluster em carga máxima, ou seja, fazê-lo usar 100%, ou perto disto, da CPU, tua parecia bem, mas quando comecei a conseguir manter o uso de CPU em 100%, ocorria um efeito trágico, do nada, o cluster parava de responder e ficava um longo período sem processar nada. Isto era o fim! Tinha chegado num ponto em que não tinha a mínima idéia do que poderia estar acontecendo, a não ser por um pequeno detalhe que eu havia percebido, assim que eu terminei a aplicação web, reparava no gerenciador do tomcat, que a cada requisição que eu fazia à aplicação, uma nova sessão era criada. Minha primeira tentativa de contornar o problema foi diminuir ao máximo o tempo de timeout da sessão, coloquei 1 minuto, que era o mínimo permitido, mas mesmo assim, com este tempo, não era possível evitar que o cluster "travasse" em determinado momento de muita carga. Insisti que poderia modificar, então, alguma coisa na aplicação web para que ela não iniciasse uma nova sessão a cada requisição, mas minhas tentativas foram em vão e eu estava certo que era pelo número acumulado de sessões abertas, pois consegui visualizar que quando chegava a um determinado número de sessões abertas era que o cluster travava. Não lembro como consegui chegar à solução, mas foi algo bem diferente do que eu pensava ser a solução, lembro que foi alguma coisa relacionada a configuração da máquina virtual, como incluir o parâmetro "-server" e algumas diretivas para garbage collector operar em paralelo. Simplesmente o cluster passou a voar, consegui resolver o problema e de quebra ele processava muito mais requisições por segundo.
Passada a grande frustação e o êxtase da solução, ainda pairava em mim uma desconfiança de que ainda não tinha chegado ao fim os problemas que pareciam "insolucionáveis", mas para minha grata surpresa, não lembro de ter passado por outro momento de tanta dificuldade quanto este.
Tudo parecia estar indo bem, já conseguia comandar os clientes através do console e neles eu apreciava em tempo real os tempos de resposta e o número de requisições atendidas por segundo. Mas como se sofre quando não se conhece os detalhes "ocultos" das tecnologias com que se trabalha, foi justamente o que ocorreu, quando eu não consegui colocar o cluster em carga máxima, ou seja, fazê-lo usar 100%, ou perto disto, da CPU, tua parecia bem, mas quando comecei a conseguir manter o uso de CPU em 100%, ocorria um efeito trágico, do nada, o cluster parava de responder e ficava um longo período sem processar nada. Isto era o fim! Tinha chegado num ponto em que não tinha a mínima idéia do que poderia estar acontecendo, a não ser por um pequeno detalhe que eu havia percebido, assim que eu terminei a aplicação web, reparava no gerenciador do tomcat, que a cada requisição que eu fazia à aplicação, uma nova sessão era criada. Minha primeira tentativa de contornar o problema foi diminuir ao máximo o tempo de timeout da sessão, coloquei 1 minuto, que era o mínimo permitido, mas mesmo assim, com este tempo, não era possível evitar que o cluster "travasse" em determinado momento de muita carga. Insisti que poderia modificar, então, alguma coisa na aplicação web para que ela não iniciasse uma nova sessão a cada requisição, mas minhas tentativas foram em vão e eu estava certo que era pelo número acumulado de sessões abertas, pois consegui visualizar que quando chegava a um determinado número de sessões abertas era que o cluster travava. Não lembro como consegui chegar à solução, mas foi algo bem diferente do que eu pensava ser a solução, lembro que foi alguma coisa relacionada a configuração da máquina virtual, como incluir o parâmetro "-server" e algumas diretivas para garbage collector operar em paralelo. Simplesmente o cluster passou a voar, consegui resolver o problema e de quebra ele processava muito mais requisições por segundo.
Passada a grande frustação e o êxtase da solução, ainda pairava em mim uma desconfiança de que ainda não tinha chegado ao fim os problemas que pareciam "insolucionáveis", mas para minha grata surpresa, não lembro de ter passado por outro momento de tanta dificuldade quanto este.
quinta-feira, 10 de janeiro de 2008
2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 003
Que beleza, o cluster estava sendo construído, mas eu precisa poder testar sua capacidade de processamento e minha primeira ação neste sentido foi criar uma aplicação web para instalar no cluster. Esta aplicação web deveria ter que acessar uma base de dados para que simulasse uma aplicação real, que fizesse transações na base de dados, como consultas e gravações.
Eu já tinha resolvido iniciar estudos em Java e na época estava brincando com Mentawai (http://www.mentaframework.org) para desenvolvimentos de aplicações J2EE (este seria meu framework MVC). Antes dele estava penando estudando Struts e depois Webwork2, mas não era nada fácil produzir algo em Java e ter que declarar um monte de coisas em XML. Com Mentawai era tudo muito mais "natural" para mim, logo consegui desenvolver a aplicação web para rodar em Tomcat no cluster (já havia desistido de usar apache, porque para meu projeto, o Tomcat iria servir bem).
Beleza, a aplicação web rodando no cluster, eu acessava com Firefox, mas e como medir os tempos de processamento? Quantas requisições por segundo o cluster era capaz de processar. E se eu tivesse um cluster com 2 nós, 3 nós, ou mesmo um só computador, como eu iria obter resultados para comparação?
Antes mesmo de procurar por uma ferramenta para medição de performance, atraquei-me no desenvolvimento de uma aplicação desktop (com swing, nesta época o matisse estava me salvando, por isto optei por desenvolvê-la em Java) para disparar requisições contra o cluster e obter os tempos de cada resposta. Estava bem legal, mas para minha surpresa, o computador cliente, que estava disparando as requisições ao cluster, retornava praticamente os mesmos valores, independente de utilizar 1, 2 ou 3 computadores no cluster (certos estamos de que 1 nós não seria um cluster). Rapidamente tive a idéia de monitorar o uso de CPU de cada nó durante uma sessão de processamento e foi aí que descobri que meu notebook com processador pentium IV de 2.8GHz não seria capaz de elevar o uso de CPU, nem mesmo o nó primário (um athlon 3000+) de cluster a 100%, ou seja, o cluster estava com folga, mesmo que eu utilizasse um só nó, eu deveria ter que utilizar mais computadores clientes e aí estava um grande problema. A muito custo consegui comprar mais dois "jogos" de gabinete, placa-mae, memoria, disco rígido e processador para, juntamente com meu PC (o primário) formar o cluster. Eita projetinho mal elaborado!
Eu já tinha resolvido iniciar estudos em Java e na época estava brincando com Mentawai (http://www.mentaframework.org) para desenvolvimentos de aplicações J2EE (este seria meu framework MVC). Antes dele estava penando estudando Struts e depois Webwork2, mas não era nada fácil produzir algo em Java e ter que declarar um monte de coisas em XML. Com Mentawai era tudo muito mais "natural" para mim, logo consegui desenvolver a aplicação web para rodar em Tomcat no cluster (já havia desistido de usar apache, porque para meu projeto, o Tomcat iria servir bem).
Beleza, a aplicação web rodando no cluster, eu acessava com Firefox, mas e como medir os tempos de processamento? Quantas requisições por segundo o cluster era capaz de processar. E se eu tivesse um cluster com 2 nós, 3 nós, ou mesmo um só computador, como eu iria obter resultados para comparação?
Antes mesmo de procurar por uma ferramenta para medição de performance, atraquei-me no desenvolvimento de uma aplicação desktop (com swing, nesta época o matisse estava me salvando, por isto optei por desenvolvê-la em Java) para disparar requisições contra o cluster e obter os tempos de cada resposta. Estava bem legal, mas para minha surpresa, o computador cliente, que estava disparando as requisições ao cluster, retornava praticamente os mesmos valores, independente de utilizar 1, 2 ou 3 computadores no cluster (certos estamos de que 1 nós não seria um cluster). Rapidamente tive a idéia de monitorar o uso de CPU de cada nó durante uma sessão de processamento e foi aí que descobri que meu notebook com processador pentium IV de 2.8GHz não seria capaz de elevar o uso de CPU, nem mesmo o nó primário (um athlon 3000+) de cluster a 100%, ou seja, o cluster estava com folga, mesmo que eu utilizasse um só nó, eu deveria ter que utilizar mais computadores clientes e aí estava um grande problema. A muito custo consegui comprar mais dois "jogos" de gabinete, placa-mae, memoria, disco rígido e processador para, juntamente com meu PC (o primário) formar o cluster. Eita projetinho mal elaborado!
quarta-feira, 9 de janeiro de 2008
2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 002
Para que eu pudesse ter balanceamento de carga e cada nós rodando um servidor web, eu precisava da base de dados disponível para cada nó o mais imediato possível. Minha idéia era de que cada nós teria uma cópia da base de dados, até mesmo para auxiliar na tarefa de alta disponibilidade. O problema era sincronizar estes dados todos. Isto levou-me a pesquisar sobre sistemas de arquivo replicados em rede, como OCFS2 e GFS, pensando que nisto meu problemas de replicação de dados estariam resolvidos, mas não foi nem perto, depois de muito pelear com GFS, passei a utilizar OCFS2 com o auxílio de um de seus desenvolvedores e consegui colocá-lo em funcionamento, mas não havia forma de conseguir fazer o mysql de um nó enxergar os dados gravados pelo mysql de outro nó, deveria ser algo relacionado a cache que o mysql faz. Voltei para o GFS, já entendendo um pouquinho de replicação de dados em rede e consegui fazâ-lo funcionar. Ah! Esqueci de dizer que eu usava Debian e faria tudo em Debian.
De tanto fuçar até que consegui fazer o mysql, às vezes, um nó enxergar os dados gravados por outro, mas tive que desabilitar tudo quanto é cache, não poderia usar transação (InnoDB) e até mesmo uns negócios de flush do disco rígido tive que configurar. Tentei até mesmo postgresql, mas depois de muito procurar, fiquei sabendo que um diretório que armazena uma base de dados não pode ser acessado por mais de um processo servidor postgresql ao mesmo tempo, ele usa umas travas e o servidor postgresql do segundo nós já não podia abrir a base.
Estava tudo errado, eu queria uma solução de balanceamento de carga que não precisasse ser vinculada a um único fornecedor de banco de dados. Em conversa com o desenvolvedor do OCFS2, este até recomendou-me utilizar uma versão do banco de dados da Oracle com suporte nativo a replicação. Mas se fosse o caso usaria o mecanismo de replicação nativo do Mysql e não era minha intenção.
Passaram-se quase dois meses de pesquisa intensa, até que resolvi que não replicaria a base de dados, todos acessariam do nó principal, o redirecionador, e por minha sorte, ao estudar sobre balanceamento de carga com LVS, "achei" o DRDB e meu problema de replicação de dados estava em partes resolvido. Embora eu pudesse somente ter uma cópia dos dados replicada em outro servidor, este era o modelo do meu cluster para alta disponibilidade, em caso de falha do redirecionador, um outro nó, previamente configurado, assumiria o papel daquele, usando os dados replicados, mas um pouco antes disto até tentei fazer com que o DRDB permitisse gravação em ambos nós, o primário e o secundário, mas não teve jeito, a versão de uso ainda não permitia que o secundário montasse a partição para escrita, somente, leitura, então abandonei de vez a idéia de a base sendo gravada por diversos nós, somente o redirecionador ou primário o faria.
A partir disto, acredito que já era março, passei a implementar LVS e DRDB, para, por fim, Heatbeat e Keepalived. Não que eu tenha terminado em março, mas sim acredito que eu já havia conseguido descobrir todos os componentes de software livre eu precisaria para poder implementar o cluster e realmente as pesquisas feitas nestes dois primeiros meses (janeiro e fevereiro/2006), foram as responsáveis pelo êxito do projeto. Estas pesquisas deveriam ter sido feitas lá em 2004, mas na época eu não estava muito a fim de passar trabalho.
De tanto fuçar até que consegui fazer o mysql, às vezes, um nó enxergar os dados gravados por outro, mas tive que desabilitar tudo quanto é cache, não poderia usar transação (InnoDB) e até mesmo uns negócios de flush do disco rígido tive que configurar. Tentei até mesmo postgresql, mas depois de muito procurar, fiquei sabendo que um diretório que armazena uma base de dados não pode ser acessado por mais de um processo servidor postgresql ao mesmo tempo, ele usa umas travas e o servidor postgresql do segundo nós já não podia abrir a base.
Estava tudo errado, eu queria uma solução de balanceamento de carga que não precisasse ser vinculada a um único fornecedor de banco de dados. Em conversa com o desenvolvedor do OCFS2, este até recomendou-me utilizar uma versão do banco de dados da Oracle com suporte nativo a replicação. Mas se fosse o caso usaria o mecanismo de replicação nativo do Mysql e não era minha intenção.
Passaram-se quase dois meses de pesquisa intensa, até que resolvi que não replicaria a base de dados, todos acessariam do nó principal, o redirecionador, e por minha sorte, ao estudar sobre balanceamento de carga com LVS, "achei" o DRDB e meu problema de replicação de dados estava em partes resolvido. Embora eu pudesse somente ter uma cópia dos dados replicada em outro servidor, este era o modelo do meu cluster para alta disponibilidade, em caso de falha do redirecionador, um outro nó, previamente configurado, assumiria o papel daquele, usando os dados replicados, mas um pouco antes disto até tentei fazer com que o DRDB permitisse gravação em ambos nós, o primário e o secundário, mas não teve jeito, a versão de uso ainda não permitia que o secundário montasse a partição para escrita, somente, leitura, então abandonei de vez a idéia de a base sendo gravada por diversos nós, somente o redirecionador ou primário o faria.
A partir disto, acredito que já era março, passei a implementar LVS e DRDB, para, por fim, Heatbeat e Keepalived. Não que eu tenha terminado em março, mas sim acredito que eu já havia conseguido descobrir todos os componentes de software livre eu precisaria para poder implementar o cluster e realmente as pesquisas feitas nestes dois primeiros meses (janeiro e fevereiro/2006), foram as responsáveis pelo êxito do projeto. Estas pesquisas deveriam ter sido feitas lá em 2004, mas na época eu não estava muito a fim de passar trabalho.
2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 001
Finalmente, no final de 2004 eu havia pensando em algo para o Trabalho de Conclusão de Curso que não fosse desenvolver um sistema. Resolvi que iria enfrentar a tarefa de desenvolver um cluster, afinal, não tinha conhecimento de que alguém no campus da Ulbra tivesse elaborado trabalho parecido e eu julgava-me competente para abraçar esta tarefa utilizando somente software livre.
No início de 2005 apresentei o projeto à banca e a orientaçao do curso veio com a boa notícia de que estava aceito. A princípio, no projeto, especifiquei uma meia dúzia de requisitos para construir o cluster, acredito que eu tenha trabalhado 2 dias neste projeto, o que me fez ter certeza de que em um ou dois meses, utilizando open-mosix eu teria um cluster para rodar aplicações web rodando a milhão. Este foi meu maior erro durante o TCC.
Resolvi que não cursaria o segundo semestre de 2005 e daria início ao TCC somente em 2006, o que efetivamente ocorreu. Chegou então Janeiro de 2006 e tirei para começar a estudar, novamente, open-mosix e algumas coisas a mais que seriam necessárias para construi este cluster, ainda nem estava pesando onde arranjaria os computadores para montar este cluster.
Lia Pitanga falando dos tipos de cluster e foi então que caiu a ficha. Um cluster open-mosix não serviria para aplicações web com apache! Ele era voltado para cálculos paralelizados, utilizando bibliotecas em C para criação do programa a ser paralelizado, era um cluster do tipo de alta performance. Eu definitivamente não queria aceitar que não daria para rodar apache, bem mais rápido, com open-mosix, mas tudo que eu lia era afirmando que não trazia vantagens e que no máximo eu teria que usar um esquema de cache de memória sei lá das quantas... Bom, tive que abandonar open-mosix, o que não poderia ser diferente.
Passei então a estudar o domínio do problema, o que deveria ter feito lá em 2004 com mais vontade. Cheguei então ao tipo de cluster para balanceamento de carga e alta disponibilidade. Em termos de resultado, o de balanceamento de carga daria para mostrar em gráficos as diferenças no número de requisições concluídas pelo cluster em um terminado tempo. Mas ao mesmo tempo achei muito interessante uma solução de alta disponibilidade para um ambiente como o da Prefeitura. Pronto, estava resolvido, modifiquei um pouco a proposta e reapresentei, agora citando cluster para balanceamento de carga e alta disponibilidade. Mas isto não era nada do que eu eu iria passar ainda.
No início de 2005 apresentei o projeto à banca e a orientaçao do curso veio com a boa notícia de que estava aceito. A princípio, no projeto, especifiquei uma meia dúzia de requisitos para construir o cluster, acredito que eu tenha trabalhado 2 dias neste projeto, o que me fez ter certeza de que em um ou dois meses, utilizando open-mosix eu teria um cluster para rodar aplicações web rodando a milhão. Este foi meu maior erro durante o TCC.
Resolvi que não cursaria o segundo semestre de 2005 e daria início ao TCC somente em 2006, o que efetivamente ocorreu. Chegou então Janeiro de 2006 e tirei para começar a estudar, novamente, open-mosix e algumas coisas a mais que seriam necessárias para construi este cluster, ainda nem estava pesando onde arranjaria os computadores para montar este cluster.
Lia Pitanga falando dos tipos de cluster e foi então que caiu a ficha. Um cluster open-mosix não serviria para aplicações web com apache! Ele era voltado para cálculos paralelizados, utilizando bibliotecas em C para criação do programa a ser paralelizado, era um cluster do tipo de alta performance. Eu definitivamente não queria aceitar que não daria para rodar apache, bem mais rápido, com open-mosix, mas tudo que eu lia era afirmando que não trazia vantagens e que no máximo eu teria que usar um esquema de cache de memória sei lá das quantas... Bom, tive que abandonar open-mosix, o que não poderia ser diferente.
Passei então a estudar o domínio do problema, o que deveria ter feito lá em 2004 com mais vontade. Cheguei então ao tipo de cluster para balanceamento de carga e alta disponibilidade. Em termos de resultado, o de balanceamento de carga daria para mostrar em gráficos as diferenças no número de requisições concluídas pelo cluster em um terminado tempo. Mas ao mesmo tempo achei muito interessante uma solução de alta disponibilidade para um ambiente como o da Prefeitura. Pronto, estava resolvido, modifiquei um pouco a proposta e reapresentei, agora citando cluster para balanceamento de carga e alta disponibilidade. Mas isto não era nada do que eu eu iria passar ainda.
A procura e o encontro: Java
No final de 2003, o Baboo e eu criticávamos o Fabiano. Éramos colegas de faculdade naquela época. Nós defendíamos vorazmente PHP e o Fabiano o Java, com seus argumentos principais de que com PHP os projetos não eram normalmente orientados a OO e que os programadores Java usualmente ganhavam bem mais que os programadores PHP que poderiam ser encontrados em qualquer boteco.
Em meu íntimo estava disposto a continuar com PHP de toda a forma, não querendo render-me a vontade de iniciar a aprendizagem em uma nova plataforma.
Mas o destino como sempre, fez com que no final de 2004, o Fabiano já formado e mestrando na PUC viesse dar aula na disciplina de Tópicos Avançados em Sistemas de Informação I (só por curiosidade, TASI II eu havia cursado um ano antes, era pra estudarmos XML, mas acabamos estudando PHP), onde foi feito uma abordagem básica de J2EE.
Fiquei interessado e também "obrigado" a aprender J2EE e gostei. Embora pra começar um projeto Web em Java demandasse 6 horas de preparação até conseguir fazer um "Hello World!" e as declarações de todos os servlets em web.xml, achei realmente interessante, acho que muito mais por estar finalmente desenvolvendo em Java. Como tarefa para o final do semestre, cada aluno apresentou um framework diferente e coube a mim, o Struts.
Nesta mesma época, eu estava pensando em uma área de estudo para desenvolvimento do meu trabalho de conclusão e ingenuamente eu acreditava que poderia construir algo como um framework em PHP para desenvolvimento mais rápido de sistemas, sem precisar utilizar frames de HTML e que utilizasse templates como Smarty, acredito que seria algo parecido com MVC (mas mesmo quase concluindo o curso de Sistemas de Informação, jamais havia ouvido falar de MVC). Bom, após estudar e apresentar um pequeno exemplo do funcionamento de Struts vi que a tarefa de criar aquele framework em PHP estava além do meu alcance e abandonei de vez aquela idéia e, também, o PHP.
Passei então a dedicar-me ao aprendizado de Java, principalmente para aplicações desktop, mas não conseguia evoluir, porque antes do matisse era muito complicado desenvolver interfaces e eu novato, não conseguia fazer nada, ficava brincando, então com J2EE.
Em meu íntimo estava disposto a continuar com PHP de toda a forma, não querendo render-me a vontade de iniciar a aprendizagem em uma nova plataforma.
Mas o destino como sempre, fez com que no final de 2004, o Fabiano já formado e mestrando na PUC viesse dar aula na disciplina de Tópicos Avançados em Sistemas de Informação I (só por curiosidade, TASI II eu havia cursado um ano antes, era pra estudarmos XML, mas acabamos estudando PHP), onde foi feito uma abordagem básica de J2EE.
Fiquei interessado e também "obrigado" a aprender J2EE e gostei. Embora pra começar um projeto Web em Java demandasse 6 horas de preparação até conseguir fazer um "Hello World!" e as declarações de todos os servlets em web.xml, achei realmente interessante, acho que muito mais por estar finalmente desenvolvendo em Java. Como tarefa para o final do semestre, cada aluno apresentou um framework diferente e coube a mim, o Struts.
Nesta mesma época, eu estava pensando em uma área de estudo para desenvolvimento do meu trabalho de conclusão e ingenuamente eu acreditava que poderia construir algo como um framework em PHP para desenvolvimento mais rápido de sistemas, sem precisar utilizar frames de HTML e que utilizasse templates como Smarty, acredito que seria algo parecido com MVC (mas mesmo quase concluindo o curso de Sistemas de Informação, jamais havia ouvido falar de MVC). Bom, após estudar e apresentar um pequeno exemplo do funcionamento de Struts vi que a tarefa de criar aquele framework em PHP estava além do meu alcance e abandonei de vez aquela idéia e, também, o PHP.
Passei então a dedicar-me ao aprendizado de Java, principalmente para aplicações desktop, mas não conseguia evoluir, porque antes do matisse era muito complicado desenvolver interfaces e eu novato, não conseguia fazer nada, ficava brincando, então com J2EE.
segunda-feira, 7 de janeiro de 2008
À procura de uma plataforma de desenvolvimento livre 003
Foi então que em 2002 pensei ter encontrado a solução, não que esta não poderia ter sido a minha solução, comecei a dedicar-me a PHP. Neste mesmo ano, Rasmus Lerdorf, o criador do PHP palestrou no FISL e fiquei encantado com a possibilidade de desenvolver para a web, pois era outro bonde que eu já estava quase perdendo, primeiro o GUI e agora a web. Comecei a produzir tudo que podia de programinhas em PHP, inclusive os que seriam mais simplesmente implementados em Delphi ou mesmo CLIPPER. Como PHP lembrava-me os tempos de CLIPPER com sua produtividade e sem precisar ficar arrastando componentes, o problema era o HTML, pois com minha enorme criatividade, meus melhores layouts seriam dignos da exclamação "Nossa que horrível!". Tirando este contratempo, produzia e produzia com PHP, sua facilidade em acessar minha base de dados em mysql (outro que sofri pra quebrar o paradigma, mas isto seria outra história).
Mas algo ainda parecia não estar certo, não me parecia correto produzir tudo para a web. E os sistemas de entrada massiva de dados que o ideal seria uma aplicação console (embora eu relutasse e sempre me "esmurrava" para acreditar que em GUI também poderia ser bom)? Como fazer uma aplicação simples e rodar em um Pentium 133 com 32MB de RAM se eu teria que instalar no computador do cliente um servidor mysql e um servidor http? Coitado de alguns clientes que tiveram que aceitar estas soluções, mas eles já não sofrem mais pois tenho certeza de que não utilizam mais aqueles programinhas que fiz (normalmente produzia de forma quase que gratuita, pois hoje eu vejo que cobrar R$ 50,00 ou R$ 100,00, ainda que em 2002 era piada, mas eu sempre aceitava que isto estava ajudando no meu desenvolvimento pessoal - e porque não?).
Mas não dava não, mysql e apache em 32 MB de RAM não dava. Volta e meia produzia novamente em Delphi, pois rodava e bem de 486 com 32MB de RAM pra cima e mais alguns aninhos se passaram.
Já em 2004 o problema de pouca RAM parecia no passado, mas eu continuava relutando em ter que instalar "trocentos" servidor só pra ter que rodar um simples programa no computador do cliente.
Desde 1997 eu já estava ouvindo falar de Java e que rodava em qualquer browser e que era totalmente orientado a objetos (depois alguns já diziam que não era totalmente, algumas coisas faltavam), mas antes de 2001/2002 eu não vislumbrava desenvolver para a web, torcia para que fosse só moda sistemas rodar em web, páginas sim, sites de e-commerce, mas não sistemas, por favor! Antes de começar a aprender C nem pensava em Java, pois diziam ser o dialeto C e ainda orientado a objetos, fora que não tinha uma IDE RAD, tipo Delphi, "sem jeito, tô fora" eu pensava, como iria produzir alguma coisa assim? Havia uma galerinha (poucas pessoas) na faculade que eram mais abastados e tinham bons computadores, em casa ou no trabalho e podia testar novas tecnologias, alguns até relatavam que estava desenvolvendo em Java usando uma IDE sei lá o quê da Symantec, só que era muito lento. Eu já tinha feito um upgrade no meu PC, agora ele era um Pentium 100 não com 16MB de RAM, já devia estar com uns 96MB, mas não tinha jeito, Java era muuuuuito lento e não tinha vontade nem de aprender, até discutia com uns colegas, mas isto já lá por 2003/2004 que o negócio mesmo era PHP, que Java não era produtivo e sei lá mais o quê (e isto que eu nunca tinha produzido nem um Hello World em Java).
Mas é a vida! Vinha um Fórum de Software Livre e dizia que C++ era o canal pra se desenvolver com QT e lá eu ia eu codificar e codificar durante uns 3 meses, depois ja era C com GTK, depois era PHP com GTK, depois já era Python. Lembro que Python foi interessante, saí da palestra achando que finalmente o mundo estava salvo, para Python tudo era objeto, inclusive um "a".upper() dava pra se fazer. Mas era tudo tão difícil, não digo aprender a linguagem, mas ser produtivo era o problema.
O pessoal do Mono, então, praticamente monopolizou um FISL e, embora olhando meio estranho por se tratar de uma implementação livre de tecnologia Microsoft, achei interessante poder ter bindings atualizados, pois PHP GTK era um caso em que não podia usar as mais recentes características do GTK. Nesta época já contava com uma pequena experiência em Java e pude notar o quanto C# (que havia sido a linguagem que eu queria adotar por contemplar de toda a capacidade do framework) era parecido com ela. Não evolui em nada com Mono, até porque não gostei da idéia de ter que usar Glade pra produzir interfaces e codificar em outro editor, não era tão produtivo quanto Delphi ou CLIPPER e definitivamente eu não iria mais programar em uma plataforma de desenvolvimento que eu tivesse que pagar para utilizá-la e Java e Mono eram gratuítas e livre respectivamente.
Mas algo ainda parecia não estar certo, não me parecia correto produzir tudo para a web. E os sistemas de entrada massiva de dados que o ideal seria uma aplicação console (embora eu relutasse e sempre me "esmurrava" para acreditar que em GUI também poderia ser bom)? Como fazer uma aplicação simples e rodar em um Pentium 133 com 32MB de RAM se eu teria que instalar no computador do cliente um servidor mysql e um servidor http? Coitado de alguns clientes que tiveram que aceitar estas soluções, mas eles já não sofrem mais pois tenho certeza de que não utilizam mais aqueles programinhas que fiz (normalmente produzia de forma quase que gratuita, pois hoje eu vejo que cobrar R$ 50,00 ou R$ 100,00, ainda que em 2002 era piada, mas eu sempre aceitava que isto estava ajudando no meu desenvolvimento pessoal - e porque não?).
Mas não dava não, mysql e apache em 32 MB de RAM não dava. Volta e meia produzia novamente em Delphi, pois rodava e bem de 486 com 32MB de RAM pra cima e mais alguns aninhos se passaram.
Já em 2004 o problema de pouca RAM parecia no passado, mas eu continuava relutando em ter que instalar "trocentos" servidor só pra ter que rodar um simples programa no computador do cliente.
Desde 1997 eu já estava ouvindo falar de Java e que rodava em qualquer browser e que era totalmente orientado a objetos (depois alguns já diziam que não era totalmente, algumas coisas faltavam), mas antes de 2001/2002 eu não vislumbrava desenvolver para a web, torcia para que fosse só moda sistemas rodar em web, páginas sim, sites de e-commerce, mas não sistemas, por favor! Antes de começar a aprender C nem pensava em Java, pois diziam ser o dialeto C e ainda orientado a objetos, fora que não tinha uma IDE RAD, tipo Delphi, "sem jeito, tô fora" eu pensava, como iria produzir alguma coisa assim? Havia uma galerinha (poucas pessoas) na faculade que eram mais abastados e tinham bons computadores, em casa ou no trabalho e podia testar novas tecnologias, alguns até relatavam que estava desenvolvendo em Java usando uma IDE sei lá o quê da Symantec, só que era muito lento. Eu já tinha feito um upgrade no meu PC, agora ele era um Pentium 100 não com 16MB de RAM, já devia estar com uns 96MB, mas não tinha jeito, Java era muuuuuito lento e não tinha vontade nem de aprender, até discutia com uns colegas, mas isto já lá por 2003/2004 que o negócio mesmo era PHP, que Java não era produtivo e sei lá mais o quê (e isto que eu nunca tinha produzido nem um Hello World em Java).
Mas é a vida! Vinha um Fórum de Software Livre e dizia que C++ era o canal pra se desenvolver com QT e lá eu ia eu codificar e codificar durante uns 3 meses, depois ja era C com GTK, depois era PHP com GTK, depois já era Python. Lembro que Python foi interessante, saí da palestra achando que finalmente o mundo estava salvo, para Python tudo era objeto, inclusive um "a".upper() dava pra se fazer. Mas era tudo tão difícil, não digo aprender a linguagem, mas ser produtivo era o problema.
O pessoal do Mono, então, praticamente monopolizou um FISL e, embora olhando meio estranho por se tratar de uma implementação livre de tecnologia Microsoft, achei interessante poder ter bindings atualizados, pois PHP GTK era um caso em que não podia usar as mais recentes características do GTK. Nesta época já contava com uma pequena experiência em Java e pude notar o quanto C# (que havia sido a linguagem que eu queria adotar por contemplar de toda a capacidade do framework) era parecido com ela. Não evolui em nada com Mono, até porque não gostei da idéia de ter que usar Glade pra produzir interfaces e codificar em outro editor, não era tão produtivo quanto Delphi ou CLIPPER e definitivamente eu não iria mais programar em uma plataforma de desenvolvimento que eu tivesse que pagar para utilizá-la e Java e Mono eram gratuítas e livre respectivamente.
À procura de uma plataforma de desenvolvimento livre 002
À deriva, passei a utilizar linux com mais freqüência, a partir de 1999 e procurei estudar C, apesar de saber que seria humanamente impossível ser um bom desenvolvedor nesta linguagem, isto era coisa pra heróis.
Estava achando interessante, embora totalmente improdutivo, eu conseguia desenvolver pequenos exercícios e estava achando interessando o quanto realmente C era rápido em relação ao MAX (um tipo de CLIPPER para linux que era utilizado pelo sistema de informações da prefeitura de Terra de Areia). Cheguei a produzir uma extensão extra-oficial e anexei ao sistema da CCA (empresa produtora deste sistema de informações), para realizar uma pré-impressão e foi aí que percebi o quanto C era rápido, pois desenvolvi esta mesma extensão em MAX e era muito lenta.
Estudei um pouco de ncurses e cheguei um chat usando cabo serial (como é fácil fazer comunicação serial em linux). Meus colegas se abobaram, de certo pensaram que eu não tinha dormido por 3 semanas para poder concluir este projeto, ainda mais que eu tinha usado C e linux. Enquanto que a maioria fez o mesmo trabalho em Visual Basic. Mas não dava, C continuava a ser muito improdutivo, estava estudando como trabalhar com postgresql em C e era tudo de outro mundo.
Voltei para o Delphi para poder produzir alguns coisinhas e por aí fiquei, embora sempre com uma preocupação na cabeça. Apareceu até um tal de Kylix e eu achei que fosse a "salvação da lavoura", pois poderia, enfim, desenvolver aplicações GUI tanto para Windows quanto para Linux usando a minha pequena formação em Delphi, mas foi somente um sonho, porque, pra começar, o Kylix era feio pacas, aquelas interfaces criadas por ele eram horrível, além de muito lento.
Estava achando interessante, embora totalmente improdutivo, eu conseguia desenvolver pequenos exercícios e estava achando interessando o quanto realmente C era rápido em relação ao MAX (um tipo de CLIPPER para linux que era utilizado pelo sistema de informações da prefeitura de Terra de Areia). Cheguei a produzir uma extensão extra-oficial e anexei ao sistema da CCA (empresa produtora deste sistema de informações), para realizar uma pré-impressão e foi aí que percebi o quanto C era rápido, pois desenvolvi esta mesma extensão em MAX e era muito lenta.
Estudei um pouco de ncurses e cheguei um chat usando cabo serial (como é fácil fazer comunicação serial em linux). Meus colegas se abobaram, de certo pensaram que eu não tinha dormido por 3 semanas para poder concluir este projeto, ainda mais que eu tinha usado C e linux. Enquanto que a maioria fez o mesmo trabalho em Visual Basic. Mas não dava, C continuava a ser muito improdutivo, estava estudando como trabalhar com postgresql em C e era tudo de outro mundo.
Voltei para o Delphi para poder produzir alguns coisinhas e por aí fiquei, embora sempre com uma preocupação na cabeça. Apareceu até um tal de Kylix e eu achei que fosse a "salvação da lavoura", pois poderia, enfim, desenvolver aplicações GUI tanto para Windows quanto para Linux usando a minha pequena formação em Delphi, mas foi somente um sonho, porque, pra começar, o Kylix era feio pacas, aquelas interfaces criadas por ele eram horrível, além de muito lento.
À procura de uma plataforma de desenvolvimento livre 001
À época em que eu me dedicava de corpo e alma ao desenvolvimento em CLIPPER, nunca pensara nas questões relativas ao licenciamento de software, pensava sim, sempre, em uma forma de poder cobrar de meus clientes por meus softwares utilizados, mas nem me passava pela cabeça que deveria ter que pagar a alguém por estar utilizando o meu adorado CLIPPER (Ah! nesta época eu ainda não tinha computador, utilizava ainda o computador do escritório em que eu trabalhava). Em 1997, quando cravei minhas garras no meu primeiro computador e já sabia, então que havia uma empresa que monopolizava tudo e que me obrigava a pagá-la pra poder utilizar o meu computador, passei também a procurar alternativas ao CLIPPER para poder começar a desenvolver, como diziam, for Windows.
Em 1996, recebi umas 3 edições de uma revista sobre CLIPPER e eles indicavam que Delphi seria uma boa alternativa aos desenvolvedores CLIPPER em detrimento ao Visual Basic, para desenvolvimento for Windows. Certamente que fui induzido pelos mestres autores daquela revista de que o Borland Delphi era a escolha ideal para mim, ainda mais, para mim, que não era fabricada pela demoníaca Microsoft.
Em 1997, continuava, ainda, a desenvolver muito em CLIPPER, pois mesmo achando que eu estava ficando para trás e que o mundo todo já era GUI, eu gostava mesmo era de CLIPPER e tinha "domínio" nesta plataforma, mas meu ingresso na Ulbra (curso de processamento de dados) e o contato com Delphi 2 instalado no laboratório de informática e também do horripilando Visual Basic, começaram a aguçar minha curiosidade. Um semestre antes de iniciar a disciplina de linguagem de programação I, que abordaria Pascal, eu já estava lendo um livro sobre Pascal para preparam-me para a demanda. Pascal era bem pior que CLIPPER, era muito limitada, mas diziam ser tão rápida quanto C (o que me deixava ansioso para aprendê-la, pois para mim os programadores C sempre foram meus ídolos e heróis).
Conclui a disciplina de linguagem de programação I e passei a futricar em Delphi 2, mas foi em Visual Basic que desenvolvi meus primeiros estudos mais avançados em GUI graças à disciplina de linguagem de programação comercial II (como é o destino!!!). Ah! O interessante é que em linguagem de programação comercial I aprendemos... tchã tchã tchã tcha... CLIPPER! Eu peguei um sisteminha meu e estava com o trabalho final do semestre, que valia toda a nota, prontinho.
Depois destas experiências, de dedicar-me ao Delphi 3 e depois ao Delphi 4, algo incomodava-me muito. Descobrira que para cobrar de meus clientes e para que os programas desenvolvidos por mim fossem legais eu deveria ter uma licença (paga) para o Borland Delphi, ou seja, não poderia usá-lo pirateado e cobrar. Minha vida tinha virado um inferno e passei a andar sem destino no mundo.
Em 1996, recebi umas 3 edições de uma revista sobre CLIPPER e eles indicavam que Delphi seria uma boa alternativa aos desenvolvedores CLIPPER em detrimento ao Visual Basic, para desenvolvimento for Windows. Certamente que fui induzido pelos mestres autores daquela revista de que o Borland Delphi era a escolha ideal para mim, ainda mais, para mim, que não era fabricada pela demoníaca Microsoft.
Em 1997, continuava, ainda, a desenvolver muito em CLIPPER, pois mesmo achando que eu estava ficando para trás e que o mundo todo já era GUI, eu gostava mesmo era de CLIPPER e tinha "domínio" nesta plataforma, mas meu ingresso na Ulbra (curso de processamento de dados) e o contato com Delphi 2 instalado no laboratório de informática e também do horripilando Visual Basic, começaram a aguçar minha curiosidade. Um semestre antes de iniciar a disciplina de linguagem de programação I, que abordaria Pascal, eu já estava lendo um livro sobre Pascal para preparam-me para a demanda. Pascal era bem pior que CLIPPER, era muito limitada, mas diziam ser tão rápida quanto C (o que me deixava ansioso para aprendê-la, pois para mim os programadores C sempre foram meus ídolos e heróis).
Conclui a disciplina de linguagem de programação I e passei a futricar em Delphi 2, mas foi em Visual Basic que desenvolvi meus primeiros estudos mais avançados em GUI graças à disciplina de linguagem de programação comercial II (como é o destino!!!). Ah! O interessante é que em linguagem de programação comercial I aprendemos... tchã tchã tchã tcha... CLIPPER! Eu peguei um sisteminha meu e estava com o trabalho final do semestre, que valia toda a nota, prontinho.
Depois destas experiências, de dedicar-me ao Delphi 3 e depois ao Delphi 4, algo incomodava-me muito. Descobrira que para cobrar de meus clientes e para que os programas desenvolvidos por mim fossem legais eu deveria ter uma licença (paga) para o Borland Delphi, ou seja, não poderia usá-lo pirateado e cobrar. Minha vida tinha virado um inferno e passei a andar sem destino no mundo.
sexta-feira, 4 de janeiro de 2008
1º FISL - 1999
Na época, eu não podia imaginar o quanto seria motivante assistir a uma palestra do Stallman, mesmo já sabendo (apenas em poucos detalhes), das histórias que se desenrolaram durante o desenvolvimento da comunidade de software livre e os dragões e trolls que o Saint enfrentou em suas aventuras.
Sem saber nada de inglês, grudei-me naquele fone do rádio e ouvia a tradução e rindo com defasagem de uns 5 segundos em relação a 80% da platéia, encantava-me
com as boas-novas que este senhor nos trazia.
Antes de vê-lo, assim como os escoceses acreditavam que
William Wallace tinha 3 metros de altura e duas cabeças, acreditava que Stallman fosse um homem alto, magro, embora de cabelos e barba comprida, de porte executivo, mas não, para minha agradável surpresa, além de ser um hacker, ele parecia um hacker. Se até então eu via o movimento do software livre/código aberto pela perspectiva da gratuidade, diversão, liberdade e ideologia, agora minha ótica já era, ideologia, liberdade, diversão e gratuidade.
Sei que existem muitas e muitas pessoas que pensam diferente de mim, assim como Stallman e Torvalds também tem suas diferenças e estão entre os maiores ícones deste mundo livre.
Foi um evento impressionante, através do Alex, chefe do setor de informática da FAMURS na época, pude apresentar-me ao Sr. Sandro presidente da Conectiva, que era o orgulho dos brasileiros.
Eu enxia tanto o saco do Alex para que fizesse eventos às prefeituras, relacionado a software livre que acabei sendo conhecido como o cara do Linux para ele, pois até então quase não se pensava em software livre na administração público, por nenhum motivo, até porque era tudo pirata, qual a diferença de se regularizar se tudo estava "funcionando"?
Para o bem do Brasil isto tudo mudou e hoje estamos na vanguarda do desenvolvimento e uso de software livre. Meu desejo é de que não desçamos deste bonde e possamos ajudar a conduzir o mundo para um momento em que possamos ter cada vez mais liberdade e que nossos computadores passem a ser respeitados, por usarmos só software "do bom", ou seja, livre.
quinta-feira, 3 de janeiro de 2008
1994 e o Linux
Até hoje não tenho certeza, se foi em 1994 ou 1995 que li pela primeira vez uma notícia sobre o Linux, acredito que foi em 1994, pois em 1995 eu já assinava a revista Informática Exame.
Fiquei maravilhado! Foi em uma edição desta revista, onde em menos de meia página, exaltavam um sistema operacional baseado em Unix para ser usado em PC e que era muito mais poderoso do que o limitado MS-DOS. Diziam que um determinado professor era o responsável por disponibilizar na internet o sistema produzido por um jovem estudante universitário finlandês. Aquilo pra mim era uma notícia salvadora, pois nesta época já abominava o monopólio e a figura do Mr. Gates (sinceramente não sei porque nasceu este sentimento, pois pouco conheço e conhecia sobre a figura deste Sr.). Diziam lá, também, que este sistema operacional, o Linux, podia ser instalado a partir de uma pequena quantidade de disquetes e que um ambiente gráfico também poderia ser instalado a partir de outra pequena quantidade de disquetes.
Imaginem que fiquei muito contente com a notícia e nem ao menos eu tinha um computador. Usava somente o do escritório de contabilidade onde trabalhava e programava somente longe dos olhos do patrão. Era muita adrenalina!
Depois disto, não lembro mais de ver novamente notícias sobre Linux, mas nunca esqueci que ele existia. Fiquei impressionado com a idéia de que era um sistema grátis e que todos podiam usar sem precisar pagar licenças e que eu podia ver o código e alterar (embora eu tivesse a plena consciência de que entender o código de um sistema operacional era coisa pra extraterrestres)
Em 1997, finalmente, adquiri meu primeiro computador, já no mês de janeiro. Passei vários meses fuçando, formatando e instalando windows versão 95, depois versão 98. Neste ano de 1998 foi que tive, então, minha primeira experiência salvadora, adquiri um livro de título parecido com "Como montar um provedor de internet" e com ele, acompanhava um CD de instalação da distribuição Slackware que não lembro a versão. Incrivelmente consegui particionar meu disco rígido e instalar o sistema e deixá-lo funcional sem perder dados!
Nesta época eu gostaria muito de iniciar um negócio e parecia que um provedor de internet seria algo promissor, mas meu maior interesse é que eu teria internet pra uso próprio, pois naquela época só podia acessar por interurbano pra Porto Alegre ou através de um 0800 do SBT Online que permitia até 10 minutos de navegação gratuíta, a cada ligação, durante um bom tempo. Também participávamos de feiras de informática em Porto Alegre e catávamos tudo quanto é disquete de instalação de provedores que davam 30 dias de acesso grátis
Não sei de que forma, mas conheci e comprei um livro de título parecido com "Linux Primeiros Passos" que vinha com uma distribuição chamada Caldera, pois tava complicado entender como funcionava o Slackware e eu estava querendo saber de tudo que podia sobre linux. Esta foi a distro mais estranha com que me deparei, embora lembre que consegui instalar facilmente, inclusive tinha um servidor X (se não me engano Metro X) que me ofertou um ambiente gráfico funcional.
Por fim, neste biênio 97-98, procurando por Linux na internet, fiquei sabendo da Conectiva, empresa brasileira que tinha uma distro baseada em RedHat que se chamava Marumbi. De cara comprei estes CDs através do site, nem lembro como foi feito o pagamento. Aliás, eu já estava doido pra que pudesse comprar de tudo que eu precisasse pela internet, só que não existia este serviço ainda, se eu fosse inteligente tinha criado um e-commerce e ficado rico hehehehe :-), mas minha satisfação sempre foi trabalhar com a tecnologia e não tinha um bom "tino" pra negócios.
Sendo assim, 1998 representa minha entrada definitiva para um mundo muito mais maravilhoso e livre, embora eu lembre teve um período de uns 6 meses em que fiquei sem utilizar Linux, não tenho certeza, mas acho que foi por falta de motivação, mas a partir da versão 5.0 da Conectiva, passamos a utilizá-la no CPD da Prefeitura (meu local de trabalho, como funcionário, atual) no servidor e então jamais me distanciei.
Gente, desculpem novamente as longas historinhas.
Um grande abraço a todos
Fiquei maravilhado! Foi em uma edição desta revista, onde em menos de meia página, exaltavam um sistema operacional baseado em Unix para ser usado em PC e que era muito mais poderoso do que o limitado MS-DOS. Diziam que um determinado professor era o responsável por disponibilizar na internet o sistema produzido por um jovem estudante universitário finlandês. Aquilo pra mim era uma notícia salvadora, pois nesta época já abominava o monopólio e a figura do Mr. Gates (sinceramente não sei porque nasceu este sentimento, pois pouco conheço e conhecia sobre a figura deste Sr.). Diziam lá, também, que este sistema operacional, o Linux, podia ser instalado a partir de uma pequena quantidade de disquetes e que um ambiente gráfico também poderia ser instalado a partir de outra pequena quantidade de disquetes.
Imaginem que fiquei muito contente com a notícia e nem ao menos eu tinha um computador. Usava somente o do escritório de contabilidade onde trabalhava e programava somente longe dos olhos do patrão. Era muita adrenalina!
Depois disto, não lembro mais de ver novamente notícias sobre Linux, mas nunca esqueci que ele existia. Fiquei impressionado com a idéia de que era um sistema grátis e que todos podiam usar sem precisar pagar licenças e que eu podia ver o código e alterar (embora eu tivesse a plena consciência de que entender o código de um sistema operacional era coisa pra extraterrestres)
Em 1997, finalmente, adquiri meu primeiro computador, já no mês de janeiro. Passei vários meses fuçando, formatando e instalando windows versão 95, depois versão 98. Neste ano de 1998 foi que tive, então, minha primeira experiência salvadora, adquiri um livro de título parecido com "Como montar um provedor de internet" e com ele, acompanhava um CD de instalação da distribuição Slackware que não lembro a versão. Incrivelmente consegui particionar meu disco rígido e instalar o sistema e deixá-lo funcional sem perder dados!
Nesta época eu gostaria muito de iniciar um negócio e parecia que um provedor de internet seria algo promissor, mas meu maior interesse é que eu teria internet pra uso próprio, pois naquela época só podia acessar por interurbano pra Porto Alegre ou através de um 0800 do SBT Online que permitia até 10 minutos de navegação gratuíta, a cada ligação, durante um bom tempo. Também participávamos de feiras de informática em Porto Alegre e catávamos tudo quanto é disquete de instalação de provedores que davam 30 dias de acesso grátis
Não sei de que forma, mas conheci e comprei um livro de título parecido com "Linux Primeiros Passos" que vinha com uma distribuição chamada Caldera, pois tava complicado entender como funcionava o Slackware e eu estava querendo saber de tudo que podia sobre linux. Esta foi a distro mais estranha com que me deparei, embora lembre que consegui instalar facilmente, inclusive tinha um servidor X (se não me engano Metro X) que me ofertou um ambiente gráfico funcional.
Por fim, neste biênio 97-98, procurando por Linux na internet, fiquei sabendo da Conectiva, empresa brasileira que tinha uma distro baseada em RedHat que se chamava Marumbi. De cara comprei estes CDs através do site, nem lembro como foi feito o pagamento. Aliás, eu já estava doido pra que pudesse comprar de tudo que eu precisasse pela internet, só que não existia este serviço ainda, se eu fosse inteligente tinha criado um e-commerce e ficado rico hehehehe :-), mas minha satisfação sempre foi trabalhar com a tecnologia e não tinha um bom "tino" pra negócios.
Sendo assim, 1998 representa minha entrada definitiva para um mundo muito mais maravilhoso e livre, embora eu lembre teve um período de uns 6 meses em que fiquei sem utilizar Linux, não tenho certeza, mas acho que foi por falta de motivação, mas a partir da versão 5.0 da Conectiva, passamos a utilizá-la no CPD da Prefeitura (meu local de trabalho, como funcionário, atual) no servidor e então jamais me distanciei.
Gente, desculpem novamente as longas historinhas.
Um grande abraço a todos
Historinhas pra boi dormir. Parte 003!
Quero começar a postar alguma coisa sobre software livre desde já para que eu tenha chance do Augusto citar meu blog no br-linux.org :-)
Brincadeiras a parte, gostaria de concluir minha saga pré-software livre, para então, dedicar-me de corpo e alma ao mundo livre.
Não sei se acontece com muitas pessoas, mas até eu concluir o segundo-grau, sempre tive como referência temporal dos acontecimentos, também a série/ano escolar. Acredito que os acontecimentos começaram a tornar-se relevantes em minha memória a partir de 1985:
Agora, vamos às tecnologias de software livre!
Brincadeiras a parte, gostaria de concluir minha saga pré-software livre, para então, dedicar-me de corpo e alma ao mundo livre.
Não sei se acontece com muitas pessoas, mas até eu concluir o segundo-grau, sempre tive como referência temporal dos acontecimentos, também a série/ano escolar. Acredito que os acontecimentos começaram a tornar-se relevantes em minha memória a partir de 1985:
- Primeira série 1985 - voltei a morar em Tramandaí
- Segunda série 1986 - Copa do Mundo no México, Brasil derrotado pelos franceses
- Terceira série 1987 - fui morar em Itati
- Quarta série 1988 - Olimpíadas de Seul
- Quinta série 1989 - voltei a morar em Terra de Areia, minha cidade atual
- Sexta série 1990 - Copa do Mundo na Itália, Brasil sofre derrotado para o Maradona e Canija
- Sétima série 1991 - null. Só pra citar então, passei a conseguir me habituar a escola que já estava a 3 anos
- Oitava série 1992 - Olimpíadas de Barcela, só lembro que foi muit legal
- Primeiro Ano 1993 - Escola nova, particular, cursava contabilidade
- Segundo Ano 1994 - Copa do Mundo nos EUA, finalmente o Brasil brilha pela estrela de Romário
- Terceiro Ano 1995 - Grêmio bi da Libertadores e finalmente formado!
- 1996 - ingressei no curso de Processamento de Dados (sendo que foi extinto e passei ao curso de Sistemas de Informação), na Ulbra. Grêmio bicampeão Brasileiro e Olimpíadas de Atlanta (foi a que mais assisti seus eventos pela TV, pois estava de férias)
- 1997 - Grêmio tricampeão da Copa do Brasil
- 1998 - Copa do Mundo e novamente o Brasil perde pra França
- 1999 - null
- 05 de janeiro de 2005, iniciou-se minha relação com a Katy
- 09 de dezembro de 2007, selamos nosso noivado (com direito a pedido surpresa :-)
Agora, vamos às tecnologias de software livre!
Historinhas pra boi dormir. Parte 002!
Já que estou aqui, "quente" da última postagem, porque não continuar?
"Você suspira pelo dia em que os homens eram homens e escreviam seus próprios drivers de dispositivos?" (Torvalds, acredito que em 1991. Fonte http://www.eduardostefani.eti.br/index.php?acao=verartigo&warLink=./artigos/art0020.php)
Não sou desta época, o que não significa que eu não era homem! :-) Ainda sou novinho perto desta turma maravilhosa, que embora distantes gerações (Stallman a Linus, só para ilustrar), tenham feito deste mundo um lugar melhor para se viver, pelo menos para nós, fuçadores de computadores e amantes da liberdade.
Quando iniciei era tudo muito mais fácil (é como consigo ver hoje). Só havia CLIPPER e MS-DOS, mas isto não significa que eu tenha iniciado meus contatos com computadores lá na década de 1980, foi exatamente em 1994, mas como moro em um pequena cidade do interior do RS, as novidades (US$ 8-|), custavam muito a chegar.
Aliás, antes do CLIPPER, na verdade nosso contato maior (nosso digo dos 4 ou 5 programadores de minha cidade), foi com dBase ou FoxBase, para depois "evoluirmos" para o CLIPPER Summer'87, 5.0 e, finalmente, 5.2.
Que época de ouro, lembro-me que ficava fascinado por saber que conseguia, depois de uns 2 anos de prática, achar que sabia decor todos as funções da biblioteca básica do CLIPPER e pensar que poderia codificar qualquer tipo de processamento em algorítmo. Eu tinha nesta época 17 anos. E é verdade que em muitos momentos prestei uma grande ajuda em alguns algorítmos cabeludos para meu chefe Amaury Hertzog, a quem eu tenha uma grande gratidão por concluir que foi o principal responsável por eu poder trabalhar com tecnologia, e ao amigo Arno que muitas vezes pude olhar seus códigos em poucos minutos e dizer-lhe uma solução para o qual ele estava a horas procurando.
Bom, antes que pensem "iii, agora começou a se achar, se dizendo o Master of Universe do CLIPPER", era porque na verdade, pelo menos em 99% das vezes eram coisas simples, mas que nós, programadores de meia-tigela, que não tínhamos noção nem do ABC de lógica, penávamos pra resolver. Por isto reitero que hoje vejo o quanto éramos ingênuos, pois na verdade estávamos engatinhando quando se tratava de programar computadores, mas nem por isto repito que foi uma época mágica, pois podíamos tudo.
Não posso esquecer de citar meu colega de trabalho, Fabiano, que desde cedo tinha um espírito empreendedor, era da tecnologia, mas acredito que seu maior dom sempre foi fazer negócios, pelo menos ele transparecia isto, ou seja, a finalidade da tecnologia pra ele era alavancar negócios, assim como é hoje para a maioria das pessoas, mas eu, como adolescente e fuçador, achava fascinante trabalhar com a tecnologia, muito mais do que gerar negócios com ela.
Até logo
[]'s
"Você suspira pelo dia em que os homens eram homens e escreviam seus próprios drivers de dispositivos?" (Torvalds, acredito que em 1991. Fonte http://www.eduardostefani.eti.br/index.php?acao=verartigo&warLink=./artigos/art0020.php)
Não sou desta época, o que não significa que eu não era homem! :-) Ainda sou novinho perto desta turma maravilhosa, que embora distantes gerações (Stallman a Linus, só para ilustrar), tenham feito deste mundo um lugar melhor para se viver, pelo menos para nós, fuçadores de computadores e amantes da liberdade.
Quando iniciei era tudo muito mais fácil (é como consigo ver hoje). Só havia CLIPPER e MS-DOS, mas isto não significa que eu tenha iniciado meus contatos com computadores lá na década de 1980, foi exatamente em 1994, mas como moro em um pequena cidade do interior do RS, as novidades (US$ 8-|), custavam muito a chegar.
Aliás, antes do CLIPPER, na verdade nosso contato maior (nosso digo dos 4 ou 5 programadores de minha cidade), foi com dBase ou FoxBase, para depois "evoluirmos" para o CLIPPER Summer'87, 5.0 e, finalmente, 5.2.
Que época de ouro, lembro-me que ficava fascinado por saber que conseguia, depois de uns 2 anos de prática, achar que sabia decor todos as funções da biblioteca básica do CLIPPER e pensar que poderia codificar qualquer tipo de processamento em algorítmo. Eu tinha nesta época 17 anos. E é verdade que em muitos momentos prestei uma grande ajuda em alguns algorítmos cabeludos para meu chefe Amaury Hertzog, a quem eu tenha uma grande gratidão por concluir que foi o principal responsável por eu poder trabalhar com tecnologia, e ao amigo Arno que muitas vezes pude olhar seus códigos em poucos minutos e dizer-lhe uma solução para o qual ele estava a horas procurando.
Bom, antes que pensem "iii, agora começou a se achar, se dizendo o Master of Universe do CLIPPER", era porque na verdade, pelo menos em 99% das vezes eram coisas simples, mas que nós, programadores de meia-tigela, que não tínhamos noção nem do ABC de lógica, penávamos pra resolver. Por isto reitero que hoje vejo o quanto éramos ingênuos, pois na verdade estávamos engatinhando quando se tratava de programar computadores, mas nem por isto repito que foi uma época mágica, pois podíamos tudo.
Não posso esquecer de citar meu colega de trabalho, Fabiano, que desde cedo tinha um espírito empreendedor, era da tecnologia, mas acredito que seu maior dom sempre foi fazer negócios, pelo menos ele transparecia isto, ou seja, a finalidade da tecnologia pra ele era alavancar negócios, assim como é hoje para a maioria das pessoas, mas eu, como adolescente e fuçador, achava fascinante trabalhar com a tecnologia, muito mais do que gerar negócios com ela.
Até logo
[]'s
Historinhas pra boi dormir. Parte 001!
Incrivelmente passa-me na idéia que uma pequena quantidade de pessoas possa vir a acompanhar minhas postagens, embora minha razão faça-me entender que eu esteja sendo um tanto otimista :-)
Neste espaço algumas pessoas poderão conhecer um pouquinho sobre o que/como penso e em que trabalho. Aliás, acredito que somente minha adorada noiva, amor da minha vida e futura esposa, Katy, possa interessar-se, pois é ela quem demonstra prazer em "usar" seu precioso tempo comigo.
Eis minha mais preciosa riqueza!
Neste espaço algumas pessoas poderão conhecer um pouquinho sobre o que/como penso e em que trabalho. Aliás, acredito que somente minha adorada noiva, amor da minha vida e futura esposa, Katy, possa interessar-se, pois é ela quem demonstra prazer em "usar" seu precioso tempo comigo.
Eis minha mais preciosa riqueza!
Uma deusa, uma louca, uma feiticeira, meu Deus ela é D+
quarta-feira, 2 de janeiro de 2008
Mundo novo, ano novo!
À aurora deste novo ano, antes de tudo, fica a gratidão a Deus e a todos que fizeram de 2007 um ano maravilhoso e o desejo de que 2008 seja, no mínimo, melhor!
Assinar:
Postagens (Atom)