Com pequenas alterações no egg-markdown (encontrado nos fontes do GNOME PackageKit), e uma versão estendida do GtkTextView que suporta hyperlinks, comecei a fazer um leitor de documentação leve, com o intuito de ser incluso em aplicações GTK+. Existem alguns problemas a serem resolvidos, entretanto:

• Inclusão de imagens;
• Suporte à internacionalização;
• Encontrar uma maneira eficiente de armazenar um arquivo de ajuda;
• Índice para busca textual (a princípio, somente para cabeçalhos nível 1 e 2).

Resolver o primeiro vai dar um bocado de trabalho, pois estender o markup do Pango é muito chato. Os links são implementados de uma forma meio hackish (usando atributos geralmente não usados do tag <span>) e eu não queria ter que implementar imagens dessa forma também.

Para os curiosos e interessados em ajudar a terminar a implementação, o código está disponível no github. Forks e pull requests são aceitos.

Demorei tanto para lançar esta versão que, ao invés de numerá-la 0.4.3, resolvi numerá-la de 0.5. As novidades já anunciadas estão obviamente inclusas, mas existem algumas outras:

• Adição de novos benchmarks (Transformada Rápida de Fourier, N-Rainhas e Junção dos testes de cálculo de MD5 e SHA-1 em um único benchmark);
• Suporte para UPS da APC (através do apcupsd);
• Exibe informações sobre cada cache do processador;
• Porte para libsoup 2.4;
• Atualização da lista de fabricantes via rede;
• Correções de defeitos e vazamentos de memória.

Como sempre, todo o código fonte pode ser obtido no site ou diretamente do GitHub. Algumas distribuições já empacotaram esta versão (procure no gerenciador de pacote delas). Infelizmente, não consegui lançar esta versão a tempo dela aparecer no Ubuntu 9.04; mas pacotes prontos são distribuídos no GetDeb.

• Benchmarks com suporte a processadores multicore
• Suporte à interfaces de rede sem fio (mostra coisas como SSID, potência de transmissão, etc)
• Suporte à DMI (mostra o fabricante da placa mãe, etc)
• Exibição da alocação de recursos de I/O (portas de I/O, memória e DMA)
• Suporte à nova interface de USB do kernel 2.6
• Polimento da interface gráfica
• Melhorias na estabilidade, consumo de memória, etc

Está disponível aqui, por enquanto apenas para x86. Agradeço quem puder testar e comentar.

Uma das funcionalidades que os usuários do HardInfo mais pedem é a realização de benchmarks levando em consideração máquinas multiprocessadas. Somente depois de conhecer o modelo fork-join que a OpenMP usa, que eu consegui implementar isso no HardInfo. Para quem não conhece esse modelo, é bem simples: em pontos paralelizáveis de seu código, n linhas de execução são criadas (aqui, n equivale ao número de núcleos) — e a execução linear do programa só retoma após um ponto de encontro. A criação das threads é o “fork”, e o ponto de encontro é o “join”.

A OpenMP facilita a vida provendo alguns #pragmas: o compilador com suporte a ela, então, gera o código responsável pela criação das threads e pelo ponto de encontro. Um desses pragmas é o “parallel for“, que divide um laço ao estilo do for em n linhas distintas. Essa construção tem suas limitações — só deve ser usada em laços vanilla: aqueles que apenas contam de um número até outro (a linguagem C permite fazer praticamente qualquer coisa num for e isso não é suportado pela OpenMP).

Como os benchmarks do HardInfo são geralmente feitos dentro de um laço for, repetindo testes pequenos várias vezes e contando o tempo (o que causa alguns problemas de precisão, mas ainda não consegui encontrar maneira melhor), recriar essa construção do OpenMP foi a saída mais natural.

A recriação foi trivial: o modelo é simples e eu tenho como obter o número de núcleos tranquilamente (afinal, o HardInfo é um programa de informações de hardware). Como a implementação foi feita sem requerer suporte do compilador (apenas usando funções), há a necessidade da criação de uma função, e da substituição do laço por uma chamada de função.

Por exemplo, se houvesse o interesse em paralelizar o seguinte código:

for (i = 0; i < 1000; i++) {
    vetor[i] = i * 3;
}

Eu criaria uma função:

void preenche_vetor(guint start, guint end, gpointer data)
{
    int *vetor = (int *)data;
    for (i = start; i < end; i++) {
        vetor[i] = i * 3;
    }
}

