SimCity Societies para Governantes Populistas

Anteontem li no blog do Roger Lovato uma análise do SimCity Societies, parece que agora o prefeito não precisa mais se preocupar com detalhes insignificantes e focar na satisfação do povo. Onde construir as residências? Pergunta pro assessor. Como a eletricidade vai chegar nas casas? Basta construir uma usina que ela chega sozinha. Transportes públicos? Ah, bota um metrô ali que as linhas aparecem. Onde? Não importa, acho que no subterrâneo, o que importa é que aparecem. E o dinheiro? É infinito! Responsabilidade fiscal é para fracos. O que interessa é a felicidade, e o amor, do povo.

Uma coisa que notei num dos trailers foi a constante visão de cartazes e telões enormes com uma figura que parecia ser o líder político da cidade. Algo desse naipe:

“Nosso Amado Stalin é a Felicidade do Povo”
(“Nosso Amado Stalin é a Felicidade do Povo”)

Vamos recapitular as duas qualidades chave do governante do jogo:

Acho que vou continuar com LinCity-NG ou o Super Trunfo com Políticos.

Update: pensando melhor, se é tão difícil gerenciar uma cidade com tantos detalhes, eles poderiam fazer um SimCity multiplayer com os jogadores assumindo vários papéis na administração da cidade. Provavelmente teria de ser assíncrono e hospedado num servidor, mas isso significaria mensalidades.

Anúncios

É uma cilada, Bino?

Hoje, Lauro e eu fomos como representantes do CInLUG, a uma palestra sobre interoperabilidade lá na sede da Microsoft, aqui no Recife.

(silêncio)

É, isso mesmo, e nem rolou uma situação “lavagem cerebral estilo Laranja Mecânica”. 😀

Conversamos com Fábio (esqueci o sobrenome), que é um cara com uma bagagem técnica muito boa e sabia do que falava; ele fez uma das melhores exposições sobre a história e situação do software livre/open source que já vi. Depois nos mostrou as tecnologias OpenXML e Silverlight, também rodou uns códigos PHP num Suse rodando dentro de um Virtual PC, dentro de um Vista.

Depois disso, aos negócios. A intenção da Microsoft é fazer contato com o pessoal da comunidade de Software Livre. A idéia geral é que eles se tocaram, e isso já faz um bom tempo, de que é bom ter softwares open source rodando na plataforma Windows. São muitos, são bons e agregam valor. É preciso se aproximar de quem produz e usa esses software. A mensagem é do tipo daquele antigo comercial “vem pra Caixa você também. Vem!”. Rodem suas aplicações aqui, é bonito e confortável, e temos cookies! A iniciativa teria sido inicialmente provocada pelas exigências do mercado e encontrou muita resistência interna. E externamente, bem, as pessoas têm dificuldade de confiar na Microsoft, e com razão, pois as trairagens do passado são muitas (e sempre aparecem algumas no presente).

Como eu disse lá no evento, uma pessoa pode confiar em outra pessoa, mas ninguém pode confiar numa companhia. Confiança de companhia é contrato, e em se tratando de software, uma licença de código aberto precisa me garantir as quatro liberdades básicas. Não falo isso só do ponto de vista filosófico, mas o mais pragmático desenvolvedor Open Source não contribuiria uma linha de código se não tiver as garantias (na licença, o contrato) de que não irão tirar proveito de seu trabalho, ou não usaria uma plataforma se houvesse a possibilidade de ficar preso nela.

Foi dito que o OpenXML é um padrão aberto e que o OpenOffice da Novell é o único com suporte a esse formato (não conferi, mas serve como exemplo possível). Ora, Software Livre não é sobre “o único que…”, é sobre “alguém implementou X? então todos temos X!”. Mas se o filtro OpenXML da Novell está coberto pelo acordo de patentes Novell-Microsoft, então ele é “aberto mas…”, sua licença é “livre, mas…”, e caímos numa situação Orwelliana “todos os animais são iguais, mas alguns são mais iguais que os outros”. Bem, pessoal, vocês desejarem cooperação é uma coisa boa, a divisão de Open Source não poder influenciar em algumas políticas infelizes da mastodôntica Microsoft não é surpresa, mas se querem um relacionamento sincero com as comunidades de Software Livre então sejam sinceros: “é, o OpenXML (ou SilverLight, ou qualquer outra coisa) é coberto por patentes, se vocês quiserem usar vão ter de trabalhar nesses limites aqui”. Não que informações sobre suas restrições legais seja uma grande revelação para as massas ignorantes (“oh, patentes! Jamais imaginei!”, e uma donzela desmaia do lado), mas sinceridade é uma iniciativa boa e ajuda as pessoas a saber com quem estão lidando, e podem decidir onde é possível cooperar em lugar de simplesmente dizer um “não” automático.

Em suma, as pessoas não querem coisas desse tipo:

