Today I have started to learn how to use FreeCAD. My first exercise was drawing a 3d model of a pinball post similar to these ones. Here it is:

3d model of a pinball ribbed post














The CAD file is here, released under public domain.

This week I have been preparing acrylic parts for my pinball machine. The parts were drawn in Inkscape (both the artwork of the parts and their shape). I have sent the shapes to be laser cut in acrylic. The artwork was printed in 4 A3 sheets of paper in a professional print shop.

There are some photos of the results here:

Laser-cut acrylic parts






An acrylic part and its printed artwork






One acrylic part with art ready to be installed in the machine






Also, this week I have discovered Jeri Ellsworth, a pinball-geek girl who is also notable for some other hacks. She's building a pinball machine and posting videos on her youtube channel. Check out this live streaming of her lab. There's an IRC bot to control the webcam zoom and angles and also a text-to-speech bot.

She's recently posted a video explaining how to make coloured pinball parts using fabric dye. I will probably try to do that with the flipper rubber bands of my pinball which are black but were supposed to be red.

Esse email eu escrevi em resposta a uma pergunta que uma pessoa fez na lista de discussão brasileira de usuários do Inkscape.

O cara perguntou sobre alternativas ao Flash. Algumas pessoas sugeriram usar
SVG com javascript e foram trocados alguns exemplos (eu, obviamente, também defendi o uso de SVG). Outra pessoa disse: "pois é... muito legal, mas SVG ainda não funciona no Internet Explorer então não rola fazer em SVG por que quem usa IE não vai conseguir ver". Então alguém falou sobre o projeto que o Google lançou recentemente chamado SVGWeb e que permite que usuários de IE consigam visualizar conteúdo SVG.

=======

Eu não sei se eu já falei a respeito disso aqui na lista, mas algum tempo atrás eu pesquisei sobre esse tema e descobri algumas coisas importantes.

* Flex é uma tecnologia implementada em software livre, mas as aplicações feitas com flex só são possíveis de ser executadas corretamente em uma máquina virtual Flash proprietária da Adobe.

* O SVGWeb é um software livre renderizador de SVG feito em flex.

Portanto, o SVGWeb tem tanto vantagens quanto desvantagens:

A grande qualidade do SVGWeb é que ele permite que conteúdo SVG seja acessado em praticamente qualquer browser sem a necessidade de instalar absolutamente nada no cliente. Todo mundo que tem um Flash player consegue acessar SVG, desde que o SVGWeb tenha sido habilitado pela pessoa que criou a página SVG.

A grande desvantagem é que hoje em dia não existe Flash player livre que seja capaz de rodar o SVGWeb.

Sendo assim, ao usar o SVGWeb na sua página você pode ter a certeza de que as pessoas que se beneficiarão disso serão aquelas que ainda estão presas a um Flash player proprietário. Em compensação, isso cria uma situação onde você não está mais impossibilitado de utilizar o SVG. Ou
seja, o SVGWeb retira o bloqueio que tínhamos no uso deste padrão aberto em função da não-aderência do Internet Explorer ao formato vetorial da W3C. Veja essa tabela de compatibilidade nativa a SVG nos principais browsers. Mas eu te pergunto: de quê adianta usar um padrão aberto, se ele depende duma máquina virtual Flash proprietária para ser exibido?

Na verdade não depende. É possível configurar o SVGWeb para ser usado apenas quando o browser do usuário não tem suporte nativo a SVG. E isso é uma coisa fantástica!

Bem... acho que isso deixa claro que eu considero sim o uso do SVGWeb benéfico, mas com fortes ressalvas, né? Acho que o SVGWeb não deve ser considerado uma solução definitiva. Mas
sim funcionar como "ponte" para uma web mais aberta em um futuro próximo.

Minha dica é: faça sua página usando SVG e coloque o SVGWeb lá configurado pra só ser usado no IE. O dia que o IE for varrido da face da Terra e todos os browsers tiverem suporte nativo a SVG, será possível simplesmente remover o SVGWeb, sem custos adicionais de desenvolvimento e teremos uma web melhor baseada em mais padrões abertos. Enquanto isso não se realiza, sejamos pelo menos amigáveis ao software livre. Tenha sempre em mente que você pode eventualmente ser o culpado por alguém ser obrigado a abrir mão da liberdade no uso de softwares (ou escolher a liberdade e ser excluído do acesso ao seu conteúdo).

Portanto, a regra de ouro é sempre usar tecnologias que não obriguem as pessoas a instalar software proprietário pra acessar o seu conteúdo. Quando se lida com o público, é necessário tomar decisões responsáveis. Talvez você não se preocupe com o seu uso pessoal de software proprietário. Mas não permita que suas opções pessoais se transformem em imposições sobre outras pessoas (efetivamente deixando elas sem opção).

Felipe "Juca" Sanches

Engenharia Reversa IB-200 (receptor de tv digital usb)

If you need an english translation of this technical report or additional info on my reverse engineering efforts, please email me at felipe.sanches@gmail.com and I will gladly help people working on further developments towards support of this device under GNU/Linux.

Comprei um receptor de tv digital usb OneSeg da IBAYO, modelo IB-200 e comecei a fazer engenharia reversa nele para tentar fazer um driver para Linux. Este post tem o objetivo de documentar minhas tentativas e convidar mais hackers para ajudar nesta tarefa que está dando nós na minha cabeça, mas que ao mesmo tempo está servindo para eu aprender um monte de coisas novas. Se você é um programador curioso, não tenha medo dos nomes feios que vão aparecer neste post. Eu também me assustei da primeira vez que vi isso, semana passada :-)

Só pra constar aqui (e pra facilitar as buscas no google de gente procurando informações sobre esse dispositivo) ele é reconhecido pelo comando lsusb como ID 5a57:4210 Zinwell

