This browser is a complete rewrite of the old Eve web browser, and is meant to be used on mobile devices. It is currently pretty complete, including tabs, bookmarks, and history. It also looks good to boot (thanks Marina!), as it is based on the Efenniht theme (click to open a larger version):

Screenshots won’t make it any justice though, as Eve is capable of some nice and smooth animations. I’m too lazy to make a screencast, so you’ll have to download and run it locally to see the interface at work

So Enlightenment users can benefit from this project, I’ve committed it to the Enlightenment SVN repository (on /trunk/eve). Also, there are some things that I didn’t have time to implement, so open sourcing this seems to be a nice idea: so, if you’d like to dive into the code, there are a few things that I’d like to have implemented on the browser… bug me on IRC (acidx @ freenode).

This will eventually speed up the maintenance of the EFL port, as build fixes do not require to be reviewed by someone else, and thus don’t require the use of the usually crowded commit queue.

There are various ways to get a monster like WebKit to compile faster, such as using ccache or icecream.

CCache is nice because I’m working with the build system, so I have to rebuild the whole thing often, even if I didn’t change a single line of code: ccache saves the object files somewhere in your home and only copies them instead of compiling it again, if there were no changes to the source code.

Icecream is also nice. Forked from distcc, icecream allows to distribute the compilation to other computers: add more nodes and the compilation goes faster. Compiling the kernel was never this fun before I’ve used this thing. There are some Gentoo users at ProFUSION that probably enjoys this thing as well.

And even though Icecream offers a nice program called Icemon with some nice visualization options, it is written for Qt3 — it works with Qt4 using the compatibility libraries — and crashes often. Since I was too lazy to debug this program, I’ve decided to write my own.

Called Picolé, it is an web-based monitor program. It felt natural to do a web-based program because I was working with WebKit; also, it can be installed on a server and there is no need for specialized client applications anymore. And since I’ve been longing to create something using AJAX for some time, this was the perfect opportunity.

The user interface is pretty simple. It offers two views: Hosts and Jobs.

Picolé’s main interface (click to enlarge)

The hosts view can display all the Icecream nodes in the network either in a table, or by using a star view, similar to the Icemon one.

The jobs view displays all the jobs being processed right now, and tells the language, file name, node that asked the compilation and node where the compilation is being performed.

The server is written in Python (using webpy) and it communicates through pipes with a program, written in C++, which communicates with the Icecream’s scheduler. The reason I’m not using a single programming language is that I didn’t want to rewrite the C++ part in Python, because I am using the same classes used by the Icemon program.

I got permission to distribute Picolé’s source code, but I need to clean it up and fix some stability problems. I’ll let you know whenever this happens.

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