Suporte a Flash no Linux vive dias interessantes

Interesting times for Linux Flash support

Autor original: Koen Vervloesem

Publicado originalmente no: lwn.net

Tradução: Roberto Bechtlufft

Embora muitos proponentes do software livre e da web aberta não gostem do Flash, essa plataforma multimídia se tornou tão difundida que é difícil imaginar a web sem ela. Só que o suporte ao Flash sempre foi um desafio para as distribuições Linux. Há anos a Adobe lança seu Flash Player para o Linux de forma proprietária, mas apenas para a arquitetura de processadores x86. Enquanto isso, projetos de código aberto que tentam recriar as funcionalidades do Flash ficam para trás, lutando com a falta de mão de obra. Felizmente, temos notícias interessantes do mundo do Flash de código aberto: o projeto Lightspark, que foi escrito do zero com base na documentação do SWF que a Adobe publicou em junho de 2009 como parte do Open Screen Project.

O Flash Player oficial

Por anos, a Adobe tratou o Linux como cidadão de segunda classe. Em 2007, os usuários do Linux tiveram que esperar por seis meses após o lançamento da versão do Windows para que o Adobe Flash 9 chegasse ao Linux. No fim de 2008 isso mudou: com o lançamento do Flash Player 10, a Adobe lançou versões para Windows, MacOS X e Linux no mesmo dia. Isso não quer dizer que não haja problemas com o Flash Player proprietário. O suporte a 64 bits ainda é uma área sensível: embora seja possível usar o Adobe Flash Player em um sistema Linux x86_64 usando uma camada de emulação de 32 bits como o nspluginwrapper, o suporte nativo a 64 bits só está disponível em uma versão alfa lançada em novembro de 2008.

Olhando para a situação hoje, é irônico que o Linux tenha sido a primeira plataforma a contar com uma prévia de 64 bits do Adobe Flash Player. Em seu FAQ da versão preliminar, a Adobe diz:

Escolhemos o Linux como a primeira plataforma devido a inúmeras solicitações recebidas em nosso sistema público de gerenciamento e relato de bugs, e ao fato de que as distribuições Linux não incluem um navegador de 32 bits ou uma camada de emulação de 32 bits abrangente por padrão. Até o lançamento desta versão preliminar, o uso do Flash Player de 32 bits no Linux exigia o uso de um wrapper, impedindo a compatibilidade com navegadores de 64 bits. Com esta versão preliminar, o Flash Player 10 agora é um membro totalmente nativo das distribuições Linux de 64 bits.

Abordagens de código aberto para o Flash

Mas o suporte a x86 e o suporte preliminar a 64 bits obviamente não são suficientes no mundo do código aberto. Claro, a Adobe está trabalhando com alguns fabricantes de celulares para oferecer uma versão para a arquitetura ARM (por exemplo, no MeeGo ou no Android), mas a turma que roda um sistema Linux no desktop ou que não tem processadores Intel ficou trancada do lado de fora. Até o ano passado, era exatamente nessa situação em que eu me encontrava, rodando o Debian em um PowerMac G5. Quem não tem processador Intel e que rodar o Flash Player oficial tem que apelas para soluções horrorosas, como rodar o Flash em um emulador x86.

Felizmente, há programas que recriam a funcionalidade do Flash, dentre os quais o mais conhecido é o Gnash (“GNU Flash”), que também roda em processadores PowerPC, ARM e MIPS. E ele não se limita ao Linux: o Gnash tem suporte aos sistemas FreeBSD, NetBSD e OpenBSD, e agrada a muita gente que não quer rodar software proprietário em seu sistema operacional aberto, mas quer poder ver conteúdo em Flash. Em março nós demos uma olhada em como andava o Gnash, quando o líder do projeto, Rob Savoye, falou sobre ele na SCALE 8X.

Embora o Gnash esteja progredindo bem, a natureza do projeto faz com que ele sempre tenha que correr atrás da Adobe. Sem falar que o Gnash tem um problema de falta de mão de obra. A fundação Open Media Now! foi criada em 2008 para financiar o desenvolvimento do Gnash, mas graças à crise econômica os quatro desenvolvedores que trabalham em tempo integral ficaram sem dinheiro, como disse o desenvolvedor Bastiaan Jacques no ano passado. Recentemente, outro problema surgiu: uma desavença crescente entre os principais contribuidores Benjamin Wolsey e Sandro Santilli de um lado e Rob Savoye do outro.

Estilos de desenvolvimento diferentes

Tudo começou com uma mensagem de Benjamin Wolsey para a lista de discussão Gnash-dev no dia 21 de maio:

Alguns commits recentes no Gnash quebraram a suíte de testes, tornando o Gnash instável, além de apresentarem sérios problemas em termos de qualidade do código.