Usei um sniffer USB para Windows chamado usbsnoop. Com ele fiz alguns logs de operação do dispositivo no Windows usando o software proprietário que vem no CD de instalação. Em um desses logs eu cheguei a abrir o programa e assistir um pouco de vídeo para ter certeza de que no log constam todos os comandos necessários para inicializar o dispositivo, sintonizar um canal e exibir o vídeo recebido. No Linux, eu utilizei um script em perl chamado usbsnoop2libusb. Esse script lê um log do usbsnoop e gera automaticamente um código fonte em C utilizando a biblioteca libusb. Esse código, quando executado, repete as operações que constam no log. Obviamente fazer um driver não é tão fácil. Mas o código gerado automaticamente é um primeiro passo. É um esqueleto de código em cima do qual podemos trabalhar.

Rodei o programa gerado automaticamente a partir do log que continha vídeo e não funcionou, mas o led azul do dispositivo chegou a acender. Sendo assim, resolvi olhar com mais calma para o conteúdo do log. Conversei com um amigo meu, o Lucas Villa Real (desenvolvedor da distro GoboLinux), que trabalhou comigo no Laboratório de TV Digital na USP. Ele me contou que eu deveria procurar informações que começassem com o byte 0x47 e que tivessem comprimento de 188 ou 204 bytes. Segundo o Lucas, essas são as características dos pacotes que compõem o transport stream da tv digital brasileira (variante do padrão ISDB-T japonês). Fiz isso visualmente e constatei que de fato haviam alguns pacotes de dados sendo enviados do dispositivo para o PC e que tinham essas características (com 188 bytes de comprimento). Fiz um script em python que filtra o log pegando só esses pacotes e salvando eles todos concatenados em um arquivo de saída binário (no log constam esses dados em ascii usando notação hexadecimal). Depois compilei e instalei o DemuxFS, que é um software livre desenvolvido pelo Lucas, que serve para auxiliar no debugging de sistemas de tv digital ISDB, especialmente no SBTVD (sistema brasileiro de tv digital).

O DemuxFS é um filesystem virtual que exibe informações de um stream de tv digital na forma de entradas em um sistema de arquivos. Ele pode ser usado com um backend chamado filesrc ("file source") que lê o transport stream a partir de um arquivo (como o arquivo que eu gerei usando o script python) para ajudar no debugging, ou pode ser usado com um backend que leia o transport stream a partir de um dispositivo de recepção de tv digital (para ser usado na prática). A minha idéia é inicialmente escrever um backend para o demuxfs ler o transport stream a partir do IBAYO IB-200. Mas no momento isso ainda não foi feito.

Usando o DemuxFS eu consegui com sucesso montar no Linux o arquivo de transport stream que foi extraído do log de operação no Windows do IB-200. Isso é um ótimo sinal!
Observei que os pacotes que compõem o transport stream são enviados por meio de transferências isoch (isócronas). Eu nunca tinha ouvido falar disso antes, mas depois de um pouco de estudo, descobri que se trata de um dos modos de transferência disponíveis no protocolo USB. Nesse modo, a banda máxima de transmissão de dados é menor, mas há a garantia de que os dados serão enviados dentro de um determinado limite de tempo. Especialistas, corrijam-se se eu estiver falando besteira.

Observei com atenção o log e inclusive modifiquei um pouco o script usbsnoop2libusb para que o programa gerado automaticamente exibisse na tela não apenas os dados retornados pelas chamadas feitas, mas também os dados que tinha sido retornados pelas respectivas chamadas originais quando executadas no Windows. Dessa forma eu pude não apenas repetir as chamadas que constam no log, mas também comparar as respostas que o dispositivo nos retorna no Linux pra ver se em algum lugar as reações do dispositivo divergem das respostas esperadas (as respostas que ele deu originalmente no Windows). No geral, as respostas foram bem parecidas com as originais. Houveram pouquíssimas respostas diferentes, mas acredito que elas não sejam um problema, pois eram mensagens onde apenas 1 ou 2 bytes eram diferentes da resposta esperada e isso até faz sentido, pois há certas informações que variam entre uma execução e outra, por exemplo o nível de qualidade do sinal de recepção de um determinado canal de tv. A cada execução, é de se esperar que o nível de qualidade seja diferente e, eventualmente esse dado será passado para o PC, o que pode caracterizar uma dessas pequenas divergências observadas.

Em um determinado ponto surgiu uma divergência grande. No ponto onde deveriam começar a ser recebidos pacotes das transferências de dados isócronas contendo o transport stream, absolutamente nada está sendo retornado. Todas as transferências parecem estar dando timeout por algum motivo. É importante dizer aqui que houve ainda um outro problema. O script usbsnoop2libusb estava reclamando que o tamanho de algumas das tranferencias isoch era maior que o limite de 32kbytes. Achei isso muito estranho, pois no log constam transferências isoch de mais que 32kbytes e foi justamente dessas transferências que eu extraí corretamente o transport stream. Portanto, não é um erro no log e de fato no windows foi possível fazer transferências maiores que 32kb. Tentei aumentar esse limite para 64kb e recebi uma mensagem de erro da biblioteca libusb quando tentei executar o código gerado a partir dessa nova versão do script. Procurei na internet pelo código fonte da biblioteca e lá existe uma condição "retorne mensagem de erro caso usuário tente fazer uma transferência maior que 32kb" sem nenhuma explicação do motivo para a limitação.