E substituiria o laço por uma chamada ao paralelizador de for:

parallel_for(preenche_vetor, 0, 1000, vetor);

A função parallel_for então determinaria o número de núcleos, criaria uma linha de execução para cada elas, e se encarregaria de esperar pelo término de todas elas. Como bônus, ela também retorna o tempo gasto desde a criação das threads até o término de todas elas — ignorados neste exemplo.

Paralelizei dois benchmarks no HardInfo: o de compressão/descompressão com a zlib, e o ray tracer. O ganho, em um Pentium Dual Core (E2160), foi da ordem de 1,86x mais rápido no caso da zlib, e 1,41x no caso do ray tracer.

O código está disponível no repositório git mestre do HardInfo, disponível na minha conta do github.

Obviamente que meu Macbook (com um Core 2 Duo de 2.16GHz) come com farinha o Atom de 1.6GHz. Mas a plaquinha se mostrou valente e, para tarefas básicas — que, no meu caso, inclui não somente a internetada básica de todo dia, mas programação leve, edição de textos, — eu diria que é mais que o suficiente. O único porém, é que coisas como vídeos no YouTube (e outros sites de vídeo) dão uma certa engasgaada… mas video em Flash judia até mesmo o C2D, então é perfeitamente perdoável.

Por exemplo: do boot loader até o desktop do Leopard, são apenas 28 segundos. É fato que a instalação do sistema no meu Macbook é mais antiga, mas ela demora pelo menos o triplo disso. E os discos e o chipset das duas máquinas são equivalentes.

Enfim: quem quiser um Macintosh barato, é uma opção legal. Por US$79 (mesmo com o dólar disparado como está), é um excelente negócio. Mas quem quiser um computador secundário (como máquina de downloads, servidor de arquivos caseiro, ou simplesmente para as tarefas do dia-dia), que consome pouco e é muito silencioso, é uma opção tão boa quanto.

Eu gostei bastante da placa. Tanto que eu a vendi! Quando vi que a Intel tinha lançado a D945GCLF2, com o Atom 300 (dual core) e, principalmente, saída S-Video, precisei vender e comprar o modelo mais novo… eu estava querendo montar um HTPC já faz um tempo e essa placa (nova) veio bem a calhar.

Eu poderia dizer que, a princípio, é apenas mais um caso de síndrome de NIH.

Acho que o Google só não reinventou o WebKit pq um interpretador de JavaScript é mais fácil fazer. E o lançamento do compilador Java para o Android, IMHO, diz que o povo lá em Mountain View gosta de brincar com compiladores e interpretadores.

Para fazer um interpretador mais rápido que outro feito por especialistas, requer gente muito foda. E é isso que tem nos times do SF, V8 e SM: cara bão de código. Mesmo acreditando que concorrência seja uma boa idéia, se juntassem os esforços (afinal é tudo free — o problema de licenciamento é “resolvível” com boa vontade) e fizessem uma única implementação teríamos, provavelmente, algo muito legal por aí.

Mas a síndrome de NIH não deixa isso acontecer. Reinventar a roda é bom e às vezes necessário.

O interesse por linguagens dinâmicas está crescendo muito ultimamente. Acho que nenhuma empresa fazendo um novo interpretador de JavaScript esteja dando ponto sem nó: provavelmente estão usando isso como desculpa para desenvolvimento (ou o aprimoramento) de novas técnicas. E é sempre mais fácil trabalhar no seu próprio código que modificar o código dos outros — principalmente quando se está falando de uma reestruturação completa da sua arquitetura.

Eu não tenho acompanhado artigos sobre compilação/interpretação, mas o (antigo, confesso) material impresso que tenho acesso sobre compiladores fala principalmente sobre linguagens de tipagem estática. Isso, em minha opinião, é reforçado ainda mais pela característica acadêmica tanto do Google quanto da Apple.

Tentar remover o pacote “pulseaudio” no Ubuntu 8.04 produz um erro de dependência, já que o pacote “ubuntu-desktop” necessita dele. Uma solução simples é usar o excelente utilitário “equivs” e criar um pacote falso que provê e substitui o pulseaudio, sem conter nenhum tipo de arquivo no pacote (um pacote já construído pode ser encontrado aqui).

Com esse pacote criado, é fácil remover o cara chato:

$ sudo dpkg -i pulseaudio-fake_1.0_all.deb
$ sudo dpkg --purge pulseaudio

Pronto. Sem mais processos bloqueando indefinidamente pro causa do PulseAudio

Isso causa um pouco de poluição no sistema de arquivos, e faz com que a execução do programa quando não instalado (principalmente quando se usa um ambiente de desenvolvimento onde não se tem acesso a usuário root) um bocado difícil. Existem alternativas — no HardInfo eu uso o binreloc (que permite guardar esse tipo de arquivo em locais diferentes dos hardcoded durante a compilação), parte da suíte do Autopackage — mas para alguns tipos de arquivos seria interessante que os dados estivessem dentro do próprio executável.

Alguns sistemas operacionais permitem a inclusão de uma seção de recursos. Provavelmente power users de Windows e MacOS já usaram programas de edição destes recursos inúmeras vezes: alterar ícones, telas e até mesmo tabelas de dispositivos de extensões do MacOS. Mas no Unix não existe uma maneira única para esse tipo de seção.

Lendo o Planet GNOME, vi um post do Ross Burton sobre o tema. Lá ele explica como fazer isso usando um truque com o ld (GNU Linker) e objcopy (utilitário do binutils) — e um leitor do blog dele mostra um truque mais legal ainda, usando o as (GNU Assembler). Baseado no post dele e nos comentários, eu fiz um script shell que gera tanto o arquivo objeto (funcionou em x86, x86-64 e sparc64) quanto um cabeçalho com a referência ao arquivo.

O cabeçalho possui uma definição do tipo extern char nomearquivo_extensao[1000];, onde 1000 é o tamanho do arquivo — o que ajuda um bocado em algumas situações (como no glade_xml_new_from_buffer).

Enfim, o script está disponível aqui.

Comentários?

Mas as placas-mãe Mini ITX sempre chamaram a minha atenção: computadores com baixo consumo de energia, silenciosos e de pequeno porte são chamativos, mesmo. O problema é que essas placas sempre custaram muito mais caro que uma placa de desktop convencional. Aí entra a Intel e lança uma placa, baseada no Atom, que custa US$80 — processador incluso.

Pois bem — comprei a D945GCLF no eBay. Chegou em menos de um mês, mas eu esqueci de comprar junto com a memória. Encomendo a memória e aguardo angustiadamente os 30 dias para que ela chegue. Chegou ontem — e, obviamente, já fui instalar algum sistema operacional para começar a usar a placa.

Escolhi o Mac OS X: a placa, segundo o wiki do projeto OSX86, é 100% compatível com o Leopard, e é basicamente a maneira mais barata de você ter um Hackintosh (importante para mim, já que meu Macbook está na assistência técnica). Por três tentativas, a instalação travava (e travava feio, de encher a tela de lixo). Logo desconfiei da memória: no Setup do BIOS alguma coisa já alertava, afinal o sistema reconhecia o pente como tendo 17592186042368MB de RAM, claramente detectado erroneamente (afinal o pente tem 2GB).

Meu CD com memtest86 estava emprestado, então procurei uma versão que funcionasse a partir de um pendrive. Dito e feito: nunca vi uma tela do memtest86 tão vermelha. E, além disso, depois do segundo teste, mais lixo na tela.

Enfim: memória incompatível. Testei em um Athlon 64 e funcionou perfeitamente sem nenhum erro, portanto eu estou vendendo pelo mesmo preço que paguei lá fora (R$80), para que eu possa comprar outra memória compatível com minha placa.

De qualquer maneira, gostei bastante dessa placa: o preço é atraente e a performance (pelo menos o instalador do OS X carregou e pude ter uma noção do que o Atom — um processadorzinho de 64-bit com HyperThreading — é capaz com seus 4W de pico de potência). Mas só há uma maneira de continuar os meus testes: arrumar um pente de memória compatível… portanto ajudem-me, comprando o pente

O que me entristece é que o povo que realmente está fazendo um trabalho legal — os desenvolvedores do Haiku — vão receber uma mísera porcentagem do alto preço da camiseta. Eu poderia ter feito a doação integral para o time e não ter ficado com dor de cabeça por alguns instantes.

Enfim — se você pensar em comprar camisetas (ou qualquer outra coisa) na Cafepress, pense novamente. Não vale o que cobram. Até eu faço uma estampa melhor com papel transfer e impressora jato de tinta.