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…