Pesquisei mais na internet e descobri que existe um projeto chamado libusb-1.0 que concorre com a libusb mais famosa (que tem pacote no ubuntu, por exemplo) que é a libusb-0.1. Apesar de terem o mesmo nome, aparentemente a 1.0 é uma versão reescrita da 0.1 e segundo consta no website do projeto ela tem várias melhorias quanto a performance e a determinados bugs da 0.1. Sendo assim, resolvi experimentar a tal libusb-1.0. Baixei a versão de desenvolvimento, compilei e instalei. Depois portei o script usbsnoop2libusb para gerar código que use a biblioteca 1.0 (as chamadas de função dessa outra biblioteca são obviamente diferentes). Esta nova versão do script está disponível no meu svn do GoogleCode. Rodando a minha versão do script consegui gerar código com transferências isoch maiores que 32kb e a libusb1.0 não tem esta limitação. Entretanto, isso ainda não resolveu o problema do receptor de tv digital. Mas ouso dizer que provavelmente este é um problema que precisaria ser resolvido de qualquer forma antes de conseguir fazer o dispositivo funcionar, então considero isso como mais um passo dado rumo ao suporte do IB-200 no Linux.

No momento, eu estou lutando com mais uma deficiência do script usbsnoop2libusb. Existe uma operação que consta no log e que o script ainda não implementou a respectiva conversão para código C. A operação é um USB_FUNCTION_ABORT_PIPE. Mais uma vez, fiquei naquela situação "WTF!?!?". Googlei um pouco e li a respeito do tal do "abort pipe". No protocolo USB, pipes são abstrações de canais de comunicação entre o host (driver no PC) e um endpoint (dispositivo). Por algum motivo que ainda não é muito claro pra mim, existe a possibilidade do host pedir para um determinado pipe ser abortado, ou reiniciado. Imagino que isso seja feito quando um pipe não vai mais ser usado, ou então quando um pipe será reconfigurado. Mais uma vez, peço o palpite dos especialistas :-)

Enfim... uma dessas chamadas de "abort pipe" acontece bem no finalzinho do log que corresponde ao momento em que fechei o programa no Windows e isso faz todo sentido, pois ao fechar o programa, é de se esperar que o pipe usado para o fluxo de dados seja fechado. Mas a outra ocorrência desse comando acontece um pouco antes do início das transferências isoch problemáticas. Sendo assim, acho que não ter o "abort pipe" alí pode ser uma das razões para as transferências isoch não estarem funcionando pra mim no momento no Linux.

A minha estratégia agora é tentar descobrir como se faz pra implementar suporte a "abort pipe" no script usbsnoop2libusb e ver se isso resolve a zica. O problema é que eu não tenho a menor idéia de como se faz para enviar um comando "abort pipe" usando a libusb. Assim que eu tiver mais avanços eu aviso. Por enquanto, aguardo comentários dos hackers de plantão :-)

If you need an english translation of this technical report or additional info, please email me at felipe.sanches@gmail.com and I will gladly help people working on further developments towards support of this device under GNU/Linux.

Gostaria de dar notícias sobre o andamento do meu projeto de construir uma máquina de verdade com o tema da mesa PARTY Land do jogo Pinball Fantasies (jogo de Amiga, PC, e muitas outras plataformas).

Visão geral de como está o PF (este video já foi postado anteriormente no blog):
http://www.youtube.com/watch?v=91HUGSr1reQ

Nesta semana terminei de montar um DMD para a máquina. Utilizei módulos de LED importados da China. Cada módulo tem 24x16 leds. Como eu precisava de um display de 160x16, comprei 7 módulos, sendo assim, meu DMD tem 168x16. Deixei 4 colunas de LEDs sobrando de cada lado do display.

Eu tinha comprado 2 desses módulos pra testar. Depois que eles chegaram e eu testei e deu tudo certo encomendei os outros 5 módulos. Entretanto, os módulos dessa segunda encomenda estão com a luminosidade bem mais forte que os 2 primeiros. Isso é bem chato, já mandei email pro fabricante reclamando, mas duvido que eles mandem outros 2 displays pra mim por causa disso. Vamos ver no que dá. Por enquanto, coloquei esses 2 displays mais fraquinhos, um de cada lado do DMD, pra pelo menos o problema ficar simétrico e ficar na região do DMD que costuma ter menos coisa acontecendo. A maioria das animações acontecem no meio do DMD.

Vejam nesse vídeo o problema da luminosidade diferente nos módulos:


(eu deixei os módulos dispostos dessa forma levemente curvada só pra eles ficarem de pé. Depois vou fazer um suporte para aparafusá-los direitinho)

Estes módulos são controlados pelo Arduino (um microcontrolador baseado em chip atmega) via interface SPI. O Arduino está conectado a um computador via USB. No computador eu rodo um emulador de MSDOS chamado DosBox.



Modifiquei o código do emulador (software livre) para que a cada quadro da emulação ele faça um dump do topo da memória de vídeo emulada e envie esta informação para o arduíno se comunicando pela porta USB. Eu rodo o jogo Pinball Fantasies nesse emulador e o jogo desenha o seu DMD (virtual) naquela região da memória que o emulador fica mandando pro DMD de verdade.

Assim, eu consigo jogar o Pinball Fantasies no emulador e ter um DMD de verdade mostrando as animações do jogo emulado.

Vocês podem ver isso em ação neste vídeo:


Esse outro é mais velho (de quando eu só tinha 2 módulos de LEDs):


Fotos do projeto em:
http://www.flickr.com/photos/felipesanches

Virei personagem de quadrinhos:



tirinha completa em: Nerdson não vai à escola

Valeu, Karlisson! A Campus Party foi demais!

Um amigo me mandou alguns emails nessa semana e depois de conversarmos um pouco sobre sistemas operacionais ele lançou o seguinte questionamento:

a questão "windows X linux" foi só pra ilustrar.

no longo prazo, acho sistemas operacionais (as we know them) nem
existirão. Manja? Isso me parece uma briga por migalhas.

Digo isso pq acredito q, no futuro, não teremos um windows para rodar
programinhas. Não precisaremos de HD, OS, etc. Estará tudo no ar, tá
ligado? Internet sem fio de banda gigantesca, faremos tudo por aí.