Infelizmente, isso significa que vou perder um tempo considerável revertendo as alterações infratoras, reimplementando coisas e consertando a suíte de testes para impedir que os danos se espalhem.

No fim da mensagem, Benjamin anunciou que daria início à sua própria ramificação estável do Gnash se outro commit desse tipo aparecesse, ameaçando implicitamente criar um fork. As acusações de Benjamin pareceram voltadas principalmente para Rob, que respondeu que a política habitual dos projetos de software livre é a de que check-ins frequentes são bons. Só que Sandro Santilli acrescentou que esse política só funcionaria se os check-ins fossem pequenos e não quebrassem a suíte de testes. Nesse ponto a discussão ficou feia e enveredou para a troca de acusações, mas Rob logo identificou o ponto central de discórdia:

Temos estilos muitos diferentes de escrita de código. Eu prefiro trabalhar de forma muito pública, fazendo check-in de código com frequência e consertando tudo nos check-ins seguintes. É assim que a maioria dos projetos de software livre com os quais me envolvi ao longo de 20 anos operam.

Rob também se defendeu da acusação de não considerar os testes algo importante: “Lembrem-se, eu sou o autor da maior parte da suíte de testes, então é justo dizer que eu dou importância aos testes.“ Mas ele também quer se concentrar em novos recursos, e acha que isso não é viável quando a “ramificação estável” precisa permanecer estável o tempo todo:

Em vez disso, o que tenho é intermináveis reescritas de código que já existe, com foco na “qualidade do código”. Isso não faz com que o Gnash avance, e por isso nossos dinheiro evaporou.

John Gilmore tentou fazer as pazes entre os dois lados em nome da causa que compartilham (“precisamos uns dos outros, pessoal“), e Sandro sugeriu a criação de uma ramificação experimental para código que quebre o Gnash.

Só que como Benjamin reverteu um dos commits de Rob e ameaçou fazê-lo novamente no futuro, Rob excluiu os direitos de commit de Benjamin no repositório Savannah do Gnash, dizendo que não vai “permitir que um desenvolvedor sedento pelo poder continue revertendo minhas alterações“. Enquanto isso, Sandro trabalhava em algumas melhorias e perguntou onde ele deveria dar commit no código: na ramificação do Gnash na qual Benjamin não poderia revisá-lo e onde talvez Rob não aceitasse as alterações, ou em um fork, que causaria divergência no projeto? Sandro obviamente ainda se importa com o projeto Gnash, e teme (com razão) que um fork não seja bom para a causa que todos defendem.

Depois de algumas noites de sono, Benjamin, Sandro e Rob parecem ter se dado conta de que possuem estilos diferentes no desenvolvimento, no gerenciamento de projetos e na comunicação, que todos eles erraram e que foram muito agressivos em suas respostas em alguns momentos. Enquanto eu escrevia este texto, eles estavam mantendo contato no canal de irc #gnash no Freenode, tentando chegar a um consenso e rascunhando algumas novas regras para commits (incluindo “commits só devem ser revertidos em último caso” e “não deve ser feito commit de código que cause falhas em testes existentes“), então essa crise toda pode acabar resultando em um processo de desenvolvimento melhor para o projeto.

O fim do Swfdec

Outro decodificador de Flash, o Swfdec, teve seu desenvolvimento interrompido silenciosamente há algum tempo. A última versão estável, a 0.8.4, é de dezembro de 2008, e os últimos commits são de dezembro de 2009. O Swfdec tem um único cabeça, Benjamin Otte, mas parece que ele perdeu o interesse no projeto, embora volta e meia responda a perguntas na lista de discussão do Swfdec. Em resposta a uma pergunta do desenvolvedor do Puppy Linux, Barry Kauler, em janeiro deste ano, Benjamin anunciou a morte do projeto em uma frase:

Sendo assim, o desenvolvimento parou, e é pouco provável que tenhamos novos recursos num futuro próximo.

O fato de Benjamin ter arranjado um novo emprego na equipe de desktops da Red Hat em janeiro certamente não é uma coincidência: isso deve nos lembrar de que um projeto com apenas um desenvolvedor principal sempre tem um futuro frágil, porque grandes mudanças na vida desse desenvolvedor podem resultar em menos tempo livre para ele trabalhar no projeto.

Um novo Flash Player de código aberto

O desenvolvimento do Gnash e do Swfdec era realizado por meio de engenharia reversa, já que a Adobe só oferecia a especificação do SWF com uma licença que proibia o uso da mesma para criar programas que reproduzissem arquivos Flash. Em junho de 2009, a Adobe lançou o Open Screen Project que disponibilizou a especificação do SWF sem essas restrições. Isso possibilitou a Alessandro Pignotti trabalhar em um novo Flash Player de código aberto, baseado completamente na documentação oficial. Parte desse projeto se baseia na tese de bacharelado dele na universidade de Pisa, Uma eficiente implementação de compilador ActionScript 3.0 Just-in-Time [PDF].

O resultado é o Lightspark, que inclui renderização via OpenGL, uma implementação praticamente completa do ActionScript 3.0 da Adobe usando o compilador LLVM e um plugin para navegadores da família Mozilla. Como o Lightspark foi projetado e desenvolvido do zero com base na documentação da Adobe, ele promete uma base de código limpa e otimizada para hardware moderno.

Ao usar o OpenGL em vez do XVideo, o Lightspark permite renderização acelerada por hardware usando shaders OpenGL. Além disso, isso abre caminho para o suporte a desfocagem (blur) e outros efeitos implementados por shaders eficientes. Outra possibilidade é o uso de texturas OpenGL para exibir quadros de vídeo, o que é menos eficiente do que no XVideo, porém mais flexível. Isso torna possível, por exemplo, implementar os efeitos de sobreposição (overlay) e transformação que o Flash suporta.

Para o ActionScript 3.0 (introduzido no Flash 9), o Lightspark tem tanto um interpretador quanto um compilador JIT, que usa o LLVM para compilar o ActionScript como código x86 nativo. Porém, como as versões anteriores do ActionScript rodam em uma máquina virtual completamente diferente, Alessando decidiu não dar suporte a elas. Isso quer dizer que no momento não é possível comparar o desempenho do Lightspark ao do Gnash: enquanto o Lightspark suporta apenas o ActionScript 3.0, o Gnash só suporta versões anteriores dele.

Para os interessados em experimentar o Lightspark em seus navegadores, Alessandro lançou um plugin para a família Mozilla. Diante de um arquivo Flash sem suporte, o plugin deve falhar com discrição. Por enquanto, há apenas um PPA para usuários do Ubuntu, mas pacotes estão sendo criados para o Arch Linux e o Debian. Nessa versão alfa de desenvolvimento, o Lightspark é mais uma demonstração da tecnologia. Alessandro é o único desenvolvedor, mas alguns contribuidores externos começaram a aparecer.

Após a primeira leva de testes, Alessandro publicou algumas informações sobre os planos para as próximas versões. Uma versão estável sem novos recursos estava prevista para a primeira semana de junho (mas ainda não saiu), e a versão 0.5.0 vai estar focada no suporte ao YouTube. Ele também esclarece que a implementação atual só funciona em x86/x86_64 por causa do código assembly usado em algumas partes, mas ele aceita de bom grado ports para outras arquiteturas.

O código é compilado com tecnologias comuns, como pthreads e STL, e deve ser bastante portável, só que partes críticas do código foram escritas em assembly para garantir a atomicidade e melhorar o desempenho. Tenho muito pouca experiência com outras arquiteturas além das x86 e x86-64, então prefiro não portar código tão crítico. Mas aceitarei de bom grado quaisquer contribuições para outras plataformas, como PPC e ARM. A boa notícia é que um contribuidor conseguiu compilar o Lightspark no FreeBSD/x86 com alterações mínimas no sistema de compilação, e uma versão para o Windows também está nos planos.

Os desenvolvedores do Gnash têm conversado com Alessandro sobre a possibilidade de unirem forças, mas ele preferiu trabalhar no Lightspark, porque era muito difícil incluir um compilador JIT otimizado na arquitetura existente do Gnash. Ainda assim, o compartilhamento de código e até mesmo uma colaboração maior entre os dois projetos certamente parece possível. Alessandro já disse que o código do Lightspark poderia ser integrado ao Gnash quando estivesse bom o suficiente, e Rob gostaria de incluir suporte ao uso do Lightspark no Gnash para lidar com a AVM2, a máquina virtual de ActionScript que a Adobe apresentou com o Flash 9. Se a ideia for implementada, o Gnash poderia essencialmente passar toda a funcionalidade do ActionScript 3 para o Lightspark.

Conclusão

Embora a maioria dos proponentes do software livre e de código aberto concordem que o Flash seja ruim e que deva ser substituído por tecnologias web abertas, como o HTML 5, a transição para uma web aberta vai acontecer lentamente, como sempre acontece no mundo da computação. Além do mais, estamos presos a um monte de conteúdo criado para o Flash, e esse conteúdo deve permanecer acessível. Sendo assim, projetos de código aberto para o Flash como o Gnash e o Lightspark vão continuar sendo importantes para os usuários do Linux por muitos anos. Espera-se que os desenvolvedores do Gnash cheguem a um consenso quanto ao seu modelo de desenvolvimento, e que o Lightspark não tenha o mesmo fim do Swfdec. Para uma coisa importante como o Flash é para muitos usuários, mais desenvolvedores trabalhando nesses dois projetos certamente seriam de grande ajuda.

Créditos a Koen Vervloesem – lwn.net

Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>