The patent-protection pledge in Microsoft’s Open Specification Promise only protects what is explicitly specified in the standard. The Promise states that the company will not sue anyone for implementing the explicit parts of the OOXML specification; however, there are numerous implied, referenced, and undocumented facets and behaviors of the OOXML formats which, if implemented by another entity, would risk “intellectual property” (patent) violations against Microsoft software.

[Extraído de Achieving Openness: A Closer Look at ODF and OOXML]

Me parece que a “essência da coisa” do desenvolvimento aberto ainda está escapando da Microsoft. Você não pode restringir as condições nas quais alguém vai usar tal e tal tecnologia, não pode ser apenas no Windows, ou apenas naquele Linux ratificado pela Microsoft. Todas as empresas Open Source estão baseadas num tipo de colaboração que não pode sofrer esses tipos de restrições, sob o risco de quebrar o sistema. Imagine que você trabalha na Red Hat, na Canonical, ou é um desenvolvedor Debian, você colaboraria com o Moonlight da Novell sabendo que apenas ela pode usá-lo legalmente? Onde está o retorno? Acho que esse seria o primeiro exemplo real de “trabalhar de graça” do qual os programadores Software Livre eram acusados trocentos anos atrás. Estou exagerando?

Binary codecs for Windows Media video and audio, only licensed for use with Moonlight when running in a web browser. Other decoders will also work include Gstreamer and ffmpeg (used during the development stage) but Novell will not provide prepackaged version that include these libraries because of licensing and patent restrictions in the United States.

Wikipedia: Moonlight (runtime)

Outro ponto notável no discurso é que mesmo o Open Source estando tão em alta aos olhos da Microsoft, o Linux não está, assim como o Apache, o que não é uma surpresa, pois o negócio da Microsoft sempre foi plataformas de software, e a desejável posição de poder que vem junto. Até Bill G. já expressou como esse controle da plataforma já salvou sua empresa no passado:

“In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.”

Wikipedia: Vendor Lock-In – Microsoft

O Apache é um alvo particularmente interessante nesses tempos de aplicações Web, que tornam Linux e Windows relevantes apenas como porta de entrada pra internet, e muito foi falado sobre o Windows Server.

No geral a visita foi muito interessante, sinceramente, não estou falando por educação. 🙂 O pessoal lá parecia bem aberto e a discussão fluiu muito bem. Eles certamente encontrarão resistência, mas a iniciativa é válida e espero que a comunidade mostre boas maneiras. Como disse o Fábio, é preciso coexistir, até porque ninguém vai desaparecer.

Inimigo Meu
(cena do filme Inimigo Meu)

Maemo SDK Appliance, release 0.4 “Not So Fat”

Finally the new version of the appliance, and it is “Not So Fat” as we expected, since it is loaded of good stuff. See the Release Notes:

This release is loaded with a lot of goodies: Maemo 4.0 (Chinook) final and Maemo 3.2 (Bora) with Nokia Binaries Installer, PyMaemo packages, Vala compiler and its Hildon bindings for Chinook, Maemomm libraries, EVAS (Bora and Chinook, but i386 only), qemu-arm-eabi used as default cpu transparency method, Eclipse with ESbox plugin, and Firefox has now a lot of bookmarks for reference material. There are code samples for all the libraries and development packages cited above.

Checkout the ChangeLog entry:

* Scratchbox installed from official Debian Repository.
* Maemo 4.0 (Chinook) release.
* Maemo 3.2 (Bora) (the last release was using 3.1)
* Use the qemu-arm-eabi as default cputransp method
* Nokia Binaries Installer for Chinook and Bora
* Added a lot of bookmarks in Firefox for reference material.
* Maemomm (C++ bindings) added, with
code samples.
* EVAS libraries added to Bora and Chinook i386 targets, along with code samples.
* Eclipse 3.3.1.1 with CDT 4.0.1 and ESbox 1.2.0 plugins.

Watch a screencast on Google Video (YouTube doesn’t like Ogg/Theora, and I’m feeling very lazy to bother converting) with a sample session of using Eclipse with the ESbox plugin to create a Maemo project. For a higher resolution version, download the ogg.)

Download torrent from PirateBay (prefer this way; yarrr!):

Or direct download in two parts:

You will need 7zip to unpack the files.

Update: direct download link fixed. Thanks tabrez. 🙂

Qemu ARM EABI no Scratchbox

Se você está usando o PyMaemo deve ter reparado na mensagem de erro "sem_post: Function not implemented" quando chama o Python2.5 no target ARMEL do Chinook. Isso tem a ver, entre outras coisas, com funcionalidades não implementadas na versão do Qemu usada no Scratchbox. O Lauro Venâncio reuniu os patches necessários pra modernizar esse bicho, criou um projeto no SourceForge e pretende mantê-los sincronizados com o head do CVS do Qemu até os caras se dignarem a implementar as melhorias.