Imagina:
- quem brigava pelo mercado de PAPEL CARBONO há 40 anos atrás
- quem tinha uma mina de sal e achava q estava dominando (depois q a
refrigeração domiciliar ficou acessível à todos, a demanda
praticamente sumiu)

Portanto, o q tenho a dizer talvez seja: existe a possibilidade de vcs
estarem se preocupando com MIGALHA.

Já pensou nessa possibilidade?

E aqui está a minha resposta (achei interessante postar aqui no blog para mais pessoas também refletirem sobre esta questão):

sim, já. É a tendência do "cloud computing".

Sinceramente, acho que grande parte disso é baboseira. Estratégia de marketing mesmo. Uma pequena parte está correta. Por exemplo, o que temos hoje como gmail, flickr, youtube, etc. Existem serviços que realmente funcionam bem quando executados "na nuvem".
Mas abrir mão totalmente de uma plataforma computacional local ainda é inviável. E deve continuar por muito tempo sendo assim pois há tarefas que são ideais para serem executadas localmente mesmo, por exemplo processamento de gráficos 3d. Há ainda impedimentos tecnológicos nesses casos mesmo que esses possam obviamente ser superados por novas tecnologias no futuro.

Além disso, eu tenho muito medo dessa tendência por que ela põe em risco justamente essa plataforma de incentivo à criatividade que é o computador pessoal hoje em dia. O computador pessoal é uma máquina maravilhosa justamente por ser uma máquina genérica que permite que se faça absolutamente qualquer coisa que um programador quiser. É como se fosse um mini-laboratório dentro da casa de cada pessoa. Aquelas pessoas que eventualmente se interessarem por computação têm todo o potencial e recursos ali já disponíveis com absolutamente nenhum custo monetário adicional. O único custo para criar é o próprio custo intelectual de se engajar na atividade criativa. É como se vc tivesse um ateliér de arte embutido em cada moldura de quadro do mundo. Todas as pessoas que têm quadros têm aquele potencial disponível. Algumas pessoas vão querer só apreciar a pintura que já está no quadro (análogo aos usuários que não têm interesse em desenvolver programas de computador), mas outras pessoas podem eventualmente se interessar em fazer suas próprias pinturas e, para estes, não haveria barreira de entrada pois todo o ateliér estaria ali embutido por padrão à espera de um surto de criatividade.

É isso que temos em casa hoje em dia. Máquinas versáteis esperando por pessoas inovadoras que queiram produzir soluções computacionais para os mais diversos problemas. E há evidências de que pessoas de fato fazem isso motivadas pelos mais diversos aspectos e freqüentemente se agrupam para participar em atividades criativas coletivas (o que é hoje, por exemplo, o software livre). O cloud computing transforma o PC genérico em um terminal burro. Joga toda a capacidade de processamento para a "nuvem" e leva embora o "ateliér". Num ambiente 100% cloud computing, o custo de se inovar será mais alto, pois os meios de produção tecnológica estarão majoritariamente nas mãos apenas dos provedores de serviço. Computadores genéricos deixaram de estar presentes nos lares pois sua produção industrial será substituida pela produção em larga escala dos terminais burros. O poder computacional dedicado à criatividade caseira estagnará na geração atual de computadores que gradativamente se extinguirá devido às panes naturais do envelhecimento dos equipamentos.

O quanto isso irá afetar a produção criativa é difícil de se dizer, mas a certeza é de que afetará negativamente, pois as pessoas não terão mais (por padrão) autonomia de criar suas próprias soluções computacionais. Isso eu não quero.

Vídeo mostrando como anda o meu projeto da máquina de pinball:

Hoje parei pra ouvir um pouco de música no Jamendo. Trata-se de um site onde artistas podem hospedar seus álbuns desde que estes estejam licenciados sob alguma das licenças Creative Commons. Algum tempo atrás eu convenci meu amigo Guilherme Padovani, vocalista da banda Motocontínuo, a adotar uma licença CC by-sa nas músicas da banda e depois ajudei a inscrever a banda no site.

Um questionamento que nos fizemos na época foi que se estávamos, por meio da licença, permitindo a criação de obras derivadas, então deveríamos fornecer os meios para tal. Ou seja, deveríamos distribuir não apenas o CD pronto, mas também as faixas de estúdio, o "código fonte" do álbum. Sem isso, ficaria muito difícil fazer alterações nas músicas. A única alternativa que restaria para quem não tivesse acesso às faixas de estudio seria regravar a música em estúdio novamente já que tentar separar os canais seria bastante difícil e provavelmente não ficaria com boa qualidade.

Sendo assim, o Guilherme me passou 7 CDs onde estavam os arquivos de áudio das gravações de estúdio separados em canais para cada um dos instrumentos. Como o conteúdo era pesado, decidimos distribuir por P2P. Criamos arquivos ISO dos CDs e fizemos upload no PirateBay. Entretanto, como não tem muita gente baixando este conteúdo, o torrent provavelmente está sem seeders nesse exato momento. Além disso, tem muita gente que não sabe baixar torrents. A tentativa de usar P2P foi fracassada. Imagino que o ideal seria um sistema que exigísse o mínimo possível de conhecimento técnico de seus usuários. Eu realmente espero que pessoas interessadas em música acessem este conteúdo. Não gostaria de limitar o acesso só por que eventualmente as pessoas não sabem lidar com arquivos torrent.

Hoje fiquei pensando bastante sobre esse problema. Enquanto no software livre ocorrem de fato modificações, aprimoramentos, etc. na "música livre", essa prática parece ser quase inexistente (corrijam-me com contra-exemplos caso eu esteja errado). Quais seriam os motivos? Será que as pessoas simplesmente preferem criar música sempre do zero? Concordo que é totalmente subjetivo falar sobre aprimoramentos de uma obra artística. Na área técnica isso é certamente uma questão mais objetiva do que na música, por exemplo.

