Requisitos para trabalhar com ferramentas Open Source

Quando se apresentam as vantagens teóricas e práticas das ferramentas informáticas Open Source é raro falar-se em profundidade dos requisitos que estas apresentam, ao contrário do que acontece na maior parte das vezes que se discutem ferramentas proprietárias. É natural que assim seja: como estas ferramentas são abertas e livres, não existe, de facto, uma lista de “exigências” e (in)compatibilidades, como acontece muitas vezes com as ferramentas proprietárias, que as apresentam, muitas vezes, apenas por interesses comerciais e sem nenhum fundamento técnico. A diversidade de distribuições de algumas destas ferramentas, disponíveis para variadíssimos “sabores” de Linux, mas também para Windows e Mac OS X, com bastante frequência, tornam ainda mais complicado falar de “requisitos” e promovem a ideia de que todas elas funcionam igualmente bem em qualquer ambiente. Numa primeira abordagem e para uma utilização pacata, suspeito que isso corresponda à verdade e essa é mais uma das razões para que não se levante frequentemente este problema dos “requisitos”, mas se nos debruçarmos mais a sério sobre estas ferramentas e se fizermos uma utilização intensiva, comparando-as com as concorrentes comerciais, começamo-nos a deparar com dificuldades estranhas e muitas vezes pouco documentadas. Especialmente se, como eu, adoptarmos várias ferramentas open source, mas não formos rigorosos militantes do modelo FLOSS— ou seja, não só mantenho como sistema operativo o Mac OS X, como preciso de ver a vantagem técnica das soluções open source, já que as morais, que não menosprezo, em momentos de crise podem não ser suficientes para não me impedir de fazer o meu trabalho.

O dia de hoje— como todos os momentos cruciais de finalização e entrega de trabalhos de design de alguma dimensão desde que comecei a usar intensivamente o GIMP, o Inkscape e o Scribus— voltou a fazer-me pensar, dolorosamente, nesta questão. Sendo, teoricamente, ferramentas muitíssimo potentes e perfeitamente capazes de realizar as mesmas tarefas que as mais avançadas soluções comerciais e tendo eu a experiência de assistir à demonstração disso mesmo ou fazer essas demonstrações eu próprio, a verdade é que, em velocidade de cruzeiro, na configuração que eu tenho neste momento, a performance é dolorosa.

Os problemas maiores que me afligem dividem-se em 3 grandes áreas:

  • Gestão de memória: quando trabalho com ficheiros grandes (imagens raster de grandes dimensões no GIMP, ficheiros com muitos objectos ou geometrias complexas no Inkscape, documentos de grande dimensão no Scribus…) operações relativamente simples demoram imenso tempo, recordando os processos de edição digital de há 10 anos atrás. Em determinados períodos isso não é mau; dá-nos tempo para pensar, ajuda a gerir as pausa, etc. Mas numa fase final de produção de elementos para impressão, em contra-relógio, é exasperante. E se fosse para ter a performance de há 10 anos atrás, não se justificava ter máquinas recentes, com processadores recentes e memória adequada.
  • Instabilidade: na altura da verdade, tenho sido presenteado com freezes e crashes como nunca tinha visto (eu nunca usei Windows para trabalho). E, se no GIMP a instabilidade parece estar directamente relacionada com o problema da gestão de memória, já que só se nota com ficheiros de grandes dimensões (apesar de haver um ou outro filtro ou extensão pouco recomendável, também pelos imensos ficheiros que gera, mesmo que temporariamente), quer no Inkscape, quer no Scribus, chego a pensar que a condição necessária e suficiente para ter um freeze ou um crash é estar a trabalhar em algo de que precise durante algum tempo. Bem sei que tem que haver um padrão e já identifiquei algumas operações “sensíveis” nas duas aplicações, como agrupar e desagrupar grandes quantidades de objectos, aplicar máscaras e clipping paths no Inkscape, tentar abrir a janela de impressão no Inkscape, manipular elementos vectoriais importados no Scribus, obrigar o Scribus a muitos redraws, através de zooms e pans… Mas a instabilidade das aplicações, para quem vem dum universo Macintosh, é um pesadelo kafkiano e em momentos críticos, crashes a cada 5 minutos, como tenho tido quando estou a finalizar a composição de MUPIs, por exemplo, faz perder qualquer esperança no benefício kármico de usar software livre.
  • Compatibilidade: este problema não é tão grave como os outros do ponto de vista de performance, uma vez que é algo a que já estamos habituados nas soluções comerciais, mas é estranho que os SVGs do Inkscape, por exemplo, tenham alguma dificuldade de importação no Scribus se usarem algumas funcionalidades, como máscaras, clipping paths ou transparências e que, mesmo que não tenham essas características, percam referências de dimensão e cheguem fora de formato ao Scribus. Via EPS ou PDF damos a volta a esta questão, mas é estranho. Como é estranho que o Scribus importe ficheiros .PSD, formato proprietário do Photoshop, mas não .XCF, formato nativo do GIMP. Ou que seja preciso recorrer ao Scribus para ter uma imagem em quadricromia feita no GIMP. Ou…