Se você quer usar o Qemu ARM EABI em seu Scratchbox, siga as instruções abaixo. Lembre de fechar quaisquer seções abertas do Scratchbox.

Compilar o Qemu ARM EABI

Na máquina host, instale o gcc-3.4 e baixe o qemu com os patches já aplicados.

$ sudo apt-get install gcc-3.4
$ svn co https://qemu-arm-eabi.svn.sourceforge.net/svnroot/qemu-arm-eabi/trunk qemu-arm-eabi
$ cd qemu-arm-eabi
$ ./configure --target-list=arm-linux-user --static
$ make

Update: o luck sentiu falta da zlib no processo de compilação:

$ sudo apt-get install zlib1g-dev

Update 2: o lauro resolveu organizar o repo dele, criando branches, tag e trunk. As instruções acima foram atualizadas.

Instalar no Qemu ARM EABI no Scratchbox

Como se pode ver, o binário gerado foi linkado estaticamente, então nada de dependências cabulosas, basta copiar para o lugar certo:

$ sudo cp arm-linux-user/qemu-arm /scratchbox/devkits/cputransp/bin/qemu-arm-eabi-sb2

Edite o cputransp-methods:

$ sudo vim /scratchbox/devkits/cputransp/etc/cputransp-methods

e adicione a linha:

qemu-arm-eabi-sb2

Depois edite o arquivo config do seu target (ou dos targets) ARMEL:

vim /scratchbox/users/USERNAME/targets/SDK_ARMEL.config

e altere a variável do método de transparência do CPU para:

SBOX_CPUTRANSPARENCY_METHOD=/scratchbox/devkits/cputransp/bin/qemu-arm-eabi-sb2

Veja também:

Dicionário Dandrader

Olá criançada, este é o Dicionário Dandrader de Termos Informáticos. Vamos aos nossos verbetes.

WORKAROUND: Arrudeio

Errado: “Zé Meleca fez um workaround no código.”
Certo: “Zé Meleca fez um arrudeio no código.”

DRAWBACK: Revertério

Errado: “Esta técnica apresenta alguns drawbacks.”
Tradução Automática: “Esta técnica apresenta alguns desenhar para trás.”
Certo: “Esta técnica apresenta alguns revertérios.”

TO FIX: Corrigir

Errado: “Lauro fixou o bug.”
Certo: “Lauro corrigiu o bug.”
Mais Certo Ainda: “Lauro corrigiu a falha.”

TO FILL: Preencher

Errado: “Talita fillou o bug.”
Quase Certo: “Talita preencheu o bug.”

Pensando bem, nesse contexto melhor trocar “preencher” por “relatar”.

Certo: “Talita relatou a falha.”

TO BRICK: Entijolar

Errado: “Luck brickou seu memory card.”
Certo: Luck entijolou seu memory card.
Mais Certo Ainda: Luck entijolou seu cartão de memória.

Nota: Os verbetes são colaborações de várias pessoas. Elas sabem quem são.

Update: Não podia deixar de fora…

VERBOSE: Verborrágico

Aparentemente Certo: “O GObject é engenhoso mas verboso.”
Certo e sem rima: “O GObject é engenhoso mas verborrágico.”

SQLite + Vala

Um dos efeitos colaterais do último post (e da insônia) foi que descobri porque não estava conseguindo usar os bindings Vala pra API C de SQLite. Nela existe a função exec, usada para executar statements SQL, que recebe como parâmetro uma função callback a ser executada após o término da query.

A função sqlite3_exec

int
sqlite3_exec(sqlite3*, const char *sql, sqlite_callback, void*, char**);

A assinatura da função callback em C é:

typedef int
(*sqlite_callback) (void*, int, char**, char**);

E no binding para Vala:

public static int
callback(pointer data, int n_columns, string[] values, string[] column_names) {
(...)

Estava tentando portar o código deste tutorial, para Vala, mas mesmo compilando terminava em segfault, mas antes disso mostrava uns dados totalmente errados.

Como você sabe bem, o compilador valac pode gerar código C, basta não usar a cláusula “-o outfile“: valac --pkg sqlite3 simplesqlite.vala, e pronto, são criados simplesqlite.h e simplesqlite.c, em lugar do costumeiro executável. Fiz isso e olhe só o que estava gerando:

gint
demo_callback (gpointer data, gint n_columns, int values_length1, char** values, int column_names_length1, char** column_names) {
(...)

O problema é que o valac transforma arrays de Vala em arrays de C precedidos de um inteiro que informa seu tamanho. Você pode evitar esse comportamento avisando ao compilador da seguinte forma:

[NoArrayLength ()]
public static int
callback (pointer data, int n_columns, string[] values, string[] column_names) { (...)

Passei um tempinho até descobrir isso (a documentação de Vala está nas fases iniciais de produção), tentei [NoArrayLength], mas resultava em char**, precedido de int, mas este era setado para -1. Cheguei a relatar um bug (487612), mas já corrigi a gafe.