Testei o KDE 4.5 recentemente e tive vários problemas, do Dolphin aos efeitos visuais que deixaram de funcionar com minha placa de vídeo Intel. Em termos de mudanças, todas que notei (fora os bugs) foram positivas, o sistema de notificações e o “painel de controle” melhoraram muito em relação ao anterior.

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!

Uma das coisas que me irritam no Chromium é a falta de um gerenciador de certificados SSL, como o que existe no Firefox. Isso leva a uma coisa muito chata, que é ter que aceitar o certificado sempre uma nova sessão do navegador é aberta. Como recentemente ativei SSL para o meu blog, usei o CAcert para criar o meu certificado e por isso resolvi encontrar um meio de adicioná-lo como seguro no meu Gentoo. O fato curioso é que o Gentoo também usa o CAcert, logo, isso resolveria dois problemas de uma só vez, já que é bem irritante abrir o https://bugs.gentoo.org/ no Chromium.

Bom, achei a solução aqui. No Gentoo, precisamos ter o pacote dev-libs/nss compilado com a USE flag utils ativada:

# echo "dev-libs/nss utils" >> /etc/portage/package.use
# emerge -av1 nss

Depois basta executar como usuário comum:

$ wget http://www.cacert.org/certs/root.crt
$ wget http://www.cacert.org/certs/class3.crt
$ certutil -d sql:$HOME/.pki/nssdb -A -t "TCu,Cu,Tuw" -n "CACert Class 1 Root Certificate" -i root.crt
$ certutil -d sql:$HOME/.pki/nssdb -A -t "TCu,Cu,Tuw" -n "CACert Class 3 Root Certificate" -i class3.crt
$ rm root.crt class3.crt index.html?url=wget*

O procedimento é o mesmo para qualquer outra entidade de certificação. :~)

A primeira e talvez mais óbvia é que mudei o tema do blog, ainda mais minimalista e limpo em termos de código, já que foi criado do zero. Outra novidade é a largura variável, que se ajusta de acordo com a resolução do usuário, permitindo um melhor uso da área da tela. O código foi atualizado para o (X)HTML5 e claro, validados pelo W3C.

A segunda novidade e não tão aparente é que mudei de hospedagem, desta vez para um VPS (Virtual Private Server) rodando Gentoo, administrado por mim e pelo Rafael Martins. Neste VPS também estão hospedados o GentooBR.org e os blogs dos membros do projeto. As vantagens foram inúmeras, além de rodar numa plataforma que dominamos, acabou me permitindo resolver alguns problemas chatos que eu tinha com XMLRPC, além de acrescentar suporte a SSL e Gzip ativado por padrão (o que tornou o site visivelmente mais rápido pra quem tem conexões mais lentas).

Voltei a usar o KDE, desta vez o 4.5, após um tempo usando o GNOME notei que realmente é um ambiente um tanto ultrapassado e, o que é pior, as mudanças que virão não parecem ser das melhores, espero abordar isso em breve de forma detalhada.

O blog tem estado um tanto abandonado nos últimos tempos, com poucos artigos sendo publicados, mas não posso afirmar que isto irá mudar em breve. Minhas férias estão acabando e ao que tudo indica meu tempo disponível só tende a diminuir, ou seja, ou me torno mais eficiente ou o blog morre. Ou começo a postar vídeos.

Utilizando Nbench, resolvi fazer uma pequena série para avaliar o desempenho do GCC 4.5 em relação ao 4.4 e acabei extendendo os testes para avaliar também o efeito de algumas CFLAGS que utilizo, como ftree-vectorize, fvect-cost-model e o Graphite (-floop-strip-mine -floop-interchange -floop-block). Os testes foram realizados no Gentoo ~amd64, com resultados bem interessantes.

