Quando o sistema engessa o negócio

2005. Íamos quase todo dia a uma cafeteria, beber um bom café e travar a batalha verbal capitalismo X comunismo. Na hora de ir embora, tínhamos naturalmente de pagar a conta, e era sempre uma confusão: procurar notas pequenas e moedas, arredondar a conta para aqueles sem troco, vigiar os "chupins" que tentavam dar a volta na conta (por esporte, não por safadeza, naturalmente :)

Já que íamos sempre no mesmo lugar, pedimos inúmeras vezes para abrirem uma conta, de modo que não precisássemos catar moedas todo dia. Sugerimos inclusive um esquema "pré-pago", para evitar temores de inadimplência. Não eramos os únicos habituées, outras pessoas certamente iam aderir ao esquema. Infelizmente, passaram 3 anos e eles ainda não aceitaram nossa proposta, provavelmente porque o sistema da loja era padronizado para a franquia e ainda não implementava esse recurso.

2008. Nos últimos dias, devido à correria de criar um bebê, temos comprado almoço num pequeno restaurante próximo, comida caseira e barata, cujo único aparato computadorizado é a máquina de cartão de crédito.

Depois de aparecer quase todo dia por 2 semanas, a atendente sugeriu abríssemos uma conta, para pagar apenas no fim de cada semana, evitando passar o cartão todo santo dia. Sugeri pagar um valor grande antecipadamente (não gosto de dever nada a ninguém), o que foi prontamente aceito. Ela abriu o caderno, colocou meu nome lá, e o esquema estava montado.

Guerras religiosas e versões do UNIX

Desde há muito tempo costumo associar o desenvolvimento do UNIX e do Linux com o das religiões. Acho que daria para escrever um livro inteiro sobre o assunto. Assim, vou me restringir a uma comparação simples, para ilustrar a idéia.

Existe uma relação de amor e ódio entre Linux e BSD, assim como existe uma relação semelhante entre cristianismo e judaísmo. Ao mesmo tempo que o Linux está "fugindo" o tempo todo do status quo do BSD, por outro lado é um descendente direto dele -- um paradoxo insolúvel. E, quando alguma iniciativa do Linux encontra um beco sem saída, não raro rende-se ao modus operandi do BSD (como aconteceu nas implementações do IPv6 e no IPSEC).

As próprias respectivas comunidades imitam muito bem as respectivas religiões. O povo do Linux é conhecido, aberto, promíscuo, admite qualquer um, tem ânsia em conquistar mais e mais adeptos. A comunidade do BSD, embora tecnicamente aberta a qualquer um, é fechada, desconhecida, avessa a novos membros; muito do que o público "sabe" dela é temperada de mitos e lendas. Assim como os cristãos, o Linux não tem vergonha especial de ser fragmentado em inúmeras distribuições, até vê uma certa vantagem nisso. O BSD preocupa-se em passar uma impressão de unidade, assim como o judaísmo -- embora isso esteja longe da verdade (só no tempo de Cristo, havia fariseus, saduceus, essênios e zelotes).

A "psicologia de comunidade" talvez tenha a ver com pressões externas. O Linux sempre cresceu à sombra de um mundo livre. O BSD sofreu perseguição severa por conta do processo da Bell Labs.

As pessoas pensam que os judeus dominam o mundo. Isso pode ser verdade, mas essa dominação ocorre de uma forma bem mais sutil e mais ubíqua do que se supõe: a lei e a moral do mundo ocidental são completamente fundadas no Antigo Testamento, a começar pelos Dez Mandamentos que são a pedra-de-canto de qualquer sistema legal moderno. É curioso notar, todavia, que a popularização dessa lei/moral é largamente devida aos cristãos.

Da mesma forma, o BSD também "domina", mas não em número de servidores; ele domina através da API, a começar pela API BSD/Sockets, que é utilizada até mesmo no Windows. A API do BSD influencia todas as outras, de formas incrivelmente sutis. Mas essa influência deve muito à popularidade do Linux. Sem essa popularidade e sem a quantidade de código livre escrito para BSD/Sockets, talvez o Windows resolvesse criar uma nova API de rede do zero.

E é bom que essa dominação exista. Do contrário, estaríamos construíndo pirâmides inúteis para os mortos, fazendo sacrifícios humanos em cada esquina e (Deus me livre!) usando aquela API horrível do Unix System V para redes, a XTI/LTI. Ou algo pior ainda bolado pela Microsoft.

Palestra na Semana de Computação da UDESC

Na próxima quinta-feira, dia 4 de setembro, vou participar do evento Semana da Computação da UDESC campus Joinville, com a palestra "Python para Dispositivos Móveis Nokia" -- aquela mesma que já foi proferida em ocasiões anteriores.

A palestra está disponível para download em formato OpenOffice e PowerPoint.

Gnome, KDE e o trem da história (tomo 1 de 2)

(featuring Rudá Moura)

Existe uma área do software livre que sempre trabalhou duro para não dar certo. Estou falando dos ambientes gráficos, em particular do Gnome e do KDE.

Em primeiro lugar, o Unix usa o X11 como base da interface gráfica. Muita gente já apontou o X11 como o grande problema do desktop Unix. O X11 não é problema; ele simplesmente faz o papel de driver de vídeo, mouse e teclado. Mas também não soluciona nada.

Por si só o X11 não é um passivo, porém a falta de uma API de nível médio é um problema que sempre foi óbvio. Embora muita gente argumentasse que essa inexistência de tal API significava "liberdade", é apenas uma liberdade potencial, enquanto os perigos da falta de uma API padrão sempre foram, e continuam sendo, reais e imediatos.

É claro, o X11 oferece uma API de baixo nível (x11lib), semelhante à API de baixo nível do Windows. Ao menos a x11lib é um padrão, embora as extensões padeçam de problemas, conforme abordaremos mais adiante.

A API de nível médio, que o X11 não oferece porém é muito necessária, é aquela que fornece elementos necessários a qualquer ambiente gráfico que mereça este nome, e que ofereça recursos como:

* Widgets (ao menos os controles básicos);

* Comunicação interprocessos de alto nível, possivelmente com semelhanças com DDE/OLE/COM do Windows;

* Instalação e manipulação de fontes;

* Impressão;

* Painel/tray;

* Som e multimídia em geral;

* Possivelmente, APIs para drivers multimídia como codecs;

* Recentemente, Bluetooth.

O Windows não tinha todos estes recursos numa API uniforme logo de início, nem mesmo manteve um padrão gravado em pedra. Por exemplo, a comunicação interprocessos era DDE, depois OLE, e atualmente COM. O Mac OS X mudou a API de Bluetooth entre as versões 10.3 e 10.4.

A API de widgets é um ponto delicado, porque também envolve a questão da aparência desses widgets. Uma das "liberdades" apregoadas no mundo X11 é cada aplicativo desenhe widgets do jeito que quiser. Na verdade, isso também é possível no Windows; lembro que o Delphi já desenhava muitos widgets por conta própria, embora com a mesma aparência.

A questão de existir uma aparência padrão que os aplicativos normalmente devam seguir, é uma questão religiosa. Teoricamente o Motif fazia este papel para o X11, porém o Motif era feio e limitado demais já em 1999.

Mas o problema que mais incomoda não é a existência de aplicativos com aparência diferente; o real problema é a reimplementação das mesmas primitivas no Motif, na Qt, no Gtk+: main loop, timers, troca de mensagens, etc. etc. É o que torna impossível usar determinados recursos do GObject porque o main loop da aplicação é Qt, e vice-versa.

Um outro problema da falta de uma API padrão, de que ninguém parece ter lembrado, é que existe duplicação de esforços na introdução de novos recursos gráficos (por exemplo, efeitos 3D). Via de regra, cada recurso novo tem de ser implementado tanto no X11 quanto na API de nível médio.

Como cada camada é mantida por times diferentes, que não se conversam, a conseqüência prática é o enorme e invariável atraso na "entrega" de recursos novos do X11 ao usuário final. Ou pior, a entrega com bugs porque as diferentes APIs não estão em sincronia.

O caso típico para mim é o gerenciador de janelas Compiz com os efeitos especiais. Não posso usá-lo nos meus computadores: não funciona no notebook por conta do X11, e embora funcione no Mac Mini, alguns programas (em particular os que usam OpenGL) "quebram" o Compiz.

No caso de um Windows ou um Mac OS X, tudo fica mais fácil. Qualquer necessidade de corrigir ou contornar bugs sempre pode ser feito na camada de API gráfica, porque é garantido que todas as aplicações passam obrigatoriamente por ela.

Bem, dito tudo isto, e já sendo um problema perfeitamente conhecido em 1997, todo o esforço da comunidade de software livre deveria ser concentrado na criação de uma API gráfica uniforme. Mesmo que não fosse a melhor possível, mas isso resolve-se com o tempo.

Infelizmente, a tal "liberdade", confundida largamente com barderna, estava tão em moda entre os nove-noves que diversas iniciativas diferentes foram criadas: Gnome, KDE, WindowMaker, Enlightenment, OpenStep, e assim por diante.

De início, o KDE tinha a melhor estratégia, porque baseava-se numa biblioteca gráfica madura, o Qt. A princípio esta decisão eliminou o maior problema do X11, que era a falta de biblioteca gráfica padrão. Infelizmente o KDE tinha alguns problemas, alguns criados por ele, outros derivados da "comunidade":

* O Qt, e portanto o KDE, eram baseados em C++. Por algum motivo que não compreendo até hoje, existe esta clivagem entre C e C++ no mundo GNU; distinção praticamente inexistente no Windows desde o início dos anos 90. Os GNU-chatos preferem C puro, e fazem questão de mantê-lo uma linguagem independente do C++. O resultado em 1999 era que o compilador era g++ era relativamente ineficiente.

Ao invés de melhorar o g++, a resposta dos GNU-chatos foi promover um ambiente gráfico em C puro, sendo que C puro é a linguagem mais inadequada possível para este fim. Não gosto de C++, porém ele é certamente melhor que C, para este fim.

* O Qt não era "livre", embora fosse de código aberto e de uso gratuito quando não-comercial. Mais um motivo para os GNU-chatos criticarem o KDE, motivo este que encontrou muito mais ouvidos receptivos, embora eu desconfie que no fundo o problema era mesmo o C++, e a licença do Qt foi usada como pretexto;

* O KDE cometeu, na minha opinião, um grande erro na sua API: "escondeu" excessivamente o Qt, de modo que uma aplicação KDE era desenvolvida de forma completamente diferente de uma aplicação Qt pura. Ou seja, paradoxalmente o KDE não ajudou o Qt a firmar-se como API gráfica padrão. Se o Qt tinha recursos faltando, tais recursos deveriam ter sido oferecidos como "qt-extras", passíveis de inclusão em versões futuras do Qt, e não como "kdelibs". Com o tempo, essa tendência do KDE utilizar APIs próprias ficou cada vez mais aguda, a ponto do KDE não adotar até hoje soluções como o GStreamer (na verdade adota, mas "esconde-a" numa outra API).

* Na onda do ponto anterior, o KDE oferece inúmeras aplicações diferentes no bojo do ambiente gráfico: jogos, editores, até navegador de Internet. Na verdade o KDE teve de fazer isso, porque apenas os aplicativos que utilizam as APIs KDE estão completamente integradas ao ambiente gráfico KDE; as outras aplicações ficam como peixes fora da água. Ou seja, a decisão de design obrigou o projeto KDE a criar inúmeros aplicativos, muito além do escopo do projeto (e da capacidade dos desenvolvedores envolvidos).

O resultado é uma quantidade grande de aplicativos cozidos pela metade -- cujo exemplo mais gritante é o KOffice.

* O KDE imitou muito de perto a aparência gráfica do Windows, o que era pragmático (atendia a necessidade dos usuários) porém jogou fora a oportunidade de tentar algo novo e melhor, que a tal "liberdade" proporciona.

--

O projeto GNU já tinha um ambiente gráfico promissor: o OpenStep, baseada no NextStep (no qual também baseia-se o Mac OS X). Embora fosse muito feio em 1998, ele tinha uma proposta interessante, em particular porque utilizava uma linguagem mais adequada que C e C++: o Objective-C.

Por algum motivo, o GNU largou o OpenStep em favor do projeto GNOME, talvez com a intenção de fazer frente mais prontamente ao KDE.

O GNOME baseia-se na biblioteca gráfica GTK+ (originalmente desenvolvida para o Gimp) e na biblioteca GObject. GObject é um animal sui generis, que recria um sistema de objetos em C puro, usando estruturas e macros. Isto atendeu à necessidade emocional dos GNU-chatos utilizarem C puro.

O GTK+ é muito mais fraco que o Qt, tanto em quantidade como em qualidade de recursos. Porém, existem hoje muito mais aplicativos bons GTK+ do que aplicativos Qt. GTK+ e GObject acabaram tornando-se o mais próximo que temos de uma API gráfica padrão. Ironicamente, os usuários preferem o ambiente gráfico KDE, mas preferem as aplicações GNOME. Por que isto aconteceu?

* Sendo o GTK+ uma API em C puro, atraiu a simpatia inicial dos GNU-chatos. Porém uma API em C puro tem outra vantagem importante: por ser um denominador comum pobre, é fácil oferecer a mesma API em qualquer outra linguagem de programação, através de "bindings". Os mecanismos do GObject permitem a geração desses "bindings" de forma razoavelmente automática. Já uma API em C++ é mais difícil disponibilizar em outras linguagens, porque o modelo de objetos é diferente em cada linguagem.

É prudente lembrar que a API de baixo nível do Windows é em C puro (embora "ninguém use-a" diretamente), e que o MFC em C++ parece estar caindo no ocaso.

* O GNOME não isolou o GTK+ do desenvolvedor. É perfeitamente possível uma aplicação GNOME utilizar de forma seletiva e opcional os recursos específicos do GNOME. Isto facilita o porte da aplicação para outros sistemas operacionais, ou a compilação de uma versão em GTK+ puro que funcione bem no KDE.

* O GNOME desistiu logo de tentar reinventar cada aplicativo, e com isso eximiu-se de ter de desenvolver aplicativos fora da sua área de competência. No início dos anos 2000, o GNOME tentou uma safadeza: açambarcar aplicativos como sendo "do projeto GNOME", como o OpenOffice e o Mozilla, que não utilizam nem GTK+. Essa tentativa de ganhar terreno sobre o KDE por usucapião não colou e foi abandonada, porém revelou-se mais certo a longo prazo não tentar reinventar cada aplicativo.

Os melhores aplicativos, como Pigdin, X-Chat, etc. têm vida própria, mesmo tendo sido inicialmente associados com o GNOME. Assim, o projeto GNOME evita ter responsabilidade por eles. O mesmo aconteceu com diversas tecnologias, como GStreamer, D-BUS etc. que estão hoje sob o guarda-chuva do projeto FreeDesktop e tendem a ser adotadas também pelo KDE.

--

A falta de API padrão para codecs tem conseqüências ainda mais óbvias. O único player que é realmente capaz de tocar "qualquer coisa" no Linux é o MPlayer, embora seja o pior em arquitetura interna. Parte deste poder do MPlayer é derivado da capacidade de usar DLLs de codec do Windows -- e naturalmente isso só é possível porque o Windows tem uma API padrão para DLLs de codec...

O GStreamer tem se firmado como API padrão de codecs e multimídia, mas ainda precisa melhorar muito na qualidade dos plugins, em particular os de vídeo.

Meia-oitos e nove-noves

Uma alegoria comumente referenciada no Brasil, que até virou história em quadrinhos do Angeli, é o Meia-Oito: aquele cara que ainda sonha com a vitória final do comunismo. Por ter tomado choques demais no pau-de-arara, o clock interno dele está quebrado, e o gettimeofday() ele retorna sempre a mesma coisa: zero, zero, zero... que corresponde a 01/Jan/1970. Para ele, os acontecimentos de 2008 interpretam-se com a mesma ótica de 1968: tudo é culpa dos EUA e do capital internacional, até a folha que cai no chão no outono... Todos nós temos pelo menos um conhecido assim.

Porém me ocorreu que temos um espécime parecido na área de informática: os "nove-noves", cujo "epoch" está travado em 1999. Assim como os meia-oitos, os nove-noves ainda sonham com a Microsoft ruindo fragorosamente, com o Linux dominando o desktop, e com os autógrafos do Richard Stallman e do Maddog.

Por esses dias, olhando um site de notícias sobre Linux e software livre, repentinamente me ocorreu que o teor das notícias não mudou muito desde que comecei a mexer com Linux, e lá se vão 10 anos:

* nova versão do KDE que conserta pela n-ésima vez os (mesmos) bugs do KMail;

* como o Linux vai tomar conta do desktop neste ano ou no próximo;

* HOWTO para usar determinado hardware extremamente popular mas que não funciona no Linux;

* Testes e comparações de distribuições;

* Lançamento de distribuição nova (a distribuição toda, não apenas versão nova);

* Algum artigo tentando explicar (sem conseguir) como se ganha dinheiro com software livre;

* Reclamações a respeito da censura da Internet na China, do traffic shaping, e das telecoms <MeiaOito:nojo> privadas </nojo>.

* Notícias sobre Microsoft devidamente acompanhadas dos comentários raivosos.

* Fundação do Grupo de Usuários Linux em Foo do Sul ou em Foo do Norte.

Como toda regra tem exceção, há dois tipos de notícia que eram figurinha fácil em 1999 e deixaram de ser hoje: IPOs e as brigas em torno de patentes de software.

O conteúdo dos sites está mais bonito, mais bem distribuído, tem Web 2.0 e Flash. Descontando isso, nada parece ter mudado. Se, por uma falha qualquer, aparecessem as notícias de 1999, muita gente só perceberia o problema quando aparecesse uma notícia de IPO bem-sucedido :)

Os comentários são a atração à parte das noticias e artigos que fazem o gosto dos nove-noves.

No Brasil, como a cultura "meia oito" recusa-se a morrer e consegue adeptos jovens, em particular nas universidades públicas, acaba rolando um acasalamento com a cultura "nove-nove". O resultado é o "meia-nove", um saco de gatos ideológico para quem expressões como "soberania digital" e "quilombo digital" fazem toooooodo o sentido. Mas isso é outra história.