Derivação incremental propriamente dita - modificações em detalhes como substituir uma linha de baixo deixando todo o resto intacto - eu acho que não teria muito valor. Talvez o maior valor da música livre esteja no acervo de recursos disponíveis para remixagem. Sendo assim, artistas criariam suas próprias obras originais com gravações de novas faixas em estúdio e as complementariam com samples retirados de outras obras livres disponíveis na rede. Ainda assim, para que isso seja produtivo continua sendo necessário publicar as faixas de estúdio na rede para enriquecer este acervo comum.

Vejo muita gente falando a favor do uso de licenças livres, mas não vejo muitas pessoas com as mesmas preocupações que estou expondo neste post. Também ainda não vejo surgirem soluções tecnológicas para viabilizar essas idéias. Seria interessante (e útil) algo como uma SourceForge para música. Ou talvez algo como o Open Clipart Library. Como relatado anteriormente, minhas tentativas de por isso em prática junto com a banda Motocontínuo não tiveram sucesso. Tentei até entrar em contato com o pessoal do Jamendo propondo que o serviço deles contasse com uma área para upload das faixas de estúdio, mas eles também não providenciaram ainda uma solução para o problema já que aparentemente não há demanda suficiente.

Na minha concepção, um sistema ideal além de fornecer para download as faixas de estúdio de um determinado álbum, também deveria ser capaz de indexar este conteúdo e permitir que os visitantes visualizassem o acervo de áudio classificado por tipos de instrumento, estilo musical, etc. Obviamente essa classificação poderia ser feita pelos próprios artistas no momento em que fazem o upload. Entretanto, aposto todas as minhas fichas que muito pouca gente se daria o trabalho de inserir estes metadados. Portanto, seria necessário criar tecnologia para inferir esses metadados automaticamente. O que falta pra concretizar essa tecnologia? Muita matemática! A solução não é trivial.

No final das contas, isso parece ser mais uma tarefa para o Google: "A missão do Google é organizar as informações do mundo todo e torná-las acessíveis e úteis em caráter universal."

RicBit talvez?!

Uns 10 anos atrás um minigame meu quebrou e na época eu abri pra ver como era por dentro. Acabei largando ele aberto por que na época eu me frustrei com o "chip bolha". Tudo o que dá pra ver ao abrir um minigame daqueles são os contatos dos botões, o cristal líquido e uma bolha de plastico derretido. Debaixo da bolha fica um chip minúsculo. Aquilo foi muito chato por que não satisfez minha curiosidade.



Recentemente, brincando com o Inkscape e curtindo minha nostalgia, eu e a Bani criamos um minigame virtual feito em SVG e programado em javascript. Se você usa um browser que implementa o padrão SVG (padrão aberto para gráficos vetoriais na web), então você poderá jogar o nosso minigame aqui. Recomendo usar o Firefox. Não funciona no Internet Explorer; ele é um dos únicos browsers hoje em dia que ainda está em 0% de suporte a SVG atrasando a evolução da web.



O jogo é inspirado numa charge famosa do Tux (mascote do kernel Linux) se preparando para bater com um mata-moscas na borboleta do MSN (da Miscrosoft). O jogo segue um formato tradicional de muitos dos jogos antigos de minigame: basicamente vc tem que bater em todas as borboletas conforme elas forem descendo na tela.

Fazer o jogo foi bastante divertido e foi relativamente simples. Desenhamos tudo no Inkscape. Depois selecionamos cada um dos ícones do display de cristal líquido e atribuímos nomes por meio do atributo id (menu de contexto => Propriedades do Objeto). Depois escrevemos o código em javascript usando as funções de manipulação do DOM (Document Object Model) para controlar a visibilidade dos ícones. Assim o software pode fazer os ícones do display acenderem ou apagarem conforme mandar a lógica do jogo.



A única edição manual (em editor de texto) do arquivo SVG foi para adicionar a tag <script xlink:href="minigame.js" /> e o atributo onload="on_load(event);" na tag svg (análoga à tag body do HTML). Com isso, pudemos escrever todo o código javascript em um arquivo .js externo. Todo o resto da edição do SVG foi feita visualmente por meio do Inkscape.

Já hoje, curtindo as férias da faculdade, resolvi voltar a mexer no minigame quebrado. Peguei o cristal líquido do minigame e tirei algumas fotos. Usei uma fonte de tensão pra acender manualmente os ícones do display. Na verdade, os ícones não acendem individualmente. O display é multiplexado e, portanto, as ligações formam uma matriz de ícones. A cada vez que eu aplico tensão em algum dos conectores do display, um certo grupo de ícones se acende. Tirei várias fotos e comecei a vetorizá-las. A idéia é fazer uma versão emulada em SVG+javascript do minigame do Megaman.



Apesar do processo de vetorização ser um pouco cansativo, o maior problema vai ser programar o jogo. Extrair o código do jogo diretamente do minigame não parece ser possível (de se fazer em casa) pois todo o código fica dentro do chip bolha. Portanto vou ter que reprogramar. Além disso, outra dificuldade é eu não lembrar mais como funcionava o jogo. Talvez eu ainda consiga consertar o minigame e assim conseguir jogá-lo, pra relembrar a lógica. Eu acho que o único problema desse minigame é que os fios que são ligados às baterias se quebraram e os que ligam o speaker também. Depois que eu soldar esses fios, é possível que o minigame ainda funcione.

Ahhh...! Outro problema para a emulação são os sons do jogo... mas isso fica pra depois.

Estou ainda LENTAMENTE montando aquela máquina de pinball caseira: uma réplica da PARTYland do jogo Pinball Fantasies.

Semana passada encomendei 2 displays de 24x16 LEDs cada um e estou escrevendo software para controlá-lo usando o Arduino. A comunidade já ajudou bastante, e grande parte do código não fui eu que escrevi.

O display que eu preciso é de 160x16. Portanto irei em breve comprar mais 5 desses displays de 24x16 e colocá-los lado a lado.