GCC 4.4.5 – snapshot 20100615
-O2 -march=native -ftree-vectorize -fvect-cost-model -floop-strip-mine -floop-interchange -floop-block -pipe

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :           981.4  :      25.17  :       8.27
STRING SORT         :          208.72  :      93.26  :      14.44
BITFIELD            :      3.9217e+08  :      67.27  :      14.05
FP EMULATION        :          137.96  :      66.20  :      15.28
FOURIER             :           23004  :      26.16  :      14.69
ASSIGNMENT          :          28.349  :     107.87  :      27.98
IDEA                :          6063.1  :      92.73  :      27.53
HUFFMAN             :          2019.2  :      55.99  :      17.88
NEURAL NET          :          45.324  :      72.81  :      30.63
LU DECOMPOSITION    :          1422.7  :      73.70  :      53.22
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 66.670
FLOATING-POINT INDEX: 51.972
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual GenuineIntel Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz 2166MHz
L2 Cache            : 1024 KB
OS                  : Linux 2.6.34-blackbird-r1
C compiler          : x86_64-pc-linux-gnu-gcc
libc                :
MEMORY INDEX        : 17.837
INTEGER INDEX       : 15.790
FLOATING-POINT INDEX: 28.826
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

GCC 4.5.1 – snapshot 20100708
-O2 -march=native -ftree-vectorize -fvect-cost-model -floop-strip-mine -floop-interchange -floop-block -pipe

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1005.4  :      25.78  :       8.47
STRING SORT         :          203.52  :      90.94  :      14.08
BITFIELD            :      3.9412e+08  :      67.61  :      14.12
FP EMULATION        :          130.48  :      62.61  :      14.45
FOURIER             :           23004  :      26.16  :      14.69
ASSIGNMENT          :          29.996  :     114.14  :      29.61
IDEA                :          6187.6  :      94.64  :      28.10
HUFFMAN             :          2027.8  :      56.23  :      17.96
NEURAL NET          :          47.762  :      76.73  :      32.27
LU DECOMPOSITION    :            1435  :      74.34  :      53.68
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 66.949
FLOATING-POINT INDEX: 53.039
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual GenuineIntel Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz 2166MHz
L2 Cache            : 1024 KB
OS                  : Linux 2.6.34-blackbird-r1
C compiler          : x86_64-pc-linux-gnu-gcc
libc                :
MEMORY INDEX        : 18.054
INTEGER INDEX       : 15.762
FLOATING-POINT INDEX: 29.417
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

GCC 4.5.1 – snapshot 20100708
-O2 -march=native -ftree-vectorize -fvect-cost-model -pipe

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1009.4  :      25.89  :       8.50
STRING SORT         :          215.36  :      96.23  :      14.89
BITFIELD            :      3.9747e+08  :      68.18  :      14.24
FP EMULATION        :          130.76  :      62.74  :      14.48
FOURIER             :           22996  :      26.15  :      14.69
ASSIGNMENT          :          29.107  :     110.76  :      28.73
IDEA                :          6172.6  :      94.41  :      28.03
HUFFMAN             :            2027  :      56.21  :      17.95
NEURAL NET          :          47.562  :      76.40  :      32.14
LU DECOMPOSITION    :          1427.7  :      73.96  :      53.41
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 67.315
FLOATING-POINT INDEX: 52.869
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual GenuineIntel Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz 2166MHz
L2 Cache            : 1024 KB
OS                  : Linux 2.6.34-blackbird-r1
C compiler          : x86_64-pc-linux-gnu-gcc
libc                :
MEMORY INDEX        : 18.265
INTEGER INDEX       : 15.775
FLOATING-POINT INDEX: 29.323
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

