sexta-feira, 21 de dezembro de 2007

Embebe em álcool e põe

Não foi a situação mais constrangedora pela qual já passei, mas é o máximo de constrangimento que eu me atrevo a passar neste blog.

Aconteceu há alguns meses. Fui à dentista pra dar uma olhada num dente que estava me incomodando. Conheço-a há muitos anos e o nosso papo é sempre bem agradável. Cheguei e esperei um pouco enquanto ela terminava uma consulta. Na minha vez ela me pediu um tempinho pra arrumar as coisas, já que era tarde e sua secretária já havia ido embora. Aproveitei pra iniciar o papo falando do assunto padrão: filhos. Os meus estavam gripados e tiveram febre naquele dia.

Eu falava disso em pé, na porta da sala do consultório, enquanto ela ia de um lado pro outro arrumando as coisas. Quando eu falei de febre ela parou, me encarou seriamente e disse:

- Sabe, eu fiquei sabendo esses dias de uma técnica ótima pra tirar a febre sem precisar de remédio.

Parecia importante e eu prestei atenção enquanto ela explicava:

- Você pega uma meia, embebe em álcool e põe.
- No ânus? Eu perguntei assustado.
- Não! Ela retorquiu encabulada. No pé!


(Podem terminar de rir... Eu espero.)


Eu sei... parece inacreditável que eu tenha dito aquilo. Mas depois de ter um acesso de riso na frente dela que durou uns dois minutos eu consegui me acalmar e tentei colocar panos quentes. Nessas horas é melhor ficar quieto pra não piorar as coisas. Mas eu não me lembrei disso e falei:

- É. Se fosse, curava tudo, né?

Não podia ficar muito pior do que isso. Durante toda a consulta eu me esforcei pra prestar atenção à conversa mas sem muito sucesso. Virava e mexia e lá vinha aquela risada impossível de evitar. Uma semana depois do incidente eu ainda tinha ataques de riso nos momentos menos convenientes. Minha esposa já não agüentava mais.

Mas eu tentei aproveitar este tempo pra entender como é que aquilo pôde acontecer.
Não, justificar não, pois é impossível. Mas eu queria encontrar uma explicação pra aquela idéia estapafúrdia ter passado pela minha cabeça.

A explicação que encontrei é a seguinte. Em primeiro lugar, quando ela começou a falar da tal "técnica" eu tive a nítida impressão de que ela havia abaixado a voz, como se estivesse tomando cuidado pra não falar alto demais. É bem possível que isso não tenha ocorrido de verdade e que tenha sido uma falsa impressão decorrente do fato de ela ter parado de fazer o que estava fazendo pra falar do assunto. Pode ser, também, que eu simplesmente tenha construído esta memória na tentativa de encontrar alguma explicação pra minha escorregada. Não sei. Mas alguma coisa na atitude dela sinalizou pra mim que poderia haver algo de "inusitado" na técnica que ela estava pra me explicar.

Em segundo lugar, quando ela disse "embebe em álcool e põe" ela fez um movimento insinuante com a mão direita. Primeiro ela uniu as pontas dos cinco dedos e os apontou pra baixo. Depois ela fez um movimento rápido de rotação com o pulso fazendo os dedos apontarem para o teto. Não sei quanto à vocês, mas por mais que eu pense sobre o assunto eu não consigo imaginar alguém fazendo este movimento pra calçar uma meia.

Nos poucos décimos de segundo que se passaram entre ela dizer "e põe" e eu responder "no ânus?" meu cérebro construiu uma imagem inusitada e totalmente diferente da que ela tentava representar. E diante do espanto que a imagem me causou, não houve tempo para eu me censurar e me impedir de proferir aquela obcenidade.

Mas não foi tão ruim como pode parecer. Afinal, nós nos conhecemos há bastante tempo. A única coisa que me incomoda agora é não saber o que ela ficou pensando depois. Quer dizer, ela também deve ter construído a sua própria teoria sobre a minha reação. Espero que eu não tenha ficado muito mal na fita...

Acho que não. Afinal, eu escrevi este post alguns dias depois do incidente, quando a memória ainda estava vívida. Desde então já estive no consultório dela outra vez e não houve nenhuma rememoração constrangedora. Só por isso resolvi finalmente publicar minha história.

Agora é com vocês. Ajudem-me a me sentir melhor contando as suas próprias experiências constrangedoras e fazendo-me acreditar que todo mundo passa por isso uma vez ou outra.

sexta-feira, 14 de dezembro de 2007

Futuro Maquiavel

A dor de barriga do meu filho continuou hoje. Os exames de ontem não mostraram nada, mas ainda havia uma possibilidade de ser apendicite. Liguei pro médico e fomos vê-lo no final da tarde. Desta vez ele foi taxativo dizendo que não há mais possibilidade de ser apendicite, porque depois de 48 horas já deveríamos ver outros sintomas. O negócio é tomar canja-de-galinha e Luftal.

Enquando voltávamos pra casa fomos conversamos sobre feedback. Hoje cedo eu fui à escola pra reunião final do 4º ano. Mais uma vez saí de lá todo orgulhoso. O professor o elogiou bastante e eu confesso, com certo embaraço, que cheguei a gostar de algumas das poucas críticas, como a de que ele tem aumentado as "brincadeiras" em classe por estar-se tornando "muito popular".

Por coincidência hoje eu também fui avaliado pelo meu chefe. Aproveitei pra contar pro meu filho como foi esta experiência, explicando que a maioria das pessoas é "avaliada" a vida toda e que, embora às vezes isso seja desconfortável, é melhor tentarmos encarar as críticas como oportunidades. E blá, blá, blá... eu juro que ele estava interessado. :-)

Antes de chegar em casa, passamos na farmácia pra comprar umas coisinhas. A essa altura o papo já tinha ido fundo e eu não me lembro exatamente o que foi que eu disse que mereceu os seguintes comentários dele, que eu fiz questão de anotar num papelzinho pra não esquecer:

- Se você não sabe mentir você não sabe ganhar.
- Hein?
- A sinceridade nem sempre é o melhor caminho.
- Onde é que você leu isso, filhão?
- Eu não li. Eu raciocinei.

Pode?

Já dei uma batida no quarto dele mas não achei nenhuma cópia escondida de "O Príncipe". Não sei, não... estamos lendo juntos o "Pai Rico, Pai Pobre" e isso pode não estar sendo muito educativo. Preciso ser mais cuidadoso. :-)

Confundindo a anatomia

Ontem levei meu filho ao médico porque ele estava sentindo dor de barriga desde a noite anterior. O doutor apertou, escutou, perguntou, brincou e me pediu pra fazer uma radiografia e uma ultra-sonografia só pra descartar a possibilidade de ser um apendicite. Sempre achei que a dor de um apendicite era do lado direito mais pra baixo do umbigo e a dor que ele sentia era mais pra cima. Mas o doutor explicou que em alguns casos o apêndice fica virado pra trás, o que atrasa os sintomas e muda a posição da dor. Como ele não tinha tido febre ainda, o doutor não estava muito preocupado, mas o fato de ele estar andando meio curvado pra frente era sintomático.

Meu filho ficou um tanto encucado. Enquanto íamos pro laboratório pediu pra eu explicar o que era "aquilo que o médico falou" e eu aproveitei pra lhe dar uma aula grátis sobre A Teoria da Evolução e a Inutilidade do Apêndice.

Ele se acalmou e não falamos mais sobre o assunto. Esperamos, fizemos a radiografia, esperamos mais um tanto e fomos pra sala da ultra-sonografia. A enfermeira o deitou e nos deixou à vontade dizendo que o médico viria logo. Mas ele não veio. Demorou uns dez minutos, no mínimo.

Durante esse tempo, meu filho ficou deitado e rindo de umas piadas sem graça que eu ia contando. Mas, sua cabecinha não tinha parado de pensar "naquilo que o médico falou" e ele estava é com um nervosismo contido.

Depois de uma pausa entre uma piada e outra ele começou a apalpar a barriga.

- Tá doendo, filhão?
- Só um pouquinho, pai.

Ele foi apalpando até embaixo do umbigo.

- Pai. Onde é que fica o útero?
- Hein?
- O útero. Onde é que fica?

Cheguei a pensar que a escola estava dando aulas de educação sexual antes da hora.

- Bem... nas mulheres o útero fica aí embaixo do umbigo, onde você está apalpando.
- Qué dizê... aquele negócio que o médico falou que eu posso ter.
- Rá. É apendicite: uma inflamação no apêndice, que fica aí embaixo do umbigo, do lado direito.
- Ah. E o que que é útero?
- É onde os bebês crescem na barriga das mulheres.

Rimos bastante, até quase o médico chegar.

Depois da ultra-sonografia, fomos esperar o resultado e ficamos vendo umas revistas. Depois de uns minutos ele perguntou:

- Pai, o que é aprose?
- Hein?
- Aquilo que eu posso ter?
- É "apendicite", não aprose.
- Ah!
- Deixa eu anotar essas barbaridades que você tá dizendo num papelzinho aqui pra eu não esquecer e poder contar pra mamãe.



domingo, 9 de dezembro de 2007

Splitting hairs

split hairs: to argue about whether unimportant details are correct

Sou fã de Perl porque me permite ser sucinto como em nenhuma outra linguagem.

Esta semana descobri um bug num velho script que eu uso pra processar o relatório produzido pelo comando " bpdbjobs -report -all_columns" do NetBackup. O relatório é um arquivo texto no qual cada linha tem um número variável de campos separados por vírgulas.

Até aí, nada demais. Se eu tiver a linha na variável $line, a função "split" separa os campos nas vírgulas e os atribui ao array @fields trivialmente:

@fields = split /,/, $line;

Só que alguns campos deste relatório podem conter vírgulas, as quais são "escapadas" com barras invertidas, i.e., "\,". O split anterior não entende essas vírgulas escapadas e vai tratá-las indevidamente como separadoras de campos.

O que queremos, então, é quebrar a linha nas vírgulas, mas apenas naquelas que não sejam precedidas de uma barra invertida. Sem problemas... hora de complicar um pouquinho a expressão regular.

@fields = split /(?<!\\),/, $line;

O "ruído" entre parêntesis é um zero-width negative lookbehind (ZWiNLoB). Ele indica que antes da vírgula não pode haver uma barra invertida. Note que o caractere com o qual o ZWiNLoB vai "casar" não fará parte do separador de linha, que continuará a ser somente a vírgula.

Muito bem, parecia tudo certo até que eu rodei novamente o script e percebi que ainda havia problemas. Algumas linhas ainda não estavam sendo quebradas corretamente. Desta vez o problema eram alguns campos que terminavam com uma barra invertida, a qual também era escapada por outra barra invertida. Por exemplo:

...,C:\\,...

Note que a vírgula não está escapada, sendo efetivamente um separador de campo.

E agora? A primeira coisa que pensei foi em usar um ZWiNLoB que case com uma barra não precedida por outra.

@fields = split /(?<![^\\]\\),/, $line;

Hmmm... mas não iria funcionar. E se o campo terminasse em duas barras?

...,C:\\\\,...

Por outro lado, se o campo termina em uma ou mais barras, como cada uma delas deve ser escapada o número total de barras antes da vírgula deve ser necessariamente par, certo? Portanto, o que eu preciso é de um ZWiNLoB que case com um número ímpar de barras. (Lembre que o ZWiNLoB é "negativo".)

@fields = split /(?<![^\\](?:\\\\)*\\),/, $line;