7*24 = 168 que é apenas 8 colunas a mais do que os 160x16 que eu preciso (veja no screenshot do jogo).



Os displays eu comprei direto do fabricante chinês por US$15,75 cada um. O datasheet deles está aqui.

Preciso de ajuda para dimensionar a fonte externa que vou usar pra ligar todos esses displays ao mesmo tempo. Seria bom fazer uma fonte inteira para todo o pinball, mas eu ainda não tenho muita idéia de quanto que o pinball todo vai puxar da fonte. Pedi conselhos quanto a isso para o PJWerneck, do grupo de usuários de Python. Mas se qualquer outra pessoa estiver a fim de dar conselhos, toda ajuda é bem-vinda!



Além disso, se alguém aí da turma do arduino se interessar, podemos encomendar alguns desses displays pra quem quiser, assim reduzimos os custos de frete e pegamos descontos oferecidos pelo site. Como eu já vou comprar 5 unidades e eles oferecem 3% de desconto pra compras de 5 a 9 unidades e 5% pra 10 ou mais, qualquer unidade extra já tem desconto automaticamente se for comprado junto.

This tutorial teaches you how to install libxml2dom python module on windows machines.

1) Install the latest python package available at python.org
I am using http://python.org/ftp/python/2.5.1/python-2.5.1.msi

2) Install the libxml2 python package available at:
http://users.skynet.be/sbi/libxml-python/libxml2-python-2.6.27.win32-py2.5.exe

3) Download the libxml2dom python package available at:
http://www.boddie.org.uk/python/libxml2dom.html

I am using this version: http://www.boddie.org.uk/python/downloads/libxml2dom-0.4.4.tar.gz

4) You will need a software capable of unpacking .tar.gz files You can use WinRar to unpack it.

5) After unpacking the tar.gz package on your Desktop, open the DOS command prompt (Start->Run "cmd")

6) Then type the following commands on the command prompt:
cd %USERPROFILE%
cd Desktop\libxml2dom-0.4.4
setup.py install
exit

http://bighead.poli.usp.br/juca/gravit.html

Javascript gravitation code v.1.1 (May 9th, 2007)
(c)2007 Felipe Sanches <felipe.sanches@poli.usp.br>

This program simulates gravitational effect.

This program is licensed under the GNU General Public License
 version 2 or later.

ChangeLog:
v1.1 (May 9th, 2007)
* Added tail effect

v1.0 (May 3rd, 2007 - First release)
* initial code
** simulation core
** basic rendering using <div>s

Eu sou um dos administradores da banda Motocontínuo, do Guilherme Padovani (Guinoupe), no site Jamendo.com

Como o site da banda (www.motocontinuo.net) ainda não está pronto, estou colocando aqui no meu blog o link de validação requisitado pelo jamendo:

Eu, Felipe Sanches, certifico que o álbum "A fantástica viagem trágica" da banda Motocontínuo (cujos direitos autorais pertencem a Guilerme Padovani e demais membros da banda) está, de fato, licenciado sob a Creative Commons by-sa 2.5

Esta é a seleção de músicas livres que estou fazendo. Vou chamá-la de "Som na Rede volume 1". Ainda não está pronta. Mas quem quiser já pode ir ouvindo o que eu já selecionei. Estou procurando músicas nos estilos acidjazz, groove ou funk.

Hoje eu traduzi pro português um trecho de uma palestra do Stallman que achei bastante interessante. Podemos refletir sobre o "Computador para Todos" quando ele fala da adoção de software livre sem a devida educação sobre a importancia das liberdades que inspiram o movimento.

Segue a tradução:
----------------------------
Para que as pessoas defendam sua liberdade, as pessoas precisam valorizar sua liberdade, precisam apreciá-la. E para que as pesoas apreciem e valorizem sua liberdade, primeiro elas precisam saber que liberdade é esta. Em outras áreas, a maioria das pessoas já ouviu falar de direitos humanos. Isso não significa que defender os direitos humanos seja uma tarefa fácil, mas pelo menos nós não precisamos sair por aí explicando para as pessoas o conceito. Nós não precisamos iniciar explicando pras pessoas o que significa liberdade de imprensa como se elas nunca antes tivessem ouvido falar a respeito. O conceito de liberdade de imprensa teve séculos para se desenvolver e espalhar-se pelo mundo.