O facto destas questões (algumas delas, pelo menos) não serem abordadas como assuntos sérios nas comunidades de utilizadores e dada a diversidade e exigências de uso a que elas têm sido submetidas, levam-me a depreender que, apesar de “funcionarem” em muitos ambientes, não “correm” em todos. Diz-me um colega de profissão que no seu MacBook, nota uma considerável diferença de performance nestas aplicações entre as versões em Mac OS X e versões a correr em Linux (Ubuntu):

É que não há comparação. Eu agora instalei o Ubuntu no meu MacBook Pro e, comparando com o OSX, as apps gráficas livres correm que é um doce. Compensa o incómodo de ter um dual-boot.

Além de que estás sempre com as versões mais actuais — as ports para OSX demoram sempre um pouco a sair. E têm sempre bugs específicos, que é o que te deve estar a afligir (e que eu também testemunhei).

Diz quem sabe.

Eu vou fazer o teste possível, mas fico a pensar até que ponto este é um problema real da comunidade open source:

  • Será que a difusão da ideia de que as ferramentas livres e abertas funcionam em todos os ambientes e o voluntarismo com que alguns programadores “martelam” o código necessário para que tudo funcione em todo o lado não criam experiências negativas (ou menos positivas) em quem está a ponderar a mudança?
  • Não seria útil gerir melhor as expectativas dos utilizadores (especialmente dos utilizadores mais exigentes, que estejam num percurso de migração, vindo de ambientes proprietários / comerciais), clarificando os requisitos técnicos de cada aplicação e dando exemplos de setups testados para performance e estabilidade?
  • Será assim tão perigoso para a difusão do software livre a declaração de exigências mínimas para aplicações específicas e a constatação de que existem diferenças entre “funcionar” e ser útil e produtivo num ambiente real?
  • Que impacto teria no ecossistema fragmentado dos sabores Linux a declaração, por parte dos principais programadores de cada aplicação, das combinações de hardware e sistema operativo ideais e/ou realmente testados?
  • Como se poderia implementar um sistema de testes das diversas distribuições de cada aplicação em cada ambiente que fosse verdadeiramente fiável? A sensação que se tem é que, em muitos casos, as distribuições Mac OS X foram testadas com uma instalação e um par de cliques por parte de quem 1) não usaria a aplicação profissionalmente e/ou 2) não tem grande experiência de utilização de computadores Macintosh.

Vamos lá a alguns testes, então…

Panorâmicas

Não sei porquê, mas sempre tive um “fraquinho” por imagens “panorâmicas”. Parece que sou sempre mais atraído por imagens de realidades que não se conseguem captar com um único olhar. Realidades que exigem um movimento associado ao olhar, seja horizontal, na paisagem, seja vertical, em alguma arquitectura. Como esta vista panorâmica do Rempart de La Charité-sur-Loire:

La Charité-sur-Loire, Panorama do Rempart

Esta imagem corresponde à montagem destas 6 fotografias:

DSC02202DSC02203DSC02204
DSC02205
DSC02206DSC02207

E a ferramenta usada para fazer a operação de “stitching” é open-source, gratuita e multi-plataforma. Chama-se Hugin e, apesar de não ser elementar na utilização, não é preciso ser-se um especialista para criar montagens decentes, com auto-detecção de pontos-chave, várias formas de correcção da perspectiva e projecção e boas capacidades de mistura (blending). A montagem que vêem, aqui, é uma projecção “trans-mercator”, usando auto-detecção dos pontos chave, com o plugin Autopano-SIFT-C (instalação opcional descarregado com o instalador de base em Mac OS, pelo menos) e “blending” normal.
Para utilizadores mais exigentes, o Hugin lê informação EXIF sobre as lentes e o posicionamento e permite introdução manual de dados relativos a cada imagem (posição, rotação, lente, etc.), afinação manual de pontos-chave, criação de imagens HDR, assim como exportação em diversos formatos de imagem e até pode ser usado para apoiar exercícios de levantamento e modelação em arquitectura (ver aqui).

Confesso que no caso desta imagem, depois de criada a montagem panorâmica, passei pelo GIMP para ligeiros ajustes de cor, porque os originais estavam um bocado desmaiados. Clicando nas imagens (panorâmica e fotos originais), podem ver em maiores dimensões, no Flickr. Que tal vos parece a performance do Hugin? Que conselhos ou sugestões me dariam para melhorar este tipo de imagens? Precisam de alguma ajuda para se iniciarem neste processo de criar panorâmicas? A caixa de comentários está aberta para isso mesmo. ;)

[divulgação] Oficina “Design para uma Redacção Livre”, no JUP

O Hacklaviva organiza no JUP uma oficina dedicada às ferramentas informáticas (FLOSS) necessárias para construir uma “redacção livre”, projecto em curso no JUP. É no próximo sábado, dia 23 de Janeiro, numa tarde cheia de actividades à volta do info-activismo (e que coincide com inaugurações nas galerias da Rua Miguel Bombarda), cujo programa completo pode ser consultado aqui.

Mas, do programa, destaco, por me interessar particularmente, esta Oficina de Design para uma Redacção Livre.

23 jan 2010 | 14h30 – 17h30
Oficina de Design para uma Redacção Livre

Uma redacção a funcionar apenas com software livre? É o objectivo de uma colaboração entre o JUP e o Hacklaviva. Nesta oficina, vamos falar sobre o que é o software livre e as suas implicações na prática criativa, associativa e editorial. Depois veremos como hoje é possível tratar fotografia, criar gráficos e tipografia, paginar, editar áudio e montar vídeo com ferramentas livres. Traz o teu portátil e vem passar uma tarde connosco a descobrir novas formas de fazer o teu trabalho.

A informação chegou-me por via do Ricardo Lafuente, que é uma das pessoas que vai orientar esta oficina. As ferramentas-base da oficina serão:

  • Imagem: GIMP, Scribus e Inkscape (3 que fazem parte do meu workflow actual)
  • Áudio: Audacity (ferramenta muito útil)
  • Vídeo: Kaltura, OpenShot e (talvez) PiTiVi (esta é a área que é toda nova para mim e tenho que verificar se se conseguem instalar algumas destas ferramentas num Mac)

Segundo o Ricardo, “a ideia é mais um overview do que tutoriais; podemos tocar em partes específicas de acordo com as vontades colectivas, mas seria mais uma cena de esclarecimento, já que boa parte do pessoal que vai aparecer não tem noção do que existe no mundo do FLOSS…