blog.ademar.org

Seguindo o hype e o movimento de mudança de vários amigos e da internerds, resolvi experimentar o Chrome como meu browser principal. Migrei as abas abertas, fechei o firefox e deixei apenas o novo navegador do google no meu desktop (na verdade utilizei o Chromium, versão opensource do Google Chrome, como disponibilizado para o Fedora Linux 12).

No início fiquei muito impressionado com a velocidade do Chrome e me senti de certo modo aliviado em deixar o Firefox. Repeti algumas vezes pra quem estava próximo: “o Firefox está com os dias contados, não tem a mínima chance”.

Mas depois de 15 dias, estou voltando pro Firefox 3.5. Os ganhos em velocidade do Chrome não foram suficientes pra compensar as inconveniências e a (falta das) boas extensões do concorrente. O navegador do Google ainda tem que amadurecer um pouco até se tornar o browser definitivo.

O que eu gostei no Chrome:

• Rápido, muito rápido. Da inicialização aos sites carregados de java-script, o Chrome dá de lavada no Firefox;
• A ideia de um processo por aba/extensão e o isolamento entre eles me agrada;

Existem outras características e mudanças que são boas, mas que não fizeram diferença considerável no uso do browser.

Os principais inconvenientes, em ordem de prioridade:

• Não suporta master-password;
• Pra colar uma nova URL, é preciso clicar na barra de endereços (em outros browsers no Linux é só clicar com o botão do meio – colar – em uma área livre do browser); update: é só clicar com o botão do meio no botão de nova aba (thanks to Andreas)
• O Chrome usa $LC_CTYPE pra definir o idioma (o correto é usar $LC_MESSAGES ou $LANG);
• Force-reload não funciona como esperado;
• Compatibilidade com sites: foram poucos problemas, mas notavelmente mais do que com o Firefox. Alguns exemplos de sites que apresentaram um ou outro problema: gvt.com.br, mercadolivre.com.br, voeazul.com.br;
• Entre a omnibox do Chrome e a awesome bar do Firefox, eu prefiro esta última combinada com uma caixa de busca;
• Extensões, sempre elas: deixei esse item por último, mas talvez seja o que mais impactou minha produtividade. Pra mim as que fizeram mais falta foram: tabmixplus, echofon/twitterfox, delicious bookmarks, multiproxy switch, dns cache e web developper. Eu tentei substituí-las pelas alternativas do Chrome, mas estas ainda são muito fracas.

O que eu aprendi com essa experiência é que, contrário do que eu achava originalmente, trocar um browser não é tão simples como parece e o Chrome ainda tem muito chão pela frente até se tornar um browser maduro. Além disso também não vejo mais o Chrome como uma ameaça tão séria ao Firefox: levará pelo menos mais um ano até ele se tornar tão usável quanto e, até lá, quem sabe o Firefox 4.0 já esteja nas ruas incorporando suas principais características positivas.

De qualquer modo, é bom ver o aparecimento de uma nova “guerra dos browsers”. Tomara que dessa vez não haja um vencedor.

Acredito que seja útil pra mais gente: frequências e modelines para configurar a resolução nativa da TV LCD Philips 32PF5320 (HDTV 720p) no Xorg. A melhor coisa é fazer testes e experimentos com algumas dessas opções e modelines. Pode ser que na sua combinação de hardware e software as coisas funcionem de maneira diferente. Alguns dos meus testes foram feitos há mais de um ano, com um PC desktop, Nvidia 7600GS, Mandriva Linux 2008.0 (xserver-1.3), cabo DVI->HDMI. Outros testes foram feitos com um Notebook ThinkPad T61p (Nvidia Quadro FX 570M), Fedora 9 (xserver-1.4.99) e cabo VGA.


  # Philips 32PF5320
  HorizSync 29-80
  VertRefresh 48-85
  Option "UseEDID" "off" ## not sure if really necessary



  # Native resolution. The first one was perfect,
  # but YMMV, so you should run some tests
  Modeline "1368x768" 104.73 1368 1516 1660 1788 768 797 800 801 +hsync +vsync
  Modeline "1368x768" 104.73 1368 1400 1544 1784 768 769 772 801 +hsync +vsync
  Modeline "1368x768" 104.73 1368 1396 1540 1784 768 769 772 801 +hsync +vsync


Utilizando o meu desktop via HDMI eu não consegui eliminar uma perda nas bordas da tela, então criei uma modeline de resolução 1200×680 e usei a opção Option "FlatPanelProperties" "Scaling = Centered" do driver nvidia:


  # if you lose the borders, try a smaller resolution
  # and center it on the screen
  Modeline "1200x680" 74.25 1200 1390 1430 1650 680 725 730 750 +hsync +vsync


Eu criei essas modelines com o xvditune(1), mas por alguma razão tive que testá-las reiniciando o X, pois a função de teste ou apply do programa não estão funcionando no meu hardware. Novamente, YMMV. De qualquer modo, dá pra fazer ajustes reiniciando o X com as modelines geradas no xvidtune (finetunning no xvidtune, show, vim xorg.conf, reinicia o X, repeat).

Depois de dois meses utilizando um MacBook Pro, finalmente voltei ao bom e velho hardware IBM PC. No início achei que, como tantos amigos e ex-colegas de trabalho hoje ex-linuxers, eu também seria mordido pelo bichinho da maçã: me impressionei com algumas firulas e depois de ler sites como o Portal Mac do Aurélio, achei que iria me adaptar facilmente. Mas eu não demorei pra concluir que realmente não combino com o OS-X e assim que tive a oportunidade troquei o macbook por um ThinkPad.

Confesso que durante esses dois meses o aplicativo mais utilizado foi o VirtualBox rodando Linux, mas fiz um esforço pra utilizar o desktop do OS-X e me adaptar às aplicações disponíveis (sem grandes hacks que descaracterizassem o sistema), como experiência.

Eu respeito quem optou pela mudança – e olha que não foram poucos – mas pra mim o OS-X está muito longe de ser um sistema que me agrade. Minhas principais reclamações:

• Mouse com um botão;
• Design fresco :-P;
• Um ecossistema não livre (inclusive menos “grátis” do que o MS-Windows);
• Ctrl+C e Ctrl+V;
• Um browser (Safari) que teima em voltar a ser definido como padrão, mesmo com o Firefox3 instalado (evil!);
• Sistema de janelas extremamente limitado (sem desktops virtuais, finder é muito simplificado, etc);
• O botão de maximizar tenta ser inteligente (e não é);
• Sistema de instalação/remoção de aplicativos brain-damaged (eu poderia escrever um post sobre isso, mas vou dar uma de troll mesmo);
• Bugs como em qualquer outro SO (e-mail client travava, máquina algumas vezes congelava em suspend quando o monitor externo era reconectado, etc)

O livro Inside the Machine: An Illustrated Introduction to Microprocessors and Computer Architecture, de Jon Stokes (editor da Ars Technica), traz uma introdução de arquitetura de computadores – linguagem de máquina, pipelines, execução especulativa, processamento superescalar, caches, etc – e cobre em detalhes o funcionamento de vários processadores, começando pelo Intel Pentium e indo até o Intel Core 2 Duo.

O autor resolveu fazer um paralelo entre as famílias Intel e PowerPC, discutindo em detalhes processadores dessas duas linhas. Isso me desagradou um pouco, pois não tenho qualquer familiaridade com PowerPCs e, uma vez que a Apple resolveu adotar processadores da Intel, o uso dos PowerPCs tende a ficar restrito a alguns nichos.

O livro é relativamente pequeno (270 páginas), e deixou um “gostinho de quero mais”, pois ainda havia espaço pra discutir muitos assuntos. Em particular, senti falta de mais discussões sobre os processadores da AMD. Há apenas uma rápida explicação sobre o Athlon x86-64 no capítulo sobre computação de 64 bits, mas muito superficial se comparada ao espaço dedicado aos outros processadores.

Mas o livro no geral é muito bom. O autor usa uma linguagem clara e inclui várias ilustrações. Recomendo-o como livro introdutório a arquitetura de computadores e pra quem tem curiosidade sobre os detalhes de funcionamento dos processadores lançados na última década. É uma boa companhia pro livro Computer Organization and Design, a bíblia da arquitetura de computadores.

Espero que mais livros nessa linha sejam lançados. Um que cubra a evolução e funcionamento dos processadores gráficos (GPUs), por exemplo, será muito bem vindo.

Cerca de quatro meses depois do primeiro anúncio público, estou lançando oficialmente o mpp.py 1.0.

Não há grandes novidades (“features”), mas o programa agora está bem mais usável e estável, com cara de v1.0. Não tenho planos de fazer grandes mudanças no mpp.py. Melhorias devem aparecer de maneira orgânica, através de necessidades vindas de ademar.org/fotos ou contribuições. A principal possibilidade de melhorias é a adição de novos modelos, mas como sou um péssimo webdesigner, não me atrevo a ir além do basicão.

Mais detalhes na página oficial:

download | documentation | examples

Há algum tempo atrás, ainda em Manaus, lembro-me do Thiago perguntando “Existe algo como uma variável de ambiente COREDUMP_DIR?” Após alguma discussão sobre a viabilidade e uma rápida pesquisa, ele mesmo descobriu que não só é possível especificar um diretório, mas também onde e com que nome o kernel 2.6 deve guardar os arquivos de core-dump.

Para isso basta gravar uma máscara em /proc/sys/kernel/core_pattern de até 64 caracteres usando as seguintes variáveis:

  %%  o caracter '%'
  %p  PID do processo
  %u  UID real do processo
  %g  GID real do processo
  %s  número do sinal que causou o dump
  %t  hora do dump (em segundos desde 00:00h de 1970-jan-01)
  %h  nome do host
  %e  nome do arquivo executável do processo