GCC 4.5.1 – snapshot 20100708
-O2 -march=native -ftree-vectorize -pipe

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1007.2  :      25.83  :       8.48
STRING SORT         :           215.2  :      96.16  :      14.88
BITFIELD            :      3.9701e+08  :      68.10  :      14.22
FP EMULATION        :          130.72  :      62.73  :      14.47
FOURIER             :           22861  :      26.00  :      14.60
ASSIGNMENT          :          29.182  :     111.04  :      28.80
IDEA                :          6147.1  :      94.02  :      27.91
HUFFMAN             :          2027.8  :      56.23  :      17.96
NEURAL NET          :          47.562  :      76.40  :      32.14
LU DECOMPOSITION    :          1422.4  :      73.69  :      53.21
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 67.262
FLOATING-POINT INDEX: 52.700
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual GenuineIntel Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz 2166MHz
L2 Cache            : 1024 KB
OS                  : Linux 2.6.34-blackbird-r1
C compiler          : x86_64-pc-linux-gnu-gcc
libc                :
MEMORY INDEX        : 18.269
INTEGER INDEX       : 15.751
FLOATING-POINT INDEX: 29.229
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

GCC 4.5.1 – snapshot 20100708
-O2 -march=native -pipe

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1000.3  :      25.65  :       8.43
STRING SORT         :          214.48  :      95.84  :      14.83
BITFIELD            :      3.9277e+08  :      67.37  :      14.07
FP EMULATION        :          132.48  :      63.57  :      14.67
FOURIER             :           23004  :      26.16  :      14.69
ASSIGNMENT          :          29.353  :     111.69  :      28.97
IDEA                :          6168.6  :      94.35  :      28.01
HUFFMAN             :          2033.5  :      56.39  :      18.01
NEURAL NET          :          42.726  :      68.64  :      28.87
LU DECOMPOSITION    :          1426.9  :      73.92  :      53.38
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 67.306
FLOATING-POINT INDEX: 51.009
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual GenuineIntel Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz 2166MHz
L2 Cache            : 1024 KB
OS                  : Linux 2.6.34-blackbird-r1
C compiler          : x86_64-pc-linux-gnu-gcc
libc                :
MEMORY INDEX        : 18.219
INTEGER INDEX       : 15.801
FLOATING-POINT INDEX: 28.292
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Notei que algumas CFLAGS se comportam melhor no ambiente 64 bits e podem proporcionar, de forma geral, um desempenho maior aos pacotes compilados. As flags são -ftree-vectorize e -ftracer.

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.

Alguns professores tem exigido o uso de algumas normas da ABNT nos trabalhos desenvolvidos para o meu curso de Engenharia. Como usuário do LaTeX, não me agrada muito ter que usar o OpenOffice para desenvolver meus trabalhos. Felizmente, há alguns dias descobri um pacote LaTeX com classes para normas ABNT, o abnTeX.

Com o abnTex fica facil formatar os trabalhos utilizando as normas ABNT, através de poucos e simples comandos.

Usuários Gentoo podem contar com um pacote para o abnTeX, desenvolvido por mim, e presente no meu overlay. Para instalar basta seguir as instruções, aqui:

http://overlay.rafaelmartins.eng.br/

O pacote possui suporte ao LyX e à instalação da documentação (recomendável) através de USE flags (lyx e doc, respectivamente).

Bons trabalhos, e até a próxima!

O comportamento padrão do GCC pode ser alterado via Specs, que são arquivos contendo as instruções sobre quais flags usar e em que circunstâncias. Você pode olhar a spec padrão do seu GCC com o comando:

# 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/

Hoje compilei o Mozilla Firefox 3.7 alpha4 para ver como estão os progressos com a engine javascript e o resultado foi bastante animador, segundo o benchmark do SunSpider, está 2x mais rápida que a versão atual 3.6. Também fiz a comparação com uma build atual do Chromium e podemos ver que o Firefox está cada vez mais próximo do concorrente mais forte em termos de engine javascript.

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

Já a algum tempo está no ár o site do g-octave e eu esqueci de avisar aqui.

Trata-se de uma instancia do Trac, excelente software para visualização de código-fonte em SCM's, administração de documentação (wiki) e bug-tracking.

Segue o link:

http://g-octave.rafaelmartins.eng.br/

Até a próxima!