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.