Já o arquivo /proc/sys/kernel/core_uses_pid, bem mais antigo e mantido por questões de compatibilidade, controla se os arquivos de core devem ter ou não anexados a seu nome o PID do processo, sendo ignorado caso %p seja usado no core_pattern.

Por exemplo, para ter a máscara /var/tmp/corefiles/%e-%t-sig%s.core, sem PID, basta executar:

echo /var/tmp/corefiles/%e-%t-sig%s.core > /proc/sys/kernel/core_pattern
echo 0 > /proc/sys/kernel/core_uses_pid

Ou melhor ainda, adicionar a /etc/sysctl.conf:

kernel.core_pattern=/var/tmp/corefiles/%e-%t-sig%s.core
kernel.core_uses_pid=0

Se seu ambiente é multiusuário ou você espera gerar cores de um mesmo nome de processo com uma frequência maior do que de uma vez por segundo, recomendo a máscara /var/tmp/corefiles/%e-%t-%p-sig%s.core.

Algumas dicas:

• Lembre-se de deixar o diretório destino com stick-bit (chmod 1777) para que multiplos usuários possam ter seus cores guardados de maneira segura;
• Se seus programas não estão gerando core, verifique seu ulimit (comando ulimit -c e configuração em /etc/security/limits.conf);
• Pra testar, você pode usar um script bash contendo o comando kill -s SIGSEGV $$.

Mais informações em linux/Documentation/sysctl/kernel.txt

Depois de anos gerenciando minhas fotos utilizando uma versão ultra-hackeada do makethumbs.sh, finalmente tirei um tempo pra implementar meu próprio programa pra gerenciar os álbuns de fotos que disponibilizo em minha página (não, eu não gosto de usar o flickr). :-)

Creio que o principal diferencial do mpp.py é o suporte à geração de álbums a partir do XML exportado pelo Picasa(TM) do Google, mas segue uma lista de suas principais características:

• Páginas 100% estáticas (sem sql, php ou cgi)
• Baseado em modelos (templates)
• Importa fotos via XML do Google Picasa(TM)
• Importa fotos de um diretório local
• Suporte a múltiplos idiomas (i18n)
• Suporte a captions (texto sob cada imagem)
• Suporte a texto/html arbitrário nos albums
• Suporte a EXIF
• Open Source
• Simples, rápido, html limpo, CSS, etc…

Se você já tem o layout de sua página pronta e quer simplesmente adicionar as fotos nesse layout, o suporte a templates vem bem a calhar. E se você utiliza o Picasa(TM), a importação do XML é uma mão na roda. Se você não usa nada disso, deve gostar mesmo assim, pois de tantos milhões de programas pra gerar álbums na web, esse é sem dúvida o melhor de todos. ;-)

Testes em cenários diferentes são muito bem vindos.

Ah, a propósito, eu gerencio minhas fotos no Picasa(TM) e meu site é mantido num repositório SVN, então o que faço é exportar (XML) o álbum no picasa, rodar o mpp.py e subir os arquivos com o svn (svn commit, up, etc). Ficou bem prático, agora não tenho mais desculpas pra demorar tanto pra disponibilizar as fotos no site. :-)

Além do previamente mencionado CODING, a equipe da Mandriva Conectiva em Manaus também desenvolveu um modelo de build-system baseado em autotools (autoconf, automake, libtool) que acredito ser muito útil. Ele também estava destinado ao esquecimento, mas resolvi ressuscitá-lo e disponibilizá-lo sob a GNU-GPL.

Pra quem o conhece, a parte principal continua a mesma. Eu adicionei algumas funcionalidades (como a geração de bibliotecas, plugins, suporte a pthread) e um pouco de documentação.

Algumas características desse modelo:

• Recursos modernos do autoconf, automake e libtool;
• Modular, limpo e facilmente extensível;
• Suporte a unit-tests em C usando o check;
• Suporte a code-coverage dos unit-tests com lcov;
• Suporte a pkgconfig;
• Modo debug, flags de warnings do gcc, electric-fence, pthreads;
• make distcheck limpo e funcional;
• Integrado com doxygen;

Escrevi um pequeno README sobre o uso do modelo que deve ser suficiente para quem já tem os conhecimentos básicos e encontrei um extenso tutorial que deve ser útil até para quem já é experiente. De qualquer modo, vale o bom e velho conselho: “Use the source, Luke”, ele é relativamente intuitivo.

O código está disponível em meu repositório SVN git: http://git.ademar.org/, e deve ser atualizado conforme as necessidades ou contribuições sejam feitas.

BTW, o grosso do trabalho inicial foi feito ainda em 2005 e paradoxalmente, o autor original é o Leonardo Boiko (paradoxalmente porque quem conhece autotools e o leoboiko sabe que o primeiro é conhecido pelo número de gambiarras/xunxos e o segundo pelo às vezes absurdo perfeccionismo). Acho que quando ele ver esse modelo vai querer me matar pelas novas “gambiarras” que adicionei… :-)

Correções e contribuições, como sempre, são muito bem vindas.