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).

O mpp.py surgiu da necessidade que tenho de manter em sync minha página de fotos com meus álbuns gerenciados no Picasa (mais detalhes no post do primeiro anúncio público).

Hoje lancei a versão 1.1 do mpp.py. As grandes mudanças são a implementação de um cache do EXIF das imagens e muitas, mas muitas melhorias no código em geral.

Mais detalhes na página oficial:

download | documentation | examples

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.

Hoje gastei um tempo estudando softwares para tratamento de fotos no PC. É uma área onde nunca havia me aventurado. Gosto muito de fotografar, mas tratar as imagens nunca foi meu forte.

Mas isso está para acabar ;-), hoje evolui bastante e acho que estou encontrando o caminho das pedras. Cheguei a instalar (pela primeira vez) os softwares que acompanham a câmera e resolvi conferir o que encontrei após algumas pesquisas na web, tanto em Linux como Windows. Segue uma pequena avaliação:

• Gimp: Eu odeio a interface do Gimp. Como só tenho um monitor por enquanto, tenho muita dificuldade com aquele monte de janelas abertas ao mesmo tempo. É uma ferramenta muito poderosa, mas dada sua complexidade, ainda vou levar muito tempo pra ter uma boa produtividade. Fiz alguns testes com layers e li alguns tutoriais. O resultado é excelente.

• GimpShop: Como alguém que não se dá bem com a interface do Gimp, resolvi testar o GimpShop, na esperança de resolver meu problema. Como nunca usei PhotoShop, só esperava encontrar uma interface MDI, mas para minha decepção, o plugin que permite isso só está disponível pra MS Windows e mesmo assim o resultado é pouco satisfatório. No Linux não tive ganho algum, então voltei pro Gimp original.

• Picasa: Embora simples, gostei muito da ferramenta de edição de imagens do Google. Seguindo o princípio de Pareto, é a ferramenta ideal para quem quer fazer ajustes e efeitos simples, em fotos do dia-a-dia, sem muito trabalho. É pra Windows, mas há esperança. :-)

• Hugin: O hugin, um frontend pra diversos programas que facilitam o processo de montagem de imagens panorâmicas e compostas em geral, eu já acompanho há bastante tempo. É um pouco complexo, mas produz bons resultados.

• Ferramentas que acompanham a Canon EOS Digital Rebel XT: Achei todos os programas medíocres, com excessão do que monta imagens panorâmicas, que é razoável (simples, mas muito fácil de usar).

• Há ainda muitos outros programas que tenho usado com frequência para pequenas tarefas, como gqview, metacam, dcraw e os utilitários do ImageMagick.

Encontrei também um software para gerenciamento de fotos (armazenagem) que me deixou satisfeito a princípio: o Photo Organizer. Mas isso é assunto pra outro post. :-)