Só que o Perl reclamou:

Variable length lookbehind not implemented in regex; marked by <-- HERE in m/(?<![^\\](?:\\\\)*\\), <-- HERE /

Os ZWiNLoBs têm uma restrição forte: eles devem especificar strings de tamanho fixo, o que significa que eu não vou conseguir usá-los pra indicar uma vírgula não precedida por um número ímpar de barras...

OK, o ZWiNLoB na expressão anterior tinha a função de garantir que eventuais barras invertidas em um campo não precedam uma vírgula escapando-a. Mas a expressão como um todo quer mesmo é casar com uma vírgula, i.e., com o separador dos campos, pois eu a estou usando como argumento da função split.

E se eu tentar uma abordagem inversa? E se ao invés de tentar encontrar os separadores eu tentasse encontrar os campos? Nesse caso, a parte de tamanho variável da expressão não estaria num ZWiNLoB.

Pensei de cara numa abordagem interativa:

push @fields, $1 while $line =~ s/(.*?(?<!\\)(?:\\\\)*),//;
push @fields, $line;

A primeira linha remove o primeiro campo de $line e o anexa ao array @fields, até que sobre apenas o último campo, que não é sucedido por uma vírgula, e que é anexado na segunda linha. Ainda há um ZWiNLoB, mas ele tem um tamanho fixo, casando com um caractere diferente de barra invertida.

Não gostei muito. Eu preferiria não ter que tratar o último campo de modo especial. Logo percebi que com um pequeno ajuste na expressão regular isso seria possível.

push @fields, $1 while $line =~ s/(.*?(?<!\\)(?:\\\\)*)(?:,|$)//;

Desse modo, os campos podem ser sucedidos por uma vírgula ou pelo final da string.

Eu estava quase satizfeito, pois a solução acabou tendo uma linha apenas, mas o split era tão mais simples...

De qualquer modo, eu ainda precisava testar. E qual não foi a minha surpresa quando o script passou a demorar dezenas de segundos a mais que a versão anterior. Por um lado ele parecia estar correto, o que era um avanço. Mas alguma coisa o havia tornado muito lento e só podia ser aquele loop.

O problema é que o relatório tem algumas linhas realmente grandes, com quase um milhão de caracteres. Como a cada iteração a linha tem um campo removido, toda essa manipulação de strings parece ser bastante pesada.

Mas eu não preciso realmente remover os campos. Basta começar a procurar um campo a partir do final do campo anterior. (Eu não estou sendo fiel à história aqui, pois não cheguei a pensar nessa solução antes de começar a escrever isso aqui. Mas, em retrospecto, acho que ela cabe logicamente entre as duas últimas.)

push @fields, $1 while $line =~ /(.*?(?<!\\)(?:\\\\)*)(?:,|$)/g;

A mudança é sutil. Troquei apanas o operador "s///" pelo "//g". Como a expressão está sendo avaliada num contexto escalar, a cada iteração a busca começa a partir do final do trecho encontrado na iteração anterior. A vantagem é que a linha não precisa ser modificada, o que deve evitar grande parte da ineficiência anterior.

Mas, se eu quero uma lista de campos eu não preciso necessariamente encontrá-los um a um. Afinal, a mesma expressão regular anterior, quando avaliada num contexto de lista, retorna de uma vez todos os trechos encontrados dentro dos parêntesis.

Et voilá, eis minha solução final.

@fields = $line =~ /(.*?(?<!\\)(?:\\\\)*)(?:,|$)/g;

Ah, mas é claro que no script eu não usei uma variável explícita chamada $line. A linha estava realmente na variável implítica $_, o que me permitiu escrever a solução assim.

@fields = /(.*?(?<!\\)(?:\\\\)*)(?:,|$)/g;

Linda, não? E sucinta. E eficiente também. Como convém a um script Perl que se preze.

quinta-feira, 29 de novembro de 2007

Bug no cliente FTP do Windows

Dizem que uma imagem vale mais que mil palavras, então vejam esta:

Pra quem não se deu ao trabalho de entender, o enredo é o seguinte. Estou numa janela de comandos do Windows e num diretório que contém um arquivo chamado file.txt contendo oito bytes. Daí eu invoco o comando de linha "ftp" e me conecto a um servidor remoto. Verifico que não existe no servidor FTP um arquivo com o mesmo nome e me engano usando o comando "get file.txt" ao invés do "put file.txt".

A mensagem de erro "550 file.txt: No such file or directory" é bastante clara e indica exatamente o que eu fiz de errado. Mas... ao sair do comando ftp e listar o conteúdo do diretório local sou surpreendido ao ver que o arquivo file.txt foi truncado e está com zero bytes!

Parece que quando fazemos um "get" no ftp do Windows ele abre o arquivo pra escrita antes de verificar se o arquivo existe no servidor FTP. Nesse caso, a abertura pra escrita trunca o arquivo local e o deixa com tamanho 0.

Um colega me disse que no Windows 98 e no Windows 2000 o arquivo local é removido do diretório. O exemplo acima foi executado num Windows XP, que não remove o arquivo mas o deixa vazio. Parece que eles estão melhorando... alguém pode testar no Windows Vista pra ver se já está corrigido? :-)

Em tempo, testei na minha máquina Linux (Kubuntu 7.04) e o problema não ocorre.

O Futuro é Wiki

É o título de um artigo muito interessante do professor Milton Campanário da FEA-USP.

Ele comenta os assuntos tratados em dois best-sellers recentes: Wikinomics e The Wealth of Networks. Quem se interessa por economia, inovação, software livre, propriedade intelectual ou produção colaborativa, vale a pena conferir.

quinta-feira, 22 de novembro de 2007

Ruby on Rails

Assisti ontem a uma palestra excelente sobre Ruby on Rails. É a terceira ou quarta palestra sobre RoR a que eu assisto. Descontando a do próprio David Hansson a que eu assisti no FISL 6.0 esta foi a mais detalhada e interessante. A impressão que eu tive depois de conversar com algumas das 30 pessoas que estavam lá é que o Bill Coutinho da Dextra conseguiu entusiasmar várias delas.

Além dos tutoriais tradicionais e da geração automática de código (scaffold!) o Bill apresentou uma perspectiva mais atual e mais madura sobre a utilização do framework. Alguns pontos que o Bill ressaltou na palestra:
  • A Dextra mediu um incremento de 100% na produtividade nos primeiros projetos RoR executados por programadores com experiência em Java.
  • Programadores Java têm pouca dificuldade em aprender Ruby e RoR.
  • O JRuby permite rodar
    aplicações RoR dentro de servidores de aplicação Java como o Tomcat e o
    JBoss, o que possibilita a integração de uma interface web RoR com
    bibliotecas Java.
  • RoR é ótimo para desenvolver aplicações web baseadas em bancos de dados. Fora disso, use outra coisa.
  • Programar em Ruby é muito mais legal que programar em Java. :-)

terça-feira, 13 de novembro de 2007

Google Android

Há um artigo interessante sobre lançamento do SDK do projeto Android do Google. Pra quem ainda não viu, o Android é uma plataforma aberta para dispositivos móveis baseada em Linux e Java.

O Google junto com outras 34 empresas formaram o Open Handset Alliance pra desenvolver esta tecnologia que parece que vai estar disponível comercialmente no segundo semestre de 2008.

O autor do artigo já está chamando o Android de tecnologia de ruptura. Será?

segunda-feira, 12 de novembro de 2007

SGBDs orientados a colunas

Semana passada assisti a uma palestra do Eduardo Sato da Sybase na qual ele explicou a tecnologia por trás do Sybase IQ, um banco de dados relacional usado em ambientes analíticos, como data warehousing e aplicações de Business Intelligence em geral.

A tecnologia em questão se chama column-oriented DBMS e é essencialmente uma forma não-tradicional de armazenar os dados das tabelas em disco. Normalmente, os dados de uma tabelas são armazenadas por linhas, i.e., todos os campos de uma linha são armazenados de maneira contígua no disco. Já num SGBD orientado a colunas os dados de uma tabela são armazenados por coluna, i.e., todos os campos de uma coluna da tabela são armazenados de maneira contígua.

Essa diferença aparentemente trivial modifica totalmente as características de desempenho do banco de dados. O armazenamento por linhas é ideal para acessos de linha inteira. Pense num insert ou num update que modifique todos os campos da linha. Ou mesmo, num select *. De fato, a forma de armazenamento por linha é a que garante melhor desempenho para a maioria das aplicações transacionais.

Agora pense num ambiente analítico, no qual os inserts e updates são quase inexistentes e a maioria absoluta das consultas são de selects. Normalmente, as tabelas usadas nestes ambientes são "tabelões", com um grande número de colunas, resultado da agregação de várias tabelas extraídas de sistemas transacionais, planilhas e arquivos texto. Além disso, em ambientes analíticos é comum ocorrerem consultas ad hoc para as quais não se pode planejar a manutenção de índices e que acabam resultando muitas vezes na necessidade de full scans nas tabelas para executar a consulta.

O exemplo concreto que o Eduardo Sato usou na palestra pra explicar os ganhos que podem ser obtidos envolvia uma tabela com 10 milhões de linhas de 800 bytes cada uma. Considerando uma representação em disco usando páginas de 16KB, pra fazer um full scan nesta tabela seriam necessários 500 mil I/Os. Se esse full scan tivesse sido motivado por um select envolvendo apenas três colunas da tabela, usando uma representação em colunas poderia reduzir o número de I/Os para apenas 234. (Não é 234 mil. É 234 unidades!)

Além do ganho de eficiência nos selects, a representação em colunas também consegue ser mais compacta que a representação em linhas. Uma razão é que os campos NULL podem ser indicados pela mera ausência, ao passo que na representação em linhas eles precisam ser indicados por um código explícito. Outra razão é que é muito mais fácil compactar dados de um tipo único que dados de múltiplos tipos, como ocorre na representação em linhas.

Ainda outra vantagem da representação em colunas é que as alterações de esquema são muito mais fáceis e rápidas. Afinal é muito mais fácil inserir, remover ou alterar uma coluna quando ela está armazenada de forma contígua que quando seus dados estão "espalhados" pelas linhas da tabela.

O Sybase IQ não é a única implementação desta tecnologia. A página da wikipedia mostra uma lista de implementações concorrentes. Achei duas promissoras: o MonetDB e o Vertica.

quinta-feira, 8 de novembro de 2007

Evidence Based Scheduling

Eu não acredito em cronogramas, mas que eles existem, existem. Bem, nem todo cronograma é furado... os ferroviários ingleses que o digam. :-)

O Joel Spolsky, que é um cara inteligente e experiente, diz que os desenvolvedores de software em geral não gostam de fazer cronogramas por duas razões. Primeiro, porque é um saco. Segundo, porque ninguém acredita mesmo que o cronograma seja realístico.

Mas, como dono de uma empresa de software, o Joel deve ter seu "lado administrador" sempre procurando encontrar uma forma de "controlar as coisas". Sabe como é: planejamento, planilhas, cronogramas...

O fato é que ele bolou um novo método de produzir cronogramas baseado no método de Monte Carlo e conseguiu me fazer acreditar que funcione. Ele chamou o método Evidence Based Scheduling, ou EBS, que parece bastante apropriado.

Para os que gostam (e principalmente para os que, como eu, não gostam) de cronogramas, eu sugiro a leitura do artigo em que o Joel explica detalhadamente o método. Para os demais (hã?) aqui vai um resumo:

O início não tem novidade. O grupo de desenvolvedores que vai trabalhar num projeto faz uma WBS detalhada do mesmo, quebrando-o em atividades de, no máximo, 16 horas. Cada atividade é atribuída a um desenvolvedor e é ele quem decide o tempo que vai levar para executá-la.

Todas as estimativas devem ser registradas e associadas ao desenvolvedor que as fez. É importantíssimo que cada desenvolvedor registre também o tempo que ele efetivamente gastou na execução das tarefas. Deste modo, ao longo do tempo, vai-se acumulando informações sobre a capacidade de "estimação" de cada desenvolvedor.

Depois de algum tempo, é possível plotar um gráfico para cada desenvolvedor, correlacionando suas estimativas com suas respectivas execuções. A idéia é que "estimadores" experientes tendem a cometer sempre os mesmos erros. Já estimadores inexperientes tendem a variar bastante nos seus erros.


De posse desse histórico e do conjunto de estimativas da WBS do novo projeto, o sistema gera 100 simulações diferentes usando, cada vez, um valor aleatório do histórico de erros passados de cada desenvolvedor para projetar o tempo de execução efetivo de cada atividade. O resultado dessas 100 simulações é um gráfico mostrando a probabilidade de que o projeto termine em um intervalo de datas dentro do qual caíram todas as 100 simulações.


O que é bacana neste método é que ele não determina uma data mágica, mas sim um intervalo de datas com probabilidades geradas a partir do histórico de sucesso de cada desenvolvedor individualmente.

O artigo original mostra várias outras vantagens do método e sugere algumas técnicas gerais para tornar o exercício mais previsível. Vale realmente a pena lê-lo.

Eu estou convencido de que o método tem mérito, mas isso não quer dizer que ele funcione. É óbvio que ele depende fortemente de que os desenvolvedores registrem suas estimativas e suas execuções o mais fielmente possível e também que produzam muitas estimativas pra aumentar a qualidade do histórico. Mas mais que tudo, o método supõe que a capacidade de estimativa dos desenvolvedores tenda a se estabilizar à medida em que eles ganham experiência. Isso parece fazer sentido, mas não conheço estudos empíricos que validem esta suposição.

Outra coisa importante é que não dá pra fazer as simulações na mão. É preciso usar um sistema que automatize o processo. Mas o Joel cuidou disso também. Ele adicionou um módulo de EBS no FogBugz 6.0, a nova versão da sua ferramenta de gestão de projetos. :-)

Banda e latência

Uma colega me procurou dizendo que alguns usuários estão enfrentando um sério problema de lentidão no acesso a um sistema web remoto. Cada transação neste sistema, desde o login até o logout, está demorando da ordem de 50 segundos. A reclamação já foi submetida aos administradores do sistema remoto que fizeram seus testes e disseram que os clientes locais conseguem executar as mesmas transações em dois segundos. Parece óbvio que se trata de um "problema de rede". Mas, a sugestão imediata dos administradores, de "aumentar a banda" do nosso acesso à Internet, pode não resolver o problema.

Como este é um problema comum, resolvi registrar aqui o email que enviei pra colega, pra poder reutilizá-lo no futuro quando outro problema semelhante aparecer. (Personagens e cenários foram modificados para proteger os inocentes. :-)
De fato, o aumento no tempo de acesso parece ser devido às diferentes situações de conectividade de rede entre o cliente e o servidor do sistema. Contudo, nem sempre um aumento de banda resolve esse tipo de problema.

Há duas características de rede que podem influenciar o tempo de resposta de uma transação: banda e latência. Banda é a quantidade de informação que a rede pode transportar por unidade de tempo e latência é o tempo que uma unidade de informação leva pra transitar pela rede de um ponto a outro.

Numa rede local trabalhamos com bandas da ordem de 100Mb/s à 1000Mb/s e latências da ordem de 1ms. Quando trabalhamos com a Internet, tratamos de bandas da ordem de 1Mb/s a 10Mb/s e latências da ordem de 100ms. Ou seja, a banda que temos pra acessar a Internet é 100 vezes menor que a banda de uma rede local e a latência é 100 vezes maior.

Essas duas características influenciam as transações de um sistema de modos diferentes. Há sistemas em que as transações são demoradas e transportam grandes volumes de dados. Imagine um repositório FTP em que as transações são o envio e a recepção de arquivos. Este tipo de sistema é bastante afetado pela banda disponível mas muito pouco afetado pela latência. Pra baixar um arquivo de 1GB da Internet leva mais de duas horas enquanto pra baixá-lo de um servidor local leva só dois minutos.

Outros sistemas são mais afetados pela latência. Imagine que ao invés de o cliente FTP fazer uma requisição para o arquivo inteiro ele precisasse fazer uma requisição para cada bloco de 1MB de dados. O mesmo arquivo de 1GB teria que ser solicitado em 1000 pedacinhos. Imagine também que cada pedaço tivesse que ser recebido antes que o próximo pudesse ser solicitado. Nesse caso, a latência passa a ser mais importante. Se numa rede local com o FTP normal o arquivo pode ser baixado em dois minutos, numa rede com a mesma banda mas com uma latência de 100ms, como ocorre na Internet, a transferência do arquivo levaria 100 segundos a mais devido ao tempo necessário para cada uma das 1000 solicitações de 100ms cada.

Tendo isso em mente é importante analisar o padrão de comunicação do sistema pra determinarmos se a lentidão quando o acesso é via Internet é determinado pela redução de banda ou pelo aumento da latência da rede. Se o padrão de comunicação for determinado por poucas requisições com grande transferência de dados então realmente o aumento na banda pode melhorar a situação. Mas se o padrão for determinado por muitas requisições pequenas, então o aumento de banda não deverá ter efeito significativo.

O ruim nisso tudo é que as soluções na camada de rede ou são caras (aumento de banda) ou inexistentes (não há como reduzir significativamente a latência na comunicação a longa distância).

Eu gostaria de simular o acesso ao sistema pra poder capturar os pacotes de rede e analisá-los pra poder verificar o padrão de comunicação. Parece-me pouco provável que uma aplicação destas tenha grandes volumes de dados trafegando entre cliente e servidor. Não conheço o sistema, mas as aplicações web mais modernas têm incorporado uma série de melhorias na interface utilizando uma tecnologia chamada AJAX. Com ela é possível que entre um clique explícito e outro do usuário o navegador dispare um grande número de requisições HTTP implícitas, o que pode tornar estas aplicações mais sensíveis a um aumento da latência da rede.

Mas isso é apenas conjectura. Se você conseguir um acesso ao sistema e um roteiro de teste eu posso tentar analisar seu padrão de comunicação pra ver se identificamos mais exatamente o problema.
Eu me lembro de ter lido um artigo muito bom sobre isso numa edição antiga da ;login:. Não consegui encontrá-lo, mas achei um outro artigo interessante do Brent Chapman sobre isso. O mais engraçado é que ele resolveu postá-lo exatamente pra poder reutilizá-lo quando tivesse que explicar o mesmo problema no futuro. :-)

quarta-feira, 7 de novembro de 2007

Ética dos profissionais de TI

Li um artigo muito bom sobre o "estado da ética" dos profissionais de TI. Ele conclui que na maioria dos casos, estes profissionais acabam tendo que usar seu próprio juízo na hora de decidir alguma questão ética. Alguns argumentam que parte do problema é que a tecnologia tem a capacidade de distanciar o indivíduo das conseqüências de seus atos, o que nos levaria a minimizar a importância dos delitos.

O artigo sugere que pra resolver o problema seria importante que os profissionais de TI tivessem um código de ética universal, assim como os médicos e os advogados. O código serviria de padrão de conduta geral, devendo ser seguido mesmo que a empresa em que o profissional trabalhe não tenha um código específico. Além disso, deveria existir alguma organização profissional para a TI assim como a OAB para os advogados. Ela deveria ter o poder de cassar habilitações de trabalho para os profissionais que não respeitarem o código.

Já existem algumas iniciativas no sentido de criar códigos de ética ou de conduta pra TI. Em 2003 o SAGE da USENIX publicou o seu Código de Ética para Administradores de Sistemas. Ele foi divulgado no LISA'03. Eu estava lá e me lembro que foi um evento bastante comentado. A ACM é outra instituição importante que tem seu próprio código de ética.

Estes códigos são muito bons, eu acho. Serviriam muito bem como base para políticas internas e regras de conduta. Resta esperar pra ver se eles evoluirão para uma versão universal.

sábado, 27 de outubro de 2007

Diff recursivo com filtro

Às vezes nos deparamos com problemas aparentemente simples mas que nos dão trabalho pra resolver. Não estou reclamando... esses são, normalmente, os problemas mais divertidos e instrutivos.

Ontem um colega mandou o seguinte problema numa lista de discussão:

Srs,

Estou fazendo um diff recursivo, comparando dois diretórios de arquivos de códigos, eu gostaria que neste diff não fosse considerado as linhas com comentários.

Ex:

//linha de comentário

/*
* comentário
*/

Alguém conhece uma maneira de fazer isso?

Ele quer comparar código fonte Java desconsiderando as diferenças dentro dos comentários.

Eu sabia que o comando GNU diff, presente em todas as distribuições Linux, tem algumas opções para desprezar espaços em branco. Dei uma olhada no manpage pra ver se por acaso haveria alguma opção pra desprezar comentários... não custava nada, né?

-E --ignore-tab-expansion
Ignore changes due to tab expansion.

-b --ignore-space-change
Ignore changes in the amount of white space.

-w --ignore-all-space
Ignore all white space.

-B --ignore-blank-lines
Ignore changes whose lines are all blank.

--strip-trailing-cr
Strip trailing carriage return on input.

É um bocado de opção pra ignorar espaço em branco, não é? Tantas opções e, ainda assim, nenhuma me servia. Aliás, isso me fez pensar se essa proliferação de opções específicas não poderia ser evitada com a implementação de uma opção de filtro mais genérica. Quero dizer, o diff poderia suportar uma opção pra qual pudéssemos passar uma expressão regular especificando strings que deveriam ser ignoradas. Ou, talvez, outra opção passando um comando que o diff pudesse chamar para filtrar os arquivos que fosse comparar.

Como não achei nenhuma solução direta no diff, passei a pensar em como remover os comentários do código Java. Se fosse apenas o comentário estilo C++ (//...) eu usaria um sed, mas como há também o comentário tipo C (/*...*/) não pensei duas vezes antes de usar Perl. O script mais conciso e elegante que obtive eu chamei de stripcomments.pl:

#!/usr/bin/perl
$/ = undef; # slurp mode
$_ = <>; # slurp file
s:/*.*?*/::sg; # strip C comments
s://.*::g; # strip C++ comments
print;

Ele lê todo o arquivo em memória e remove os comentários com expressões regulares simples. Com o tamanho da memória dos desktops atuais eu não creio que ler o arquivo todo seja problemático. Qualquer solução mais comedida no uso de memória seria muito mais complexa.

Pois bem, a idéia é passar pro diff o resultado da aplicação deste filtro a cada um dos seus dois argumentos. A melhor maneira que eu conheço pra fazer isso é usando a sintaxe de substituição de processos da bash. O comando seria o seguinte:

diff <(stripcomments.pl file1) <(stripcomments.pl file2)

Hmmm... há duas coisas no resultado deste diff de que eu não gosto. A primeira é que eu prefiro o resultado no formato unified, que eu obtenho com a opção -u. A segunda é que como o diff recebe o resultado do filtro ele não sabe o nome dos arquivos originais.

Descobri ontem que eu posso instruí-lo sobre o nome dos argumentos através da opção -L. O comando final ficou assim:

diff -u -L file1 <(stripcomments.pl file1) -L file2 <(stripcomments.pl file2)

OK, eu já tenho o filtro e já sei como fazer o diff usá-lo. Mas há um problema: meu colega quer um diff recursivo. Logo, eu não posso passar os nomes dos arquivos diretamente.

Estudei um pouco mais e descobri outra opção interessante do diff: a -q, ou --brief. (Só de curiosidade: o comando "man diff | grep '^ *-' | wc -l" mostra que o diff suporta 44 opções diferentes!) Com esta opção o diff não mostra as diferenças em si, apenas o nome dos arquivos diferentes.

Minha idéia final foi a seguinte. Primeiro eu executo um "diff -qr" nos dois diretórios pra descobrir quais arquivos são diferentes. Do resultado disso eu coleciono os pares de arquivos diferentes e comparo cada par com o comando diff acima, utilizando o filtro. O script final eu chamei de diff-java-stripped.pl:


01 #!/usr/bin/perl

02 BEGIN {
03 $ENV{PATH} = '/bin:/usr/bin';
04 $ENV{LANG} = 'C';
05 }

06 use strict;
07 use warnings;

08 my $usage = "$0 DIR1 DIR2\n";

09 my $dir1 = shift or die $usage;
10 my $dir2 = shift or die $usage;

11 my @pairs; # hold pairs of different files

12 open DIFF, "diff -rq $dir1 $dir2 |"
13 or die "Can't exec diff -rq: $!";
14 while (readline(*DIFF)) {
15 if (/^Files (.*) and (.*) differ$/) {
16 push @pairs, [$1, $2];
17 } else {
18 print;
19 }
20 }
21 close DIFF or die "closing DIFF";

22 open BASH, "| bash --norc"
23 or die "Can't exec bash --norc: $!";
24 for my $pair (@pairs) {
25 my ($l, $r) = @$pair;
26 print BASH "diff -u -L '$l' <(stripcomments.pl '$l') -L '$r' <(stripcomments.pl '$r')\n";
27 }
28 close BASH or die "closing BASH";

O primeiro diff é chamado na linha 12 e é processado no loop da linha 14. A saída do comando mostra três tipos de linhas, dependendo do tipo de diferença encontrada:

Only in dir1: file1
Only in dir2: file2
Files dir1/file3 and dir2/file3 differ

Quando um arquivo só existe debaixo de um dos dois diretórios o comando mostra a linha "Only in dir: file". Nesse caso, só estou interessado em mostrar este fato ao usuário.

Quando há dois arquivos diferentes com o mesmo nome dos dois lados, então eu guardo os caminhos de ambos em @pairs para compará-los depois.

O loop da linha 24 obtém cada par encontrado e constrói uma linha de comando para compará-los depois de devidamente filtrados. Cada linha de comando destas é submetida para execução por uma bash invocada a propósito na linha 22.

A definição da variável de ambiente LANG na linha 4 é para garantir que as mensagens do comando diff sejam em inglês independentemente do locale em que o comando esteja sendo executado.

Tá aí. Acho que ficou legal. E vocês?

(Obs: Foi difícil embutir os scripts acima neste post porque o editor do Blogger teimava eu não aceitar alguns caracteres e eu eliminar alguns newlines. Tive até que usar uma sintaxe alternativa na linha 14 porque não consegui fazer a sintaxe normal ser aceita.)

terça-feira, 16 de outubro de 2007

Deduplication

Falando sobre storage, mais especificamente sobre backup, uma das tecnologias mais badaladas ultimamente é a data deduplication, ou de-dup. A idéia básica é detectar redundâncias durante o backup pra reduzir drasticamente a utilização de storage pra cópia. O stream de backup é dividido em blocos e cada bloco é identificado por uma assinatura digital. As assinaturas de todos os blocos copiados são mantidas num banco de dados. Assim, quando um novo bloco tem a mesma assinatura que outro já copiado os dados em si não precisam ser salvos novamente, apenas o banco de dados é atualizado com o índice do novo bloco apontando para o mesmo local em que o anterior foi salvo.

Confesso que até há pouco eu não havia conseguido perceber como é que os fornecedores deste tipo de solução são capazes de anunciar reduções de armazenamento da ordem de 20 ou de até 50 vezes. Não me parecia possível encontrar tanta redundância assim nos dados armazenados em disco.

Mas, acabei de ouvir um podcast no qual o Curtis Preston explica direitinho como a deduplication funciona e como é possível reduzir dezenas de vezes o consumo de storage de backup. O segredo é que o backup é um processo cíclico. Uma política de backup comum é realizar um backup full de todos os discos a cada quatro semanas. Isso significa que a cada quatro semanas todos os dados de um servidor são copiados pra fita novamente. Se usarmos um sistema de de-dup, normalmente a maioria dos dados já estaria armazenada no sistema de backup e não precisaria ser armazenada novamente, como acontece atualmente com nosso sistema de fitas.

Aliás, os sistemas de de-dup normalmente utilizam disco e não fita como storage de armazenamento exatamente porque os dados redundantes precisam ser acessados de modo aleatório e não sequencial durante um restore. A utilização de disco ao invés de fita é mais cara mas tem a vantagem de permitir restores mais rápidos e simultâneos, independentemente do número de unidades de fita disponíveis no momento.

Estou achando que vale a pena.

terça-feira, 25 de setembro de 2007

Lidando com as interrupções

Recebi o seguinte email de um colega:
  > On Monday 24 September 2007, Gustavo Chaves wrote:
>> E aí? Começou o trabalho?

> Comecei sim, e inúmeras vezes para ser sincero. Acho que você
> sabe como é o ambiente aqui no suporte, muitas interrupções...
> O pior é que eu não sei como lidar direito com isso (como você
> lida com isso???)...
É um ciclo. Geralmente começa quando eu volto das férias e não tenho nenhuma pendência acumulada. (A verdade é que eu acabo me esquecendo de todas as pendências não realizadas antes das férias.) Nesse momento eu estou feliz.

Daí eu começo a fazer uma coisa até ser interrompido e eu empilho o estado. Começo a tratar a interrupção e outra ocorre. Mais um push. Quando acaba o dia minha pilha começa a perder os links e no dia seguinte eu já não sei bem por onde começar. Normalmente eu começo por alguma atividade do meio da pilha, que deixa de ser uma pilha de verdade e passa a ser um balaio de tarefas mal-começadas.

Depois de um tempo algumas dessas atividades simplesmente saem do meu inconsciente (do consciente já saíram faz tempo) e ficam perdidas.

Algumas semanas disto e eu já estou estremamente irritado e convontade de dar um basta, falando com o chefe, passando a usar headphones, colando uma placa de não-perturbe nas costas, planejando trabalhar em casa e sonhando com o ambiente de trabalho idealizado no livre Peopleware e no blog do Joel Spolsky.

Mas... pro bem ou pro mal o peso dos anos serve pra frear estes impulsos. Mais de dez anos trabalhando em TI sem ter conseguido resolver o problema me deixam deprimido pensando que ou não há solução ou eu não sou capaz de encontrá-la.

Pra evitar o incômodo da dissonância cognitiva eu acho que meu inconsciente acaba resolvendo o problema dando um dispose geral e zerando minha pilha de atividades. Normalmente as próximas férias já estão chegando e a expectativa de começar zerado de novo já me conforta.

(Não desanime... nada garante que este seja um problema insolúvel.)

Tempestade em copo d'água

No capítulo sobre "comunicação" do livro Producing Open Source Software, Karl Fogel tem uma seção interessantíssima chamada The Softer the Topic, the Longer the Debate na qual ele argumenta que embora uma discussão possa vaguear em qualquer tópico, a probabilidade de que ela vagueie aumenta na medida em que a dificuldade técnica do tópico diminui.

Deste modo, é geralmente mais difícil atingir o consenso em discussões técnicas em que o tópico seja fácil de entender e de se formular uma opinião a respeito e em tópicos "leves" tais como organização, publicidade, patrocínio, etc. Os envolvidos podem participar destas discussões pra sempre, porque não há pré qualificação necessária pra isso nem critérios claros para se decidir (mesmo a posteriori) se uma decisão foi certa ou errada e, porque, simplesmente suportar a discussão por mais tempo é muitas vezes uma tática de sucesso.

domingo, 17 de junho de 2007

O Quereres

Domingão é dia de tirar o atraso do sono acumulado na semana. Se você não tem filhos, é claro. Hoje cedo (não tão cedo) a Juliana me acordou docemente, gritando:

- Quero Toddy!

Eu era o único em casa que ainda estava na cama e resolvi fazer corpo mole pra ver se alguma alma caridosa se compadecia de mim e fazia o Toddy pra ela. Mas quem já estava acordado não tinha muita razão pra se compadecer. Desconfio mesmo que o pedido da Juliana tenha sido redirecionado de outra pessoa.

Eu me fiz de morto. Eu virei pro outro lado. Mas ela não desistia. Resolvi apelar pras cócegas pra ver se ela fugia. Mas ela gostou da brincadeira e resolveu revidar. Quando as táticas de despistamento se esgotaram eu tentei uma abordagem direta e lhe perguntei:

- O que você quer?
- Quero Toddy!
- Mas eu quero ficar na cama, filha.
- Vai fazer Toddy agora!
- Filha, escuta. Você quer Toddy e o papai quer ficar na cama. Por que é que o seu querer é mais importante que o meu?
- Por... que... vo... cê... é... pai!

quarta-feira, 13 de junho de 2007

Trem de pouso

Esse nome nunca fez o menor sentido pra mim até o mês passado quando eu estava passeando em Belo Horizonte. É óbvio que foi coisa de mineiro. Posso até imaginar que tudo começou numa conversa:

- Omi, ocê viu a notícia do avião qui teve di posá de barriga purque os "trem" de pouso num descêru?

Saber perder

Outro dia minha filha Juliana, de cinco anos, veio até mim chorosa e reclamando que seu irmão e sua prima, mais velhos, não a estavam deixando brincar com eles. Perguntei qual era a brincadeira e ela me disse que eles estavam jogando um jogo que ela não conseguia ganhar. Pensei em aproveitar a situação pra explicar pra ela algumas coisas sobre a vida:

- Escuta, filhinha. Você tem que entender que num jogo todos querem ganhar mas só um consegue. Os outros perdem mesmo.
- Mas eles não deixam eu ganhar.
- Você tem que aprender a perder.
- Eu sei perder. Eu não sei é ganhar.

sexta-feira, 25 de maio de 2007

Dia da Toalha

25 de maio é o Dia da Toalha, no qual homenageamos Douglas Adams, autor do Guia do Mochileiro das Galáxias.

Se nada disso faz o menor sentido pra você, "não entre em pânico", é "praticamente inofensivo". Mas também é instrutivo. Saiba que nos seus livros, Douglas Adams abordou a questão fundamental sobre "a vida, o universo e tudo mais", conseguindo, pela primeira vez, encontrar sua resposta cabal e completa: 42.

Ainda tá difícil? Quem sabe algumas imagens possam esclarecer.

Este sou eu lendo atentamente uma passagem importante.


Aqui eu estou demonstrando a minha satisfação por ter sido capaz de compreendê-la:


(Não estou a cara do Mr. Magoo?)

Confiante com meus novos conhecimentos, encontrei-me com outros wanabe-nerds (Andreyev e Daniel).


Zaphod Beeblebrox tirou esta foto ao nos dar carona em sua nave Coração Dourado pra almoçarmos juntos no "restaurante no fim do universo".


"Até mais, e obrigado pelos peixes!"

segunda-feira, 21 de maio de 2007

Filho de peixe...

Ontem eu estava me preparando pra por meu filho pra dormir e comecei dando a bronca padrão pra ele deixar as coisas arrumadas pra manhã seguinte. Aproveitei e mandei-o guardar um spray desodorante que devia estar no escritório mas que estava no banheiro dele. Enquanto ele cumpria minhas ordens eu fui me preparar.

Voltando do banheiro eu vi uma lanterna sobre a minha cama. A vontade de dar outra bronca chegou a passar pela minha cabeça, mas fiquei com pena e decidi eu mesmo ir guardá-la. Só que o lugar dela é na cozinha, do outro lado da casa. Saindo do meu quarto eu vi que a porta do corredor já estava fechada. Aí bateu aquela preguiça e eu resolvi deixar a lanterna na sala de TV pra guardá-la na manhã seguinte.

Depois de todas as minhas broncas, confesso que senti um certo desconforto. Era como se eu estivesse enganando meu próprio pai, adiando uma ordem direta dele. Por isso, decidi deixar a lanterna escondida atrás da TV. Coloquei-a com cuidado pra ela não rolar pro chão e já ia voltando quando notei um pequeno objeto sobre o móvel, encostado na TV. Era o spray que eu havia mandado meu filho guardar no escritório.

O danado teve a mesma idéia!

Não é incrível como os filhos podem sair aos pais?

quarta-feira, 16 de maio de 2007

/net/bin SNAFU

Pois é... ontem eu falei do lado bom de ser administrador de sistemas. Hoje eu preciso falar do lado ruim. Uma das piores coisas para um administrador é descobrir que fez uma besteira que afetou um monte de gente e ele não percebeu.

Enquanto eu investigava o problema de ontem eu acabei criando um script /net/bin/gawk pra tentar capturar as tentativas de usá-lo, o que acabou não sendo efetivo. Só que eu me esqueci de remover o script depois. Fiquei sabendo que vários usuários ligaram para o plantão falando que não estavam conseguindo usar o /net/gnu/bin/gawk no servidor, o que deu um bom trabalho para o pessoal que não estava sabendo do que eu estava fazendo.

Desculpe, gente! :-(

Duas lições pra qualquer administrador:
  • Sempre restaure o sistema à situação original depois de modificá-lo para fazer qualquer teste.
  • Nunca mexa num sistema de produção sem avisar seus colegas administradores antes.
Um dia eu aprendo.

terça-feira, 15 de maio de 2007

A saga do /net/bin

Uma das coisas mais divertidas da vida de um administrador de sistemas é resolver um problema difícil. É ainda mais legal quando o problema é antigo e você já tentou resolvê-lo várias vezes sem sucesso. Daí, quando você consegue finalmente vencê-lo, a satisfação é enorme.

Hoje tive um desses momentos memoráveis. Tanto assim que ao invés de simplesmente mandar um email para meus colegas de trabalho resolvi relatar a solução aqui e só mandar o link pra eles. Assim eles vão poder ter razão quando disserem que o Gustavo está "se achando". :-)

Pois bem. O mistério que nos estava deixando encucados há alguns meses eram as mensagens freqüentes que apareciam no /var/log/messages de vários servidores Linux:

May 13 16:05:02 noname automount[7655]: lookup(program): lookup for bin failed
May 13 16:05:02 noname automount[7655]: failed to mount /net/bin

Essas mensagens apareciam uma ou duas vezes por minuto, durante o dia todo, e indicavam que um ou mais processos estavam periodicamente tentando acessar o diretório /net/bin que não existe. Como o /net é a base de um mapa indireto do automounter, as falhas eram reportadas por ele via syslog.

O problema que não conseguíamos resolver era como identificar os processos que estavam acessando o diretório inexistente para podermos corrigi-los. Os logs do automounter não davam nenhuma pista útil, de modo que precisávamos de uma abordagem criativa.

O fato de os logs terem uma freqüência regular sugeria que os processos causadores pudessem estar sendo ativados via crontab. Só que essas máquinas são servidoras e têm dezenas de usuários com crontabs definidos. Os logs do /var/log/cron indicavam que grande parte dos crontabs iniciava comandos a cada minuto, de modo que não dava pra investigar um ou outro script especificamente.

Tentei pegar o culpado rastreando as chamadas de sistema do daemon crond e procurando por referências ao diretório /net/bin.

# strace -f -e trace=file -o/tmp/crond.strace -p `pidof crond`

Infelizmente, não encontrei nada, o que parecia um forte indício de que não se tratava mesmo de um processo de cron, mas eu não fiquei convencido.

Eu já tinha lido alguma coisa a respeito de ferramentas para monitorar o acesso a arquivos no Linux. Com o Google foi fácil encontrar o venerável dnotify e seu colega mais novo inotify. O dnotify permite monitorar o acesso aos arquivos de um diretório e o inotify é bem mais flexível. Só que o inotify não é suportado pela versão do kernel do servidor e eu desisti de instalar o dnotify pois provavelmente o tipo de acesso que os processos estavam fazendo não seria detectável mesmo por ele.

Uma idéia que parecia promissora era procurar por processos que tivessem o diretório /net/bin presente na sua variável de ambiente PATH. Podia ser que estes processos estivessem acessando o /net/bin como resultado do processo de busca de algum comando no PATH. Felizmente, ter a idéia foi mais difícil que implementá-la:

for e in /proc/[0-9]*/environ
do echo -n "$e: "; tr '\0' '\012' <$e | grep PATH
done | grep /net/bin


Procurar nos quase 3.000 processos do servidor demorou alguns segundos mas não devolveu resultado algum. Ou o acesso não era por causa do PATH ou os processos tinham vida curta e eu não consegui acertar em nenhum deles com esse tiro.

A próxima idéia foi importante, pois me fez descobrir algumas pistas e abriu as portas para a idéia seguinte. Se os logs eram gerados porque o /net/bin não existia, talvez eu pudesse ver o resultado do acesso se eu o criasse. Exportei um diretório vazio de outra máquina e configurei o automounter para montá-lo como /net/bin na servidora. Não demorou pra eu ver que ele tinha sido montado e que as mensagens de erro pararam. Já era um avanço.

A vantagem é que agora qualquer acesso ao /net/bin deixaria um rastro de pacotes NFS na rede. Trabalho para um analisador de pacotes como o ethereal. Alguns minutos de captura e eu já tinha uma coleção razoável de pacotes NFS pra investigar. Consegui descobrir duas coisas. A primeira, promissora, foi que havia várias tentativas de acesso ao arquivo /net/bin/gawk. A segunda, ruim, foi que estes acessos eram feitos por vários usuários diferentes. Eu podia identificá-los, pois suas credenciais estavam registradas nos campos RPC dos pacotes NFS.

Daí eu pensei: se eles estão procurando o /net/bin/gawk eu vou criar um que me avise quando for invocado. Criei um script chamado gawk no diretório montado como /net/bin. O script iria registrar várias informações sobre seu chamador num arquivo e dormir por 10 minutos, de modo que eu poderia identificá-lo mais facilmente. Preparei a armadilha e fiquei esperando... Nada aconteceu. Por algum motivo os processos não estavam "chamando" o gawk falso que eu havia criado. Eu não conseguia entender porque é que algum processo procuraria o gawk se não era para chamá-lo.

Mas a idéia de forçar o travamento dos processos que estavam acessando o /net/bin era muito boa. Tinha que haver uma maneira de poder efetivá-la. A ficha caiu quando eu me lembrei da causa de um travamento recente no mesmo servidor: um servidor de NFS fora do ar. Agora que eu já tinha o /net/bin montado de um servidor NFS, bastava eu desativar o serviço remoto de NFS pra que os processos que quisessem acessar o diretório ficassem suspensos num estado de uninterruptible sleep. Tive um certo receio, pois esses travamentos devidos a problemas com servidores NFS costumam deixar os servidores num estado em que só é possível ressuscitá-los com um reboot. Ocorre que os processos que param pelo problema com o NFS podem causar a parada de outros processos que dependam deles e assim sucessivamente. Mas como eu podia restabelecer o serviço de NFS rapidamente deveria ser possível sair de qualquer enrascada.

Parei o NFS e fiquei analisando o número de processos que iam parando no estado "D":

# ps aux | awk '$8 ~ /D/'

Pelo que me lembro, o número de processos assim chegou perto dos 400 em poucos minutos. Joguei o resultado num arquivo e reativei o NFS. Os processos travados voltaram a rodar e eu pude analisar o arquivo com calma. O que eu vi nele não fez muito sentido a princípio. Todos os processos parados ou eram instâncias de uma shell invocando o /net/gnu/bin/gawk ou o /net/gnu/bin/awk:

/bin/bash /net/gnu/bin/gawk ...

Preciso explicar que o /net/gnu/bin é onde, historicamente, costumamos instalar as ferramentas livres do Projeto GNU nas nossas máquinas Solaris. Quando começamos a instalar servidores Linux há quase 10 anos o modelo do /net/gnu/bin não era necessário em princípio. Afinal, os sistemas Linux já vêm com todas as ferramentas do Projeto GNU instaladas nos diretórios padrão /usr/bin e /bin. Mas como o diretório /net/gnu/bin já era referenciado por uma quantidade enorme de scripts e binários antigos, pra evitar o trabalho de mexer em tudo isso alguém teve a brilhante idéia de configurar o automounter das máquinas Linux para montar o diretório local /usr/bin das máquinas como /net/gnu/bin sempre que algum processo fizesse referência explícita ao último. (Nessas horas não adianta muito ser purista. Uma solução porca e torta que "resolva o problema" é considerada boa o suficiente. Ahem.)

Tudo bem. Que o /net/gnu/bin/gawk era mesmo o /usr/bin/gawk eu sabia, mas o que é que ele tinha a ver com o inexistente /net/bin/gawk? Por que é que ao chamar o /net/gnu/bin/gawk a shell travaria se o /net/bin estivesse com o servidor NFS fora?

Isso não fazia nenhum sentido até que eu dei uma olhada de perto no dito cujo:

# ls -l /usr/bin/gawk
lrwxrwxrwx 1 root root 14 Dez 15 2005 /usr/bin/gawk -> ../../bin/gawk

Um link simbólico!?!? Pra que raios o gawk é um link simbólico? Ah... o /usr/bin/gawk está apontando para o /bin/gawk, que é onde o binário do comando está efetivamente instalado.

Cáspita! Matei a charada. Como o link simbólico é relativo, o /usr/bin/gawk aponta para o /bin/gawk mas o /net/gnu/bin/gawk acaba apontando para o /net/bin/gawk!!!

Isso explicava o fato de eu não ter encontrado nenhuma referência direta ao /net/bin com o strace: o PATH da shell tinha uma referência ao /net/gnu/bin e não ao /net/bin. O travamento ocorreu dentro do sistema operacional, na chamada ao exec, quando ele foi seguir o link simbólico.

Eu sabia que um dia eu teria uma boa razão pra dizer "bem que eu avisei" quando reclamei da gambiarra que foi o /net/gnu/bin no Linux. Agora eu tenho. :-)

Bom, a causa do problema foi descoberta. Resta agora resolvê-lo. Idealmente, os processos que estão tentando acessar o /net/gnu/bin deveriam ser reescritos para não tentarem. Mas algo me diz que a solução vai acabar sendo criar mais uma gambiarra. Que desta vez deverá ser montar o /bin local dos servidores Linux no /net/bin.

quarta-feira, 9 de maio de 2007

Explicando pro meu filho

"Porque sim" não é resposta.
"Tanto faz" é uma resposta que não satisfaz.
"Pode ser" só é resposta pra você.

domingo, 22 de abril de 2007

Podcasts que irritam

Só há uma coisa mais irritante do que uma coisa extremamente irritante: uma coisinha um pouco irritante que a gente tem que enfrentar um monte de vezes. Das coisinhas que me irritam, a mais chata são os podcasts que não identificam adequadamente seus arquivos mp3 com tags id3.

Dois podcasts me irritam: os da CBN e o do Diogo Mainardi, na Veja. O problema dos podcasts da CBN é que vêm todos com um título (Rádio CBN) e um álbum padrão (CBN - A rádio que toca notícia). Isso é quase que completamente inútil. Costumo carregar meu ipod uma vez por semana e geralmente tenho uns 20 comentários da CBN pra ouvir. Como eles têm todos a mesma informação, não dá pra saber nem a data e nem de que comentarista é cada podcast. O problema do podcast do Mainardi é mais simples: o pessoal da Veja simplesmente não põe informação alguma nos mp3.

Cansado de ter que classificá-los manualmente pela interface do gtkpod, procurei por alguma ferramenta de linha de comando que pudesse me ajudar. O mp3info, que vem no pacote de mesmo nome no meu Ubuntu Linux, parece perfeito. Escrevi um pequeno script Perl (podcast-fix) pra automatizar o processo. O script recebe uma lista de arquivos mp3 como argumentos. Ele procura identificar dentre eles os podcasts da CBN e do Mainardi e invoca o mp3info para inserir as tags id3 que eu quero. Como eu baixo meus podcasts todos num único diretório, pra corrigir as tags dos arquivos problemáticos basta eu chamar o script assim:

podcast-fix ~/casts/*

Pronto. Uma irritação a menos na minha vida. :-)

domingo, 15 de abril de 2007

FISL8, a volta

Pra que eu não me esqueça como foi e possa evitar no futuro, eis como foi que cheguei em casa de volta do FISL8.

O avião da TAM atrasou 40 minutos pra sair de Porto Alegre, o que não foi totalmente inesperado. Cheguei em São Paulo às 22h mas a bagagem demorou a aparecer na esteira. Eu fui conferir se não haveria mesmo algum ônibus direto pra Campinas. Descobri que o último tinha saído às 22h e que o próximo sairia só às 0h15!

A alternativa seria ir pro terminal Tietê e pegar um Cometa de lá. Mas achei que seria mais seguro aguardar no aeroporto. Afinal, eu tinha carregado meu ipod com 10 episódios antigos do Nerdcast que me manteriam felizes enquanto eu aguardava. :-)

Cheguei em Campinas às 1h15, tonto de sono. Peguei um táxi e cheguei em casa às 2h.

Acabou o martírio. Mas o sono ainda está bravo.

sábado, 14 de abril de 2007

FISL8, terceiro dia

Fui dormir tarde ontem e não podia acordar muito tarde hoje pois eu precisava fechar a conta do hotel. Em retrospecto, acho que fiz uma grande besteira marcando a volta pra hoje. Primeiro porque tive que perder as três últimas palestras de hoje pra poder vir pro aeroporto. Mas principalmente porque eu vou chegar em Guarulhos depois do último ônibus direto pra Campinas. O plano é ir de táxi até o terminal Tietê, pegar um ônibus pra Campinas e outro táxi até em casa. Eu havia me esquecido do táxi final. Acho que se tivesse deixado pra voltar amanhã o custo de mais uma noite de hotel seria tranquilamente compensado pelo custo dos táxis que terei que pegar. Sem falar que eu acho que só vou estar em casa de madrugada. Oh well... aprendizado pra próxima.

A primeira palestra do dia foi a do Erwin Tehnumberg, sobre o ODF. O Erwin é um alemão que trabalha na Sun, no projeto OpenOffice.org. O blog dele é um dos mais famosos no tratamento dos assuntos OpenOffice.org e OpenDocument Format. Ele contou a história do desenvolvimento do padrão ODF, desde a sua origem no formato XML do OOo 1.0. Eu não sabia, mas a decisão de desenvolver o formato XML foi tomada pelo dono da StarDivision, a empresa alemã que desenvolveu o StarOffice e que foi comprada pela Sun em 1999. A motivação principal para desenvolverem o novo formato foi prover suporte para Unicode, mas na visão dele, criar mais um formato proprietário era errado, pois eles sabiam o quanto lhes havia custado impletar o suporte aos vários formatos proprietários já existentes. O objetivo, desde o princípio, foi especificar um formato aberto, que pudesse ser usado por outras ferramentas de escritório.

Em 2003 a OASIS formou um grupo de trabalho para especificar um padrão para documentos de escritório e decidiram usar a especificação aberta do OOo 1.0. Em 2005, a versão 1.0 do ODF foi ratificada e em 2006 foi abençoada pela ISO. A versão 1.1 saiu em 2006 e suas modificaçõ­es foram focadas no suporte às funções de acessibilidade. Segundo o Erwin, como o ODF referencia vários outros padrões, para suporte a imagens e a notação matemática, por exemplo, o trabalho acabou sendo mínimo, pois estes outros padrões já estavam melhor preparados para isso. A versão 1.2, que deverá ficar pronta ainda este ano, deverá especificar mais completamente o uso de fórmulas, uma área ainda meio em aberto.

Ele não falou quase nada do Open XML, formato da nova verão do MS Office, e que a Microsoft está forçando para que se torne um segundo padrão ISO para documentos de escritório. No seu único slide sobre o assunto ele mostrou que o ODF usa tags XML mais verbosas, o que é criticado por alguns usuários como causa de bloat, mas que ele justificou dizendo que isto é mais uma garantia de que o formato será legível no futuro distante, pois mesmo sem a especificação ele é bastante transparente.

Acho que ele devia ter falado mais do Open XML, sobre os motivos da Microsoft para tentar transformá-lo num padrão ISO e sobre as diferenças fundamentais entre ele e o ODF em termos de complexidade, completude, independência e implementabilidade.

Na seqüência, assisti à palestra sobre o Samba 4, do Felipe Augusto van de Wiel, mais conhecido como faw. O Felipe é desenvolvedor Debian e atua nos projetos Samba e OpenLDAP. A palestra falou sobre as novidades do Samba 4 em relação ao Samba 3. Basicamente, o Samba 3 funciona bem como um PDC numa rede NT4 e como cliente numa rede Active Directory. Mas o Samba 4 trará suporte completo ao CIFS, coisa que nem o Windows Vista faz, e deverá ser uma alternativa completa para um servidor AD.

Ele contou um pouco da história do Samba, elogiando bastante o Andrew 'Tridge' Tridgel, autor da primeira versão ainda atuando como líder do projeto. Aliás, o Samba foi iniciado em 1992, de modo que está fazendo 15 anos. Uma história interessante é que cada nova versão do Samba precisa passar pelo "Susan Stage" antes de ser considerado pronto. Susan é a esposa do Tridge. O Susan Stage acontece quando ele manda uma mensagem pra lista dos desenvolvedores avisando que sua esposa já está usando a nova versão no seu computador, sem ter perdido qualquer arquivo e feliz.

A palestra do Felipe estava lotada. É o terceiro ano em que ele se apresenta e parece que já fez sua legião de fãs.

A palestra seguinte foi do Theo de Raadt, líder do OpenBSD. Ele falou sobre o problema que eles enfrentam quando querem implementar um driver para algum dispositivo para o qual o fornecedor não disponibiliza a documentação. Ele mostrou para cada categoria de hardware como estava a situação. De longe, a mais complicada é a dos fornecedores de placas wireless. Parece que apenas dois fornecedores disponibilizam a documentação.

Esta situação é ridícula. Quer dizer, há leis obrigando os produtores de automóveis, por exemplo, disponibilizar a documentção necessária para que qualquer pessoa possa dar manutenção no próprio veículo. Por que com computadores a coisa deveria ser diferente? O fato é que não há uma boa razão para que os fornecedores sejam tão cabeças-duras em se negar a cooperar. Não é por causa de patentes, nem de copyrights e nem de medo que os concorrentes possam usar a informação contra eles. O Theo também não acha que haja uma conspiração contra os desenvolvedores de software livre. Ele desconfia que a razão principal seja a vergonha destes fornecedores em ter que expor na documentação a má qualidade da sua implementação. Segundo ele, a lista de bugs que são descobertos por engenharia reversa em alguns dispositivos é assustadora.

Ele criticou duramente alguns desenvolvedores do Linux por não terem comprado esta briga que ele considera da maior importância. Ele diz que se todos os desenvolvedores, as distros e os usuários dos sistemas livres começarem a atuar ativamente (enviando emails para os fornecedores solicitando a documentação) ou passivamente (recusando-se a comprar hardware dos fornecedores que não colaboram) temos uma boa chance de reverter o problema. Mas sem a ajuda da comunidade Linux ele acha que as chances são pequenas.

Depois, resolvi conferir a palestra da Fernanda Weiden sobre seu trabalho como administradora do Google. Ela foi contratada há 15 meses e está trabalhando no escritório de Zurique, no grupo SysOps. O grupo SysOps é responsável pela manutenção dos servidores e do ambiente de trabalho dos funcionários, mas não cuida dos servidores que implementam os serviços externos do Google.

A palestra foi bastante concorrida e, infelizmente, foi escalada pra uma das salas barulhentas.

A Fernanda começou falando dos projetos nos quais já se envolveu. Um deles é o "Office in a Box", que pretende especificar e automatizar o processo de configurar os serviços neccessários para suportar um escritório do Google. É interessante que a primeira abordagem considerava a configuração de um servidor para cada serviço. Essa estratégia teve vários problemas. Um deles é que com o aumento do número de serviços que precisam ser suportados, é preciso aumentar o número de servidores. Outro é que a maioria dos servidores acabam ficando ociosos, enquanto alguns deles podem estar sobrecarregados. Por fim, quando um dos servidores cai, demora até que outro possa ser configurado para substituí-lo.

A solução a que chegaram baseia-se em dois princípios. O primeiro é o de virtualizar todos os servidores, de modo a resolver os problemas acima. Usando o Xen, eles podem configurar uma máquina virtual para cada serviço, o que possibita uma melhor utililização do hardware real e uma maior flexibilidade na migração servidores virtuais no caso de um problema físico. O outro princípio tem a ver com o planejamento de capacidade para estes servidores. Eles decidiram medir a carga em cada servidor em função do número de empregados trabalhando em cada escritório. Deste modo, foram capazes de encontrar a capacidade de CPU e de memória necessária para suportar adequadamente cada servidor virtual, em função do número de empregados.

Outro projeto em que ela se envolveu é o Fast (não tenho certeza do nome pois não o anotei). Trata-se de um sistema de automatização da instalação de sistemas. A idéia é que para configurar um novo servidor, basta preconfigurar sua especificação num servidor central, instalar o sistema operacional básico manualmente (via CD ou PXE-boot) e rodar o script do Fast. O script se encarrega de obter as informações necessárias do servidor central e de configurar todo o necessário no novo servidor, inclusive instalando os pacotes de software necessários. Entendi que o Fast usa tecnologias básicas com as quais todo administrador de sistemas está acostumado, como o rsync para sincronizar arquivos.

Outro projeto é o Zombie para monitoração de serviços e de servidores. Entendi que se trata de uma compilação e integração de produtos livres.

Ela falou sobre o Goobuntu, uma distribuição interna do Ubuntu que o Google definiu como sistema operacional padrão da empresa. Isso não significa que eles vão trocar todos os outros sistemas ou que vão obrigar todos a migrarem para o Goobuntu. Mas será o sistema operacional mais bem mantido pela equipe de SysOps. Parece que há três sabores do Goobuntu: servidor, laptop e workstation. Elas são mantidas por uma equipe que analisa e modifica o que for necessário nos pacotes originais do Ubuntu. Não há intenção de disponibilizar o Goobuntu pra fora do Google. Trata-se de um projeto estritamente interno.

É interessante a maneira como a questão de padronização é levada no Google. Ela disse que ninguém é obrigado a usar uma tecnologia específica, seja o sistema operacional, seja algum aplicativo. Há algumas (poucas) pessoas que até usam o Windows. O que acontece é que a maioria normalmente faz pressão para que os demais migrem gradualmente para o que é considerado padrão. Mas nunca ocorre uma ordem que vem de cima pra mudar tudo. Acho que isso é saudável pois permite a coexistência de várias tecnologias evitando uma "monocultura" que poderia tornar a empresa menos flexível e menos ágil.

Esse papo todo foi rápido e ela abriu a sessão pra perguntas. E foram muitas. Perguram bastante sobre o ambiente de trabalho, sobre o processo de seleção e sobre como ela se sente trabalhando na empresa que é o sonho de emprego de 9 entre 10 pessoas que se interessam por tecnologia. Ela se rasgou em elogios e até pediu desculpas por isso. Confirmou quase tudo o que ouvimos falar sobre o Google, desde os 20% do tempo dedicados a projetos pessoais (os quais ela não usufrui por ser muito desorganizada) até as brincadeiras infantis cometidas no escritório.

Sobre sua contratação, ela não se considera um bom modelo porque não foi ela que foi atrás do Google. Eles é que a chamaram. Ela disse que sua insegurança não a teria permitido sequer tentar participar do processo seletivo. Mas, como foi chamada, raciocinou que na pior das hipóteses não perderia nada. O processo é longo e envolve múltiplas entrevistas com os futuros eventuais colegas de trabalho do pretendente.

Perguntada sobre o nível de cobrança a que os empregados são submetidos ela disse que é bastante normal. A cada três meses cada um se reúne com seu gerente imediato e negocia metas. Ao final do período eles se reunem novamente para discutir avaliar os resultados obtidos.

Perguntada sobre as tecnologias que usa ela disse que sempre foi uma "garota linha de comando" e que se sentia perfeitamente à vontade escrevendo scripts bash. Mas a necessidade de usar uma linguagem mais completa a fez investir em Perl, pelo qual ela se apaixonou. Acontece que no Google a maioria dos seus colegas usam Python, o que a forçou a estudá-lo... Ela não pareceu muito feliz... Eu também não ficaria. :-)

A última palestra a que eu assisti foi sobre LDAP, de novo do faw. Também estava lotada mas não achei tão boa quanto a sobre o Samba. Acho que ele tentou falar demais e acabou não explicandonada muito bem. Pra quem já tinha noção do assunto não houve muita novidade, mas pra quem não sabia nada acho que não ajudou também. De qualquer modo, valeu pra lembrar que LDAP pode servir pra bem mais que meramente unificar o cadastro de contas.

Peguei um táxi e vim cedo pro aeroporto. O avião está atrasado uns 40 minutos e eu já estou me preparando psicologicamente pra enfrentar o problema que vai ser ir de São Paulo até em casa.

No todo, valeu. Sinto que fiquei mais empolgado com o FISL6, mas foi bom o suficiente pra já me deixar com vontade de voltar no ano que vem.

Inté.

sexta-feira, 13 de abril de 2007

FISL8, segundo dia

O segundo dia tem sido bem melhor que o primeiro, em termos da qualidade das palestras a que consegui assistir. Logo cedo assisti à Free Software and The Matrix, do Alexandre Oliva. Dificilmente verei outra melhor. Ele fez uma colagem de trechos da trilogia The Matrix e foi fazendo comentários enquanto o clipe corria. Não medi, mas deve ter sido mais de meia-hora de clipe. A edição foi muito bem feita, com trechos extremamente hilários e um final empolgante.

De início ele disse que a legislação brasileira permite a utilização de partes de obras alheias na criação de outra, o que lhe dava o direito de fazer o que fez. Seu argumento é que há coisas que a legislação permite explicitamente e coisas que ela proíbe explicitamente. O problema é a fronteira que não fica muito bem definida. Segundo ele, muitas vezes quando temos vontade de fazer alguma coisa que parece estar na fronteira acabamos desistindo por medo de que alguém possa nos questionar. O resultado desta atitude é que a fronteira vai lentamente ficando cada vez mais pro nosso lado. A atitude dele é a oposta, i.e., ele tenta forçar a fronteira do que é permitido a se expandir. Muito bom mesmo. No final ele foi ovacionado de pé por muita gente.

A seguir assisti à palestra sobre Neutralidade na Rede, do Carlos Afonso, membro do Conselho Gestor da Internet no Brasil. Estou ciente da questão mas não a tenho acompanhado em detalhe. A sala estava lotada e ele também foi muito aplaudido.

Como exemplo do que os grandes provedores de hoje estão fazendo ele citou o caso da Brasil Telecom, que estaria usando um sniffer especializado para detectar e restringir o tráfego de VoIP na sua rede. A questão, segundo ele, não é usar o sniffer, pois há razões técnicas para manter estatísticas de utilização da rede. A questão é se a empresa poderia usar estas informações para priorizar tráfego que lhe interessa ao mesmo tempo em que bloqueia ou restringe tráfego que não lhe interessa. No caso específico, a empresa estaria reduzindo a banda efetiva de pacotes de tráfego VoIP que não fossem providos pela própria provedora. Parafraseando a declaração universal dos direitos humanos, ele disse que deveria haver uma outra declaração para a Internet dizendo que "Todos os datagramas são iguais perante a rede".

Outro exemplo indo na mesma linha é o caso da AT&T que foi denunciada por um funcionário por estar usando um sniffer para capturar pacotes em algum entroncamento de sua rede e repassando as informações coletadas para a própria NSA!

Outra questão que ele levantou é a da eventual obsolescência da UIT como organização. O problema é que a convergência das telecomunicações tradicionais com a Internet deverá obsoletar todos os protocolos padronizados pela UIT a longo prazo. Por isso, haveria um movimento dentro daquela organização vizando trazer pra ela a responsabilidade pela governança da própria Internet.

Por fim, ele comentou sobre a recente reunião do Fórum Internacional de Governança da Internet de que ele participou em Genebra. O assunto de neutralidade da rede estava em pauta quando um representante chinês se levantou e disse que dado o que ele estava vendo ser discutido ele não via razão para que o mundo todo criticasse a censura que o governo Chinês impõe ao acesso à Internet pelos seus cidadãos. Houve uma gritaria geral, criticando o pronunciamento do chinês, mas o Carlos se levantou e disse que o colega tinha um ponto. Afinal, a censura chinesa existe mas é explícita. O governo chinês não a esconde. Já as ações de empresas como a Brasil Telecom e a AT&T são feitas na surdina e têm o efeito de censurar determinado tráfego. Em última instância, a diferença é apenas que são grandes empresas e não governos que estão realizando a censura neste caso.

Depois desta palestra fui ao YAPC::SA::2007, encontro da comunidade Perl. Não havia muita gente. Acho que umas 20. Antes de começar fui abordado por um rapaz que me reconheceu pelo nome. Ele ouviu minhas entrevistas no Papotech e me cumprimentou. Fiquei lisonjeado. O nome dele eu não me lembro, mas ele é conhecido como Lorn, na comunidade Perl. Acabou fazendo uma apresentação rápida e bem interessante sobre o Catalyst. Até dá vontade de brincar com isso.

Antes do Lorn, o Flávio Glock, líder da comunidade Perl no Brasil, apresentou o projeto em que está atualmente envolvido: o MiniPerl6. Trata-se de um compilador que converte miniperl para várias coisas, como Perl5, Perl6 e Parrot. O conceito é interessante e a descrição do processo de bootstrap mais ainda. Miniperl é um Perl em miniatura. O suficiente para escrever um compilador nele próprio. A idéia seria escrever o compilador Perl6 em miniperl pra poder usá-lo no bootstrap de um futuro compilador Perl6-Perl6. Depois da palestra conversei mais um pouco com ele e perguntei sobre o relacionamento entre os projetos Pugs e Parrot com o dele. O projeto MiniPerl6 está sendo tocado dentro do Pugs, com a benção do próprio Larry Wall. Parece que houve um stress no passado quando o Glock participou do projeto Parrot e não se sentiu bem recebido. Agora parece que isso são águas passadas e que os vários projetos estão trocando figurinhas. Mas quanto à questão de qual a expectativa dele para termos finalmente um compilador Perl6 oficial, ele desconversou. :-)

Saí no meio do YAPC pra assistir à apresentação do Randal Schwartz sobre o git, a ferramenta de controle de versão que o Linus Torvalds começou a desenvolver depois que não pode mais usar o BitKeeper. Foi uma apresentação excelente, se bem que foi tanta informação que no final eu estava meio tonto. Acho que todo desenvolvedor deveria assistir a uma apresentação assim pra ver quanta funcionalidade uma ferramenta moderna como o git oferece para suportar o desenvolvimento de software de modo distribuído.

Em relação à arquitetura, o git se parece mais com o BitKeeper e com o SVK e é bem diferente do CVS, do SVN ou do ClearCase, pois não há um repositório central no qual todos os desenvolvedores mantêm seus objetos. Cada desenvolvedor cria um repositório local e interage com os repositórios alheios através de cópias e de merges.

O git é otimizado para:
  • Desenvolvimento distribuído
  • Grandes conjuntos de arquivos (o Linux kernel tem aproximadamente 25.000 arquivos)
  • Merges complexos
  • Criação de branches
  • Ser extremamente eficiente
  • Ser robusto
Por outro lado, ele não é otimizado para:
  • Manter metadados dos arquivos. De fato, ele lembra apenas se o arquivo é executável ou não. Permissões de leitura e de escrita, usuário e grupo são coisas que ele simplesmente não guarda. O Linus Torvalds argumenta que estas informações são irrelevantes para o tipo de arquivos para o qual o git é feito, i.e., para arquivos fonte de programas.
  • Manter o histórico de um único arquivo.
  • Tornar as coisas difíceis. :-)
Todo objeto mantido pelo git, seja um arquivo, um diretório, uma tag ou um branch, tem uma chave SHA1. Este parece ser o segredo do git. Não vou explicar aqui, mas esta decisão é que parece ter possibilitado a arquitetura descentralizada, a eficiência e a robustez da ferramenta.

Ele falou bastante e fez uma demonstração básica. Foi muita coisa e não me lembro de tudo. Uma das coisas que mais me impressionou foi a facilidade para a criação e descarte de branches. Eles são realmente baratos. Um novo branch gasta apenas 41 bytes! E quanto você resolve que um branch não deu em nada, pode mandar destruí-lo e ele realmente vai embora, ao contrário do que acontece com a maioria dos outros sistemas de controle de versão.

Achei fantástico que toda a demonstração foi feita dentro do Emacs. O Randal disse que: "I live inside Emacs". Mas, a certa altura, ele se pegou criando arquivos usando comandos como "echo something >file1". Mas como a shell dele estava dentro do Emacs ele disse: "isn't it increadible that I'm using echo to create a file inside Emacs?" :-)

Perguntei-lhe sobre outros projetos que já estejam usando o git e ele me disse que a entrada sobre o git no Wikipedia mantém uma lista. Mas citou o X.org e o Wine.

Do git acabei pegando o final da palestra " Designing Efficient APIs for Long Lived Open Source Projects" de um cara da Sun. Era tudo Java e fiquei boiando. :-)

Na seqüência eu fui assistir à palestra "As Ações mais Legais da FSFLA", apresentada pelo Oliva, pela Fernanda Weiden e pelo professor Pedro Resende, todos conselheiros da FSFLA. Eles fizeram um rápido relato das questões mais relevantes em que a FSFLA se envolveu no último ano em defesa da liberdade dos usuários de software. Começando pelo estudo que fizeram sobre os requisitos que a própria Constituição Federal impõe sobre as tecnologias empregadas na implementação dos sistemas informação do governo e dos meios de comunicação com o cidadão. Eles demonstram que estes requisitos acabam exigindo que as quatro liberdades que definem o software livre sejam resguardadas, o que implica em que estas tecnologias só poderiam ser implementada usando software livre. Esses requititos vêm de princípios básicos, como soberania nacional, transparência e isonomia na prestação de serviços e no investimento responsável dos recursos públicos. Eu não poderia fazer melhor do que referenciar o artigo em que tudo isso é explicado convincentemente.

Outro assunto foi o dos softwares impostos, como o programa para declaração de imposto de renda. Não é meramente o fato de ele ser feito em Java que ainda não (mas quase) é software livre. Outro problema é que o parágrafo terceiro do artigo primeiro da Instrução Normativa SRF nº 616, de 31 de janeiro de 2006, da Receita Federal define alguns critérios que proíbem quem quer que os satizfaça de declarar sua renda no formulário em papel. O próprio Alexandre Oliva cai num destes critérios e é obrigado a fazer a declaração com o programa da Receita. Incomodado com isso (eufemismo meu), por considerar que utilizar um programa prietário é imoral, ele tentou argumentar com a Receita Federal solicitando que pudesse fazer sua declaração e papel. Sem sucesso. Mesmo alegando que é um direito constitucional recusar-se a fazer alguma coisa que vá contra suas convicções morais (ou mesmo religiosas), desde que esta coisa não seja imposta a todos. Como nem todos são obrigados a declarar com o uso do programa, ele estaria mais que justificado em se recusar por motivos morais. É o que diz o inciso VIII, do artigo quinto, da Constituição Federal.

Mas isso não é tudo. A Lei de Software, em seu artigo nono, diz que um programa só pode ser usado mediante uma licença de uso de seu autor. Acontece que o programa da Receita Federal não tem uma licença, daquelas que a gente não lê e clica OK. O Oliva questionou o pessoal da Receita e o máximo que conseguiu foi uma resposta na linha de "pode baixar e usar sim". Ou seja, ao pé da letra da lei, o uso do programa da Receita é ilegal.

E ainda tem mais. Decompilando o binário Java do programa da Receita (que, diga-se de passagem, vem com os símbolos de depuração), o Oliva descobriu que ele usa mais de 10 programas livres, a maioria deles licenciado com licenças sem copyleft, o que permite que sejam incorporados ao código proprietário do programa da Receita. Mas essas licenças exigem que o uso dos programas regidos por elas seja declarado na documentação do programa que os incorpora e que uma cópia das licenças seja fornecida. Mas também há componentes LGPL no programa. Neste caso, a Receita deveria fornecer os fontes deste componente. A esta altura você já deve ter adivinhado que o Oliva pediu os fontes e não os obteve. Disseram a ele que ele os poderia obter do site do componente original. Mas isso não vale. A licença obriga o distribuidor a fornecer os fontes quando solicitados. E além disso, não dá pra saber que versão do componente foi usada e menos ainda foi modificada.

Mas nem tudo está perdido. O Oliva conseguiu um documento especificando o formato do arquivo que programa da Receita gera e foi capaz de gerá-lo sem precisar usar o programa. Mas falta ainda um detalhe. Parece que o arquivo precisa conter um hash, calculado sobre o seu próprio conteúdo, de modo que a Receita possa saber que ele foi gerado com o programa que ela fornece e não por um outro. Por isso, eles não forneceram o algoritmo de cálculo do hash, mas o Oliva está trabalhando no código decompilado do programa pra ver se consegue reconstruí-lo. Ele ainda tem uns quinze dias pra poder entregar sua receita sem cometer uma imoralidade.

As conseqüências do seu eventual sucesso são importantes. Em última análise, ele estará criando uma ferramenta capaz de produzir declarações que a Receita não poderá distingüir de uma gerada pelo seu programa. Em tese, isso não devia ser um problema pra Receita, pois de qualquer modo ela deveria realizar verificações de consistência interna da declaração além de cruzar os dados de cada declaração com os das declarações dos fornecedores referidos por ela. Por que será, então, que a Receita reluta em fornecer as informações necessárias para que alguém possa criar um software alternativo ao seu? Não quero especular, mas não consigo imaginar uma razão moralmente justificável.

Depois deste assunto fascinante, eles comentaram um pouco sobre DRM e como isso pode restringir as liberdades dos consumidores de dispositivos eletrônicos que o implemente. Quem quiser saber mais sobre isso pode ler também sobre a tal Trusted Computing.

Por fim, eles anunciaram que uma nova constituição havia sido adotada hoje pela FSFLA. A partir de hoje a FSFLA não é mais uma entidade jurídica própria, mas apenas um grupo de pessoas físicas. Todos os membros passam a ser conselheiros e não há mais uma estrutura formal. A razão para isso é evitar que a FSFLA tenha que ser formalizada num dos países da América Latina em detrimento de todos os outros. Podem haver "braços" nacionais formalizados como pessoas jurídicas, mas a própria FSFLA não será mais assim.

A palestra seguinte foi a do Dan Ravicher sobre "Patents and Free/Open Source Software: Introduction and Analysis". Dan é advogado do Software Freedom Law Center e fez uma palestra brilhante e muito didática. Ele mostrou os problemas causados pelas patentes de software mas argumentou que eles acabam sendo mais impactantes para empresas de software proprietário. Uma razão é o fato de que nos EUA, cada parte envolvida numa ação sobre infração de patentes, paga, em média, uns três milhões de dólares. E lá não existe o princípio de que quem perde a ação arca com as custas advocatícias da parte vencedora. Deste modo, uma empresa detentora de patente só entraria com uma ação de infração se tivesse a expectativa de obter um ressarcimeno financeiro que pelo menos cobrisse seus custos com advogados. Portanto, somente empresas com algum porte seriam vítimas deste tipo de ação e o desenvolvedor de software livre comum não precisaria ficar preocupado.

Faz sentido, mas nem toda ação visa obter ganho financeiro direto. Um risco que independe do tamanho do bolso do desenvolvedor é o caso em que um software livre faz sucesso e começa a atrapalhar os planos de negócio de uma empresa produtora de um similar proprietário. Neste caso, a empresa pode julgar que os custos de uma ação seriam menores que o impacto que o software livre poderia lhe causar em termos de competição por clientes. E eu já ouvi falar de casos assim.

Um outro ponto que ele citou como argumento para justificar o menor risco que o software livre sofre com as patentes está relaciado ao tamanho do canal de distribuição. Se uma empresa que produz um software proprietário é processada por infração de patentes, o juiz pode demandar que o software em questão tenha sua distribuição interrompida. Mas o mesmo não poderia ocorrer caso a empresa processada produzisse software livre. A razão é que quando o software é proprietário, só a empresa que o produz é que tem o direito de distribuí-lo. Já no caso do software livre, se o juíz impedisse a empresa de distribuí-lo ele estaria ferindo um outro princípio jurídico que diz que o cerceamento de direitos não pode ser seletivo. A questão é que quando o software é livre, qualquer outra pessoa ou empresa poderia continuar a distribuí-lo e a empresa processada estaria tendo seus direitos restringidos de maneira inócua.

A próxima palestra foi do Jono Bacon, gerente de comunidade na Canonical, sobre "How to Herd Cats and Influence People". O cara é extremamente elétrico e sabe como cativar o público. Bastante apropriado para a função que ele exerce na empresa. Ele disse que atualmente, principalmente depois que a Canonical fez sucesso com o Ubuntu, todas as empresas de software livre estão bastante preocupadas em cativar uma comunidade fiel. E a Canonical tem conseguido fazer isso como ninguém. Pelo que eu vi, o Ubuntu é, de longe, a distro mais usada neste FISL. Os pontos são os seguintes:
  • Encontrar pessoas de qualidade
  • Promover a integração das pessoas com interesses comuns
  • Promover a comunicação entre esses grupos
  • Facilitar a integração de novatos
Ele foi bastante aplaudido e acho que foi o mais tietado de todos os palestrantes.

A última palestra do dia foi do Jon 'maddog' Hall sobre "Why Free Software is Like a Pianola". Ele falou sobre a história dos instrumentos musicais, em particular da do cravo, do piano e dos órgãos. Toda essa história é cheia de paralelos com a história do software. Acho que a idéia é usar esta analogia pra vermos por outra perspectiva as questões prementes sobre tecnologia e direito sobre o software à luz da história dos instrumentos musicais.

Saí da FIERGS e fui ao Shopping Lindóia. Parece que é o mais perto daqui, mas mesmo assim eu achei longe. Era pequeno e eu quase não consegui encontrar as lembranças pra família. Acabou dando tempo e eu jantei num rodízio de pizza. (Estou comendo tão mal que semana que vem vai ser só salada.)

Na volta peguei um táxi. Mal entrei e percebi que o motorista estava ouvindo algum tipo de pregação evangélica. Não deu outra... no caminho ele começou a falar sobre violência, sobre como o diabo veio ao mundo para destruí-lo e sobre como as mulheres deviam permanecer em casa cuidando dos filhos. Neste ponto eu não agüentei e perguntei por que é que nós não trocávamos de lugar com elas, deixando-as trabalhar e ficando em casa cuidando das crianças? Pra quê, né? Ele disse que há um princípio básico de que deus teria feito tudo certo e que o que ele diz ninguém desdiz e que tudo isso estava na Bíblia. Eu contra-argumentei que isso estaria certo desde que todos concordassem com este princípio, mas que minha condição de ateu nos colocava em bases diferentes.

Resultado... ficamos discutindo por mais uns 15 minutos dentro do carro na frente do Hotel. O cara tem uma leitura fundamenntalista da Bíblia. Eu consegui responder a alguns dos seus argumentos tentando mostrar que eles se baseavam ou em uma premissa questionável ou em uma simples falácia lógica. Mas realmente não dá pra levar uma discussão destas com base na razão. Um dos seus argumentos é o de que a Bíblia não deve ser lida com a razão, mas sim com o coração... não sei como levar uma discussão racional a partir disto. Mas tudo bem, quer dizer, nós nos despedimos cordialmente, ele me abençoou e eu o agradeci. Penso que poderia ter sido bem pior.

Amanhã é o último dia.