Mas a computação é algo novo. Faz apenas cerca de dez anos que um graende número de pessoas nos países mais ricos vêm usando computadores. E faz apenas algumas poucas décadas que existem computadores. Portanto, as idéias sobre quais direitos humanos devem acompanhar o uso de um software estão apenas começando a ser desenvolvidas. O movimento do Software Livre diz que há quatro direitos humanos essenciais para um usuário de software. [[ Nota do tradutor: mais informações sobre isso em http://www.gnu.org/philosophy/free-sw.html ]] Esta é uma idéia nova. A maioria das pessoas que usam software nunca pensaram sobre a questão de quais direitos humanos um usuário e software deve ter. Eles simplesmente aceitam o que lhes foi dito, ou seja, os direitos humanos atribuídos ao usuário são: nenhum de fato.
É isto que os desenvolvedores de software proprietário lhes dão. É isso que eles vêem quase todo mundo aceitando. É isso que eles fizeram. E eles nunca ouviram ninguém dizer que há outra idéia. Portanto nós precisamos de fato começar pelo passo número um, que é dizer às pessoas o que significa ter liberdade ao utilizar um software. E então podemos ter a esperança de que aquelas pessoas irão valorizar estas liberdades o suficiente para defendê-las de modo que elas possam continuar sendo livres. O futuro de nossa comunidade depende do que nós valorizamos, mais do que qualquer outra coisa.
E é por isso que é tão importante hoje em dia ensinar as pessoas sobre os ideais do movimento do Software Livre. Não é suficiente apenas ensinar as pessoas a usar Software Livre. É claro que espero que as pessoas utilizem Software Livre, por que é uma vergonha se elas estiverem utilizando softwares não-livres que subjugam o usuário. Ma apenas utilizar Software Livre não é suficiente se queremos ter liberdade que dure muitos anos. Se amanhã nós dessemos liberdade a todas as pessoas que utilizam computadores, mas elas não soubessem o significado dessa liberdade, dentro de cinco anos muitas delas teriam perdido esta liberdade por que alguém teria dito a elas " Eu tenho um programa bacana que irá tornar as coisas mais fáceis, você quer? É claro que você vai ter que me prometer que não vai compartilhá-lo com ninguém, e eu não o deixarei ver o que há dentro dele, mas é um programa bacana, você não o quer? "
Uma pessoa que não tenha aprendido a pensar que há algo errado ali poderia responder sim. E isto significa que sua liberdade teria parcialmente se perdido. Portanto, não é suficiente dar liberdade às pessoas. Nós precisamos ensinar as pessoas a reconhecê-la como liberdade de modo a aprenderem a valorizá-la e então defendê-la e não deixá-la fugir. É disso que precisamos se queremos ter liberdade não apenas amanhã mas permanentemente.

Richard Stallman, 9 de março de 2006

Richard Stallman iniciou o projeto GNU em 1983 e, com ele, o movimento do Software Livre.

Fonte (com o texto e gravação em áudio da palestra completa em inglês): http://www.fsfeurope.org/documents/rms-fs-2006-03-09.en.html

Concordo que é, no mínimo, exagerada a posição sobre os danos ao meio ambiente que podem ser causados pelo Windows Vista. Mas quero ressaltar o que acredito ser o mais importante desta notícia da slashdot : o motivo. Pra que atualizar o hardware? Para aguentar a nova interface gráfica do Windows Vista? Também...

Mas mais importante é notar aquela sigla que foi utilizada (DRM) que talvez nem todos conheçam. Significa "Digital Rights Management". Resumindo, são técnicas de proteção de conteúdo multimídia digital. O Vista virá com isso para melhor se adequar à crescente pressão da industria de entretenimento que vê na internet o possível colapso de seu império.

Outro dia eu comprei um CD que usava uma dessas técnicas. O DRM simplesmente não permite que vc copie as músicas do CD para um mp3player portátil. Ele RESTRINGE os usos que vc pode fazer com a música que VOCÊ COMPROU! Sob o pretexto de combate à pirataria, eles cada vez mais limitam os usos legítimos que vc poderia fazer com sua mídia adquirida legalmente. No caso do CD que eu comprei, o DRM deles foi feito para Windows, e como no meu PC roda linux, o DRM simplesmente não funcionou. Mesmo no winXP seria possível se livrar do DRM apenas desabilitando o auto-run do CD. Entretanto, a nova versão do windows (o Vista) virá com novos mecanismos que, através de criptografia, torna virtualmente impossível para um usuário comum driblar estes bloqueios. E por se tratar de um sistema de código fechado, eles conseguem garantir que o código de proteção não será removível, efetivando assim seu domínio sobre as atividades dos usuários.

Obviamente, hackers conseguirão burlar estes mecanismos, mas não é isso que devemos esperar. Não devemos passivamente aguardas a "vitória" silenciosa do "dá-se um jeito". Pois não seria uma vitória. Seria a aceitação da submissão aos poderes destes grandões. Devemos nos engajar a todo custo em barrar estes abusos. As pessoas precisam se manifestar e tornar claro tanto para estas megacorporações quanto para os governos que as regulam (ou que deveriam regulá-las) que estamos indignados e não aceitamos estes insultos.

(aliás... só de passagem, em 1998 foi aprovado nos EUA o "DMCA = Digital Millenium Copyright Act" que torna ilegal a utilização, o desenvolvimento e a distribuição de tecnologias que permitam burlar mecanismos de DRM. Ou seja, em muitos casos, governos estão dando suporte a esse império)

Como vc poderá ler nos 2 artigos abaixo (caso se interesse), muito do hardware extra necessário no Windows Vista não será útil para melhorar desempenho, ou prover novas funcionalidades. Será, na verdade, útil para garantir a continuidade do império. Para engordar mais os bolsos de Hollywood às custas de... "usuários inocentes"?

Não é à toa que a campanha anti-DRM da FreeSoftwareFoundation chama-se "Defective by Design", em bom português, "Defeituoso por Projeto" ( http://www.defectivebydesign.org )

Windows Vista precisa de MAIS hardware pra ter MENOS funcionalidade!

vejam os artigos:

* http://www.theinquirer.net/default.aspx?article=25124
* http://www.meiobit.com/industria/restricoes_usando_drm_no_windows_vista

Juca

A análise a seguir exemplifica o aprimoramento da participatividade e do poder de ação política propiciado pela Internet como ferramenta de interação na esfera pública em rede em contraposição às características da esfera pública mediada pela mídia de massa comercial.

A história escolhida para tal trata da polêmica em torno do sistema de votação eletrônica produzido pela Diebold, uma das empresas fabricantes de urnas eletrônicas certificadas para as eleições de 2004 nos Estados Unidos. Apesar de ser um debate a respeito de votação eletrônica, não é isto que o torna pertinente à democracia. O debate poderia tratar de qualquer prática corporativa ou de governo que fosse difícil de investigar e analisar, tivesse graves implicações e que fosse amplamente ignorada pela grande mídia. O fato relevante aqui é que a esfera pública em rede se mobilizou e conseguiu, com sucesso, transformar algo que não era pauta de discussão pública séria em uma discussão pública que levou a ações públicas concretas.

Urnas eletrônicas foram utilizadas em escala substancial pela primeira vez nas eleições de novembro de 2002 nos EUA. A cobertura da mídia ressaltava principalmente a novidade do mecanismo com leves referências à possibilidade de eventuais falhas, mas sem nenhum questionamento severo quanto à segurança do sistema. Sem dúvidas, uma análise profunda não seria uma tarefa fácil dada a necessidade de alto grau de conhecimento a respeito de segurança de computadores e o fato de o assunto ser tratado como altamente confidencial. Entretanto, devido a uma série de fatos, a tarefa mostrou-se viável para um grupo de voluntários organizados através da Internet.

Ao final do mês de janeiro de 2003, Bev Harris, uma ativista especializada em urnas eletrônicas descobriu um site da Diebold onde encontravam-se milhares de arquivos com informações confidenciais sobre suas urnas indevidamente acessíveis ao público. Mo início do mês seguinte, ela publicou 2 artigos em um jornal online neo-zelandês. Além disso, organizou em seu site um espaço para pessoas com conhecimentos técnicos discutirem a respeito de suas descobertas. No início de julho, ela publicou uma análise dos resultados das discussões mostrando como o acesso ao material poderia ter sido usado para afetar os resultados das eleições de 2002 no estado da Georgia. Num editorial anexado à publicação os editores do jornal online adicionaram a seguinte nota que ressalta diversas características da esfera pública em rede:

"Nós agora podemos, pela primeira vez, revelar a localização do site onde encontra-se todo o material. Como podemos prever tentativas por parte da Diebold de evitar a distribuição destas informações, nós encorajamos os apoiadores da democracia a fazer diversas cópias destes arquivos e disponibilizá-los em websites e redes de compartilhamento de arquivos: http://users.actrix.co.nz/dolly/. Como muitos destes arquivos estão protegidos por senhas você pode precisar de ajuda para abri-los. Nós descobrimos que a ferramenta disponível em http://www.lostpassword.com/ funciona bem. Por fim, alguns arquivos estão danificados, mas esta outra ferramenta pode ser útil para recuperá-los: http://www.zip-repair.com/. Neste estágio, acreditamos que ainda não chegamos nem remotamente próximo de investigar todos os aspectos destas informações; ou seja, não há razão para crer que as falhas de segurança encontradas até agora sejam as únicas. Portanto, esperamos novas descobertas em breve. Pedimos a assistência da comunidade online de especialistas em computação para nos auxiliar nesta busca e os encorajamos a arquivar suas descobertas em nosso fórum de discussões."

Muitas características desta convocação seriam inviáveis na mídia de massa. Ao das acesso ao material cru completo e usar a estratégia de replicar a informação para que seja impraticável censurá-la leva-se o discurso público a nortear-se pelo "veja com seus próprios olhos" em vez do "confie em nós" típico da mídia de massa.

Além disso, não foi necessário investir enormes quantias de dinheiro para contreatar especialistas. Ao contrário, voluntários que acreditavam na importância do assunto se dispuseram para a tarefa colaborativa. Este curto parágrafo delineia mecanismos radicalmente decentralizados e estratégicos de armazenamento, distribuição, análise e divulgação dos arquivos da Diebold.

Enquanto isso, novos problemas estavam surgindo para a empresa. A revista norte-americana "Wired Magazine" informou em agosto de 2003 ter recebido de um hacker uma cópia de milhares de emails internos da Diebold e enfatizou este fato como outro exemplo do desleixo da Diebold em relação à segurança. A revista não publicou o conteúdo dos emails. Entretanto, a ativista Bev Harris, também recebeu cópias dos emails e os expôs ao escrutínio público em seu site. A empresa respondeu perante a justiça requisitando a retirada do material do site.

Entretanto, os esforços da empresa foram fúteis perante a determinação dos ativistas engajados na distribuição irrestrita do material. Estudantes de diversas universidades dos EUA começaram a replicar cópias dos emails. As universidades receberam cartas requisitando a remoção do material de seus servidores. Os alunos foram obrigados a fazê-lo, mas , no que foi por eles descrito em 21 de outubro de 2003 como "desobediência civil eletrônica" cópias dos emails foram re-distribuídas em redes peer-to-peer de compartilhamento de arquivos (as mesmas redes que são freqüentemente criticadas por seu uso para pirataria de músicas e vídeos). Novamente, a participação de indivíduos de todo o país impossibilitou a censura do material.

Estes emails continham, entre muitos outros relatos problemáticos, evidências de que algumas das urnas utilizadas nas eleições em 2004 haviam sido modificadas após a certificação. Estas informações levaram à decertificação de parte das urnas da Diebold.

NOTA: A Diebold além de fornecer 75 mil urnas para as eleições nos EUA, foi responsável, em parceria com a PROCOMP, pelas urnas eletrônicas utilizadas no Brasil.

------------
Texto adaptado para o português a partir do original de Yochai Benkler no livro "Wealth of Networks: How Social Production Transforms Markets and Freedom" ("A riqueza das redes: Como a Produção Social Transforma os Mercados e a Liberdade")

O livro está disponível na íntegra para download em http://www.benkler.org/ sob a licença livre Creative Commons Attribution Noncommercial Sharealike http://creativecommons.org/licenses/by-nc-sa/2.5/

This is how I intend to use dosbox to control the real pinball machine that I am building based on the design of Pinball Fantasies' PARTYland table:

This is a yet unfinished hack. I am modifying dosbox to act as a light & sensor controller for the real pinball machine. It would send on/off commands to real lights each time it detects an operation on the VGA pallete corresponding to the flashing lights in the game. It would also patch at runtime the variables that contain the x,y cordinates of the ball, each time the real ball touches a sensor, in order to put the virtual ball over the corresponding virtual sensor. This way, the original game acts as the firmware for the real machine, and no new code needs to be written. This method guarantees fidelity to the original game behaviour.

See photos of the pinball machine I am building on my flickr.

The following video shows me filling one of the light inserts using blue epoxy: