Os bugs do KDE 4.5 me obrigaram a fazer algo que estava evitando, usar o KDE 4.4.5. Tive bugs com a séries 4.4.0 até o 4.4.4, logo o medo era em parte justificado. Sorte que não se concretizou, os bugs do Plasma diminuíram, me permitindo usá-lo sem maiores incômodos. O que isso me ensinou? Que as vezes é bom esperar o último pacote de correções antes de usar em uma máquina onde estabilidade é importante. Parece algo óbvio, mas nem sempre é.

A partir de agora passei a aplicar a mesma política que usava com o compilador GCC, esperar umas 2 ou 3 versões menores antes de fazer uma atualização maior (ainda uso o GCC 4.4.4, sendo o atual o 4.5.1). Isso permite que boa parte dos bugs intrínsecos ou de compilação no Gentoo sejam resolvidos, diminuindo e muito a dor de cabeça gerada pelas atualizações. E o que é melhor, fazer isso sem necessariamente tornar todo o sistema atrasado, uma das vantagens do rolling release e do Gentoo em particular.

Bom, ainda recomendo usar a árvore de testes (~arch) do Gentoo se você é um usuário comum, mas ao fazer isso em uma máquina de produção é vital o bom uso do packages.mask, só assim é possível conciliar um sistema recente com algum grau de estabilidade. Até mais!

NOTA: O KDE 4.5 não entrará na árvore oficial até o lançamento do KDEPIM 4.5 e da correção de alguns bugs importantes! Cool!

A primeira permite fazer a vetorização de loops e a segunda torna as otimizações mais eficientes. Estas flags, em especial a -ftree-vectorize, possuem uma reputação ruim, devido a problemas em sua implementação e seu comportamento em ambientes 32 bits, onde ainda hoje causam problemas isolados.

Entretanto, tudo indica que o cenário no ambiente 64 bits é mais animador, permitindo inclusive o uso delas globalmente, definindo-as no make.conf. O meu atual Gentoo (~amd64) utiliza estas flags mesmo em pacotes problemáticos (ex: Mozilla Firefox) e não apresentou nenhum problema até o momento, sendo que se fosse 32 bits, normalmente eu receberia um Segmentation Fault bem bonito .

Com relação ao desempenho, geralmente leva a ganhos consideráveis, tendo observado algo em torno de 2% em compactadores. Possui efeito negativo em algumas aplicações, como o ffmpeg, mas no Gentoo não é problema, uma vez que nestes casos flags mais agressivas são filtradas.

Concluindo, se você utiliza o Gentoo 64 bits como desktop, seria bastante vantajoso ativar as flags -ftree-vectorize e -ftracer no seu make.conf, mesmo com um risco um pouco maior de encontrar bugs. Lembrando que não recomendo usá-las em ambientes 32 bits ou em arquiteturas diferentes da x86, por ter um histórico considerável de problemas.

# gcc -dumpspecs

Após ler o artigo sobre –as-needed do Gentoo percebi que poderia usar isso para forçar o uso de minhas LDFLAGS, umas vez que alguns pacotes não respeitam aquelas definidas no make.conf. O procedimento é bastante simples:

# export SPECSFILE=$(dirname "$(gcc -print-libgcc-file-name)")/ldflags.specs
# export CURRPROFILE=/etc/env.d/gcc/$(gcc-config -c)
# gcc -dumpspecs | sed -e '/link:/,+1 s:--eh-frame-hdr:\0 *SUASFLAGS*:' > "$SPECSFILE"
# sed "${CURRPROFILE}" -e '1i\GCC_SPECS='$SPECSFILE > "${CURRPROFILE}-ldflags"
# gcc-config "$(basename "${CURRPROFILE}")-ldflags"
# source /etc/profile


No caso, basta substituir o *SUASFLAGS* pelas suas LDFLAGS, no meu caso (que uso -O1 –as-needed –hash-style=gnu –sort-common) ficaria assim:

# gcc -dumpspecs | sed -e '/link:/,+1 s:--eh-frame-hdr:\0 -O1 --as-needed --hash-style=gnu --sort-common:' > "$SPECSFILE"

Esta dica deve ser usada apenas por usuários avançados e que sabem o que estão fazendo. Como visto no passos acima, basta usar o gcc-config para alternar entre os diferentes specs ou mesmo o GCC vanilla.

CHM (Microsoft Compiled HTML Help) é um formato em que páginas HTML são agrupadas em um único arquivo, bastante usado em arquivos de ajuda no Windows e em alguns ebooks. Eu prefiro os PDFs ou mesmo DJVUs para os meus ebooks, mas alguns só são encontrados em formato .chm, por isso tive que encontrar uma solução para ler estes arquivos no GNU/Linux. O programa eleito foi o xCHM, um leitor escrito em wxGTK e chmlib, funciona muito bem com os ebooks que testei. O Okular do KDE suporta chm e usa a mesma chmlib, entretanto, ele é bem mais lento e instável para lidar com estes ebooks, por isso acabei optando pelo xCHM, mesmo sendo um usuário do KDE.

O xCHM está disponível em praticamente todas as grandes distribuições e pode ser instalado facilmente. No Gentoo Linux, ele está na árvore oficial e pode ser instalado com o comando abaixo:

# emerge -av xchm

Espero que a dica seja útil, pois pra mim deu um trabalho e tanto achar um leitor de chm que realmente faz o que promete.

• Site oficial: http://xchm.sourceforge.net/

• Firefox 3.6.2 vs Firefox 3.7 alpha4
• Firefox 3.7 alpha4 vs Chromium 5.0.360.0

O resultado foi uma derrota impressionante do Firefox, o Chromium foi mais de 4x mais rápido no teste, o que mostra o belo trabalho feito pelos desenvolvedores. O Firefox com certeza tem melhorado seus tempos devido a concorrência com o Chrome, mas acho que precisam fazer mais, uma vez que ter mais e melhores extensões não vai mantê-lo no trono por muito tempo.

Pode ver o resultado completo e com detalhes sobre o sistema usado em:
http://dl.yporti.med.br/plain/sunspider_benchmark_20100207.txt

Inicialmente pensei no XFCE, mas ele ainda é muito dependente do GNOME, faltam muitos aplicativos e não possui uma integração muito boa. Os window managers mais simples foram considerados, mas como preciso de algo prático pra uso diário, com facilidades como montagem automática e coisas que esses gerenciadores não podem oferecer, a alternativa final foi o KDE 4.

O KDE não passa a impressão dos outros ambientes de ser um amontoado de coisas reunidas com um nome, ele realmente é integrado. Os efeitos gráficos são bem interessantes e, ao contrário do GNOME 3, podem ser desativados. O sistema de notificações e de gerenciamento de energia são muito legais, sendo que o último permite o uso de vários perfis (editáveis) diferentes.

Usei todas as versões do KDE 4 desde o 4.0 e sempre achei ele um tanto pesado, principalmente em termos de consumo de memória. Recentemente comprei um laptop mais potente, com processador de 2 núcleos e 2 GB de memória RAM, então o problema foi virtualmente minimizado. Descobri também que ativando a engine Raster no QT deixa os aplicativos KDE bem mais responsivos, isso ficou mais evidente no Dolphin.

Sobre o consumo de memória, até que não está ruim. O cold start do KDE 4.4 RC3, com Nepomuk/Srigi desativados, é de 200 Mb ± 4Mb. Se deseja utilizar o Nepomuk/Strigi, então adicione mais uns 100 Mb + algum tempo indexando. Quanto a bugs, no geral está bastante estável, alguns problemas no Nepomuk ainda persistem, mas devem ser corrigidos na versão final.

Pra quem usa Gentoo, recomendo que ativem as USE flags “raster” e “semantic-desktop”, a primeira permite ativar a engine gráfica Raster no pacote qt-gui e a segunda ativa o suporte ao Nepomuk/Strigi, que pode ser desativado no “System Settings” sem maiores prejuízos e sem ter que abrir mão de certos pacotes que requisitam esta USE flag, como o KMail.

Enfim, achei o KDE 4.4 um excelente ambiente gráfico e recomendo fortemente para máquinas com 1 GB ou mais de memória.

Veja também:

• Novidades do KDE 4.4

A máquina do teste era um Lenovo G530 Pentium Dual Core T3400 (2.16Ghz) com 2Gb de RAM rodando Gentoo ~amd64. Fiz vários testes além destes e os resultados foram muito parecidos. Resumindo, o bzip2 levou cerca de 60% mais tempo para concluir a operação requisitada, um ganho bem apreciável. Segundo o site do pbzip2 e benchmarks independentes, a vantagem só tende a aumentar conforme aumenta o número de núcleos, que no meu caso são apenas 2.

Você pode instalar o pbzip2 facilmente no seu Gentoo com:

# emerge -av pbzip2

Atenção à USE flag symlink, que permite criar symlinks do pbzip2 para o bzip2, fazendo com que ele se torne padrão para os usuários do sistema (exceto o root). Eu decidi substituir definitivamente o bzip2 do meu Gentoo e por isso fiz 2 ebuilds especiais para isso e em breve disponibilizarei no meu overlay pessoal. Entretanto, vale lembrar que ele pode vir a apresentar bugs, no caso dos usuários comuns, não há grandes riscos, mas sugiro cuidado a quem deseja, assim como eu, substituir o bzip2 original globalmente.

Gentoo

Use o eselect para ativar as configurações específicas, que são:

10-autohint.conf
10-sub-pixel-rgb.conf
70-no-bitmaps.conf

Para ativar os ajustes, basta usar o eselect fontconfig, cuja sintaxe é:

# eselect fontconfig enable #id

Para descobrir o #id, basta usar:

# eselect fontconfig list

No meu caso, as #ids são 1, 4 e 24. Logo, para meu sistema, devo executar os seguintes comandos:

# eselect fontconfig enable 1
# eselect fontconfig enable 4
# eselect fontconfig enable 24

Dica extra para o Gentoo

Se usa aplicativos que usam o cairo, é interessante ativar a USE flag “cleartype”, que aplica um patch ao Cairo para melhorar a aparência das fontes. Lembre-se, obviamente, de recompilar o cairo após ativar a USE no make.conf.

Debian

No Debian é até mais simples, basta usar o dpkg-reconfigure:

# dpkg-reconfigure fontconfig-config

Na configuração, selecione “Autohinter”, “Sempre” e “Não” para as perguntas. Tanto no Debian quanto no Gentoo, é preciso efetuar logoff para que as mudanças façam efeito na renderização das fontes.

Conclusão

Não posso garantir que a configuração seja melhor em 100% dos casos para todos os usuários, mas desde que descobri isso, nunca deixei de usar a suavização de fontes, que tornou as fontes bem mais legíveis e bonitas.