Although many proponents of free software and an open web don't like
Flash, the multimedia platform has become so ubiquitous that it is
difficult to imagine the web without it. However, Flash support has always
been a challenge for Linux distributions. Adobe has had a proprietary Linux release of its Flash player software for years now, but only for the x86 processor architecture. Meanwhile, open source projects trying to recreate Flash functionality are lagging behind and struggling with lack of manpower. Luckily, there are also some interesting new technical developments in the open source Flash world. One that sparked our interest recently is Lightspark, which was written from scratch based on the SWF documentation Adobe published in June 2009 as part of the Open Screen Project.
The official Flash player
For years, Adobe treated Linux as a second-class citizen. As recently as 2007, Linux users had to wait six months after the Windows release for their version of Adobe Flash 9. At the end of 2008, that changed: with the release of Flash Player 10, Adobe released versions for Windows, MacOS X and Linux on the same day. However, that's not to say there are no problems with the proprietary Flash player. 64-bit support is still a sore point: although it's possible to use Adobe Flash player on a x86_64 Linux system using a 32-bit emulation layer such as nspluginwrapper, native 64-bit support is only available as an alpha version that was first released in November 2008.
In hindsight, it's ironic that, as late as it may come to the party,
Linux is the first platform that gets a peek at a 64-bit Adobe Flash
player. In its FAQ
for the 64-bit prerelease, Adobe writes:
We chose Linux as our initial
platform in response to numerous requests in our public Flash Player bug
and issue management system and the fact that Linux distributions do not
ship with a 32-bit browser or a comprehensive 32-bit emulation layer by
default. Until this prerelease, use of 32-bit Flash Player on Linux has
required the use of a plugin wrapper, which prevents full compatibility
with 64-bit browsers. With this prelease [sic], Flash Player 10 is now a
full native participant on 64-bit Linux distributions.
Open source approaches to Flash
But x86 and preliminary x86_64 support for Flash obviously isn't enough
in the open source world. Granted, Adobe is or has been working with some
mobile phone manufacturers to offer a version for ARM (for example on MeeGo
or Android), but people running a Linux desktop system on a non-Intel
processor are left in the cold. Until last year, your author was in exactly
this position, running Debian on a PowerMac G5. If non-Intel users want to
run the official Flash player they have to use ugly solutions such as running Flash in an x86
Luckily there are some open source programs recreating Flash
functionality, of which the most well-known is Gnash ("GNU Flash"), which
also runs on PowerPC, ARM and MIPS processors. It's not even limited to
Linux: Gnash also supports FreeBSD, NetBSD, and OpenBSD, so it pleases a
lot of people that don't want to run proprietary software on their open
source operating system but have to be able to see Flash content. In March
we looked at the current state of
affairs of Gnash when project lead Rob Savoye talked about the project at SCALE 8x.
Although Gnash has been progressing well, the nature of the project
means that it will always be chasing Adobe. Moreover, Gnash is facing some
manpower challenges. The Open Media
Now! foundation was started in 2008 to fund Gnash development, but,
because of the economic crisis, the four full-time developers were cut back
to zero, Gnash developer Bastiaan Jacques said last
year. Recently, another issue appeared: a growing disagreement between
the two top
contributors Benjamin Wolsey and Sandro Santilli on the one hand, and
Rob Savoye on the other hand.
Different development styles
It all started with a message by Benjamin Wolsey to the Gnash-dev mailing list on Friday 21 May:
Recently there have been several commits to Gnash that break the testsuite, make Gnash unstable, and have serious issues with code quality.
Unfortunately this means that I have to spend considerable time reverting
faulty changes, reimplementing things properly, and fixing the testsuite
just to stop the damage spreading.
At the end of his message, Benjamin announced that he would start his
own stable branch of Gnash if another commit of this sort appeared,
implicitly threatening a fork. Benjamin's accusations seemed to be
primarily aimed at Rob, who answered
that the usual policy of free software projects is that frequent checkins
are good. However, Sandro
Santilli added that this policy would only work if the checkins are
small and do not break the test suite. Then the discussion became somewhat nasty with general accusations thrown back and forth, but Rob soon pinpointed the central point of disagreement:
We have very different coding styles. I prefer to work very publically, checking code in frequently, and then fixing it over the next few checkins. This is the way most all free software projects I've been involved in for 20 years operate.
Rob also defended himself against the accusation that he doesn't consider testing important: "Remember, I wrote the majority of our testsuite, so I think it's fair to say I consider testing important." But he also wants to focus on new features and he has the impression that this doesn't work when the "stable branch" has to remain stable all the time:
Instead I get endless rewrites of existing code, all aimed towards "code quality". This does not advance Gnash at all, which is why our funding evaporated.
John Gilmore tried to get the two parties back together behind their common cause ("We need each other, guys"), and Sandro suggested to use an experimental branch for code that breaks things.
However, because Benjamin reverted one of Rob's commits and threatened
to do it again in the future, Rob removed
Benjamin's commit rights to the Savannah repository for Gnash, because
he doesn't want to "allow a power-hungry developer to continue to
reverting my changes." In the meantime, Sandro worked on some
improvements and asked where
he should commit the code: to the Gnash trunk where Benjamin couldn't
review it and Rob maybe wouldn't accept the changes, or to a fork, which
would make the project diverge? Sandro obviously still cares for the Gnash
project and rightly fears that a fork will not be good for the common
After a few nights of sleep, Benjamin, Sandro, and Rob seem to acknowledge
that they have different development, project management, and communication
styles, that they all made mistakes, and were too rude in their responses
at some times. At the time of this writing, they were still on speaking
terms on the #gnash irc channel on Freenode and were actively trying to
reach a consensus and drafting some new commit rules (including
"Commits shall not be reverted except as a last resort." and
"No code shall be committed that causes failures in existing
tests."), so this whole crisis may well result in a better development process for the project.
The death of Swfdec
Another Flash decoder, Swfdec, has silently stopped
development a while ago. The last stable release, 0.8.4, is from December
2008, and the last
commits are from December 2009. Swfdec has been primarily run by one
person, Benjamin Otte, but he seems to have lost interest, although he is
still occasionally answering questions on the Swfdec mailing
list. In response to a question by Puppy Linux developer Barry Kauler in January of this year, Benjamin announced the death of his project in one sentence:
That said, active Swfdec development has pretty much stopped, so you'll likely not see any new features in the near future anyway.
The fact that Benjamin started a new job in
Red Hat's desktop team in January of this year is surely no
coincidence: it should remind us that a project with just one core
developer always has a fragile future because big changes in the developer's life can result in less time to work on the project.
A new open source Flash player
Development of Gnash and Swfdec was done using reverse engineering because Adobe only offered the SWF specification with a license that forbids the use of the specification to create programs that play Flash files. In June 2009, Adobe launched the Open Screen Project which made the SWF specification available without these restrictions. This made it possible for Alessandro Pignotti to work on a new open source Flash player, entirely based on this official SWF documentation. A part of this project is based on his bachelor's thesis at the university of Pisa, called An efficient ActionScript 3.0 Just-In-Time compiler implementation [PDF].
The result is Lightspark, which includes
OpenGL-based rendering, a mostly complete implementation of Adobe's
ActionScript 3.0 using the LLVM compiler, and a Mozilla-compatible browser plug-in. Because Lightspark has been designed and written from scratch based on Adobe's documentation, it promises a clean code base optimized for modern hardware.
By using OpenGL instead of XVideo, Lightspark allows for
hardware-accelerated rendering using OpenGL shaders. Moreover, this opens
the path for supporting blur and other effects that are implemented by efficient shaders. Another possibility is using OpenGL textures to display video frames, which is less efficient than XVideo but more flexible. For example, it makes it possible to implement the overlay and transformation effects that Flash supports.
For ActionScript 3.0 (introduced in Flash 9), Lightspark has both an interpreter and a JIT compiler that uses LLVM to compile ActionScript to native x86 code. However, because the previous ActionScript versions run on a completely different virtual machine, Alessandro has decided to not support them. This means that currently it's not really possible to compare the performance of Lightspark with that of Gnash: while Lightspark only supports ActionScript 3.0, Gnash only supports previous versions of the scripting language.
For people that want to try Lightspark in their browser, Alessandro has
released a Mozilla-compatible plug-in. When encountering an unsupported
Flash file, the plug-in should fail gracefully. For now, there's only a PPA
(Personal Package Archive) for Ubuntu
users, but packages are being created for Arch Linux and Debian. In
this alpha phase of development, the current release is more of a
technological demo. Alessandro is currently the only developer, although
some external contributions have started trickling in.
After the first wave of testing, Alessandro published some information
on the plan for the next releases. A stability release with no new features is planned for the first week of June, while release 0.5.0 will be focused on YouTube support. He also clarified that his current implementation only works on x86/x86_64 because of some assembly code, but he welcomes ports to other architectures:
The code is build using standard technologies, such as pthreads and STL and
should be quite portable, but some critical code paths has been written in
assembly to guarantee atomicity or improve performance. I've very little
experience with anything beside x86/x86-64, so I prefer not to port such
critical code. However I will gladly accept any contributions for other
platforms, such as PPC and ARM. The good news is that a contributor managed
to compile lightspark on FreeBSD/x86 with minimal changes to the build
system and a windows port is also planned.
The Gnash developers have been talking with Alessandro about joining their efforts, but he decided to work on Lightspark because it was very difficult to include an optimizing JIT compiler into the existing Gnash architecture. That said, code sharing or even a closer collaboration between the two projects certainly seems possible. Alessandro has already said that Lightspark's code could be integrated with Gnash in time when it's good enough, and Rob would like to add support for using Lightspark in Gnash to handle AVM2, the ActionScript virtual machine that Adobe introduced in Flash 9. If this idea is implemented, Gnash could essentially hand off all ActionScript 3 functionality to Lightspark.
Although most free and open source proponents agree that Flash is a bad
thing and that it should be replaced by open web technologies such as HTML
5, the transition to an open web will happen slowly as all evolutions in
the computer world do. Moreover, we are stuck with a lot of existing Flash
content that should remain accessible. Therefore, open source Flash
projects like Gnash and Lightspark will remain important for many Linux
users for years. There is hope that the Gnash developers will reach a
consensus on their development model and hopefully Lightspark will
not face the same fate as Swfdec.
For something as critical as Flash is to many users, more developers for
both projects could certainly help.
to post comments)