Submitted by The fourth alpha release of Gnash has just been made at version 0.8.1. Gnash is a GPL’d Flash movie player and browser plugin for Firefox, Mozilla, Konqueror, and Opera. Gnash supports many SWF v7 features and ActionScript2 classes. Gnash also runs on many GNU/Linux distributions, embedded GNU/Linux, FreeBSD, NetBSD, OpenBSD, non x86 processors, and 64 bit architectures. Ports to Darwin and Windows are in progress for a future release. The plugin works best with Firefox
1.0.4 or newer, and should work in any Mozilla based browser. There is also a standalone player for GNOME or KDE based desktops.
What Gnash really needs is a code cleanup! Yesterday i checked the cvs code, and it’s a complete mess… There’s no standard in classes, variables, files and methods names… There are small dirs with code copied from other libs, like libltdl and so on.
heh that is why libswf is still around, actually
Gnash is pretty nowadays; I’ve used it on OS/2 Warp 4 and its does just about everything, including YouTube.
So how does it compare to swfdec http://swfdec.freedesktop.org/wiki
which also seems to be a flash player…?
> So how does it compare to swfdec http://swfdec.freedesktop.org/wiki
> which also seems to be a flash player…?
Good question. I would like to know this too.
Sadly i can’t compile swfdec on my Debian Etch box (missing dependencies) so i can’t test it by myself.
Sadly i can’t compile swfdec on my Debian Etch box (missing dependencies) so i can’t test it by myself.
Then install the dependencies. Hell use your bashrc and setup variables paths so the dependencies vanish.
>Then install the dependencies. Hell use your bashrc and setup variables paths so the dependencies vanish.
But it needs libs which aren’t available in Etch and just to test something i will not mess up my system by installing testing libs or by installing them by myself.
sfwdec hasn’t quite mastered places like lulu.tv and has some sound issues with YouTube but its getting there.
Also swfdec is only for Linux and FreeBSD while gnash is for everything.
>>So how does it compare to swfdec…?
They’re both quite incomplete yet. I think swfdec is more realistic by calling its version 0.5.1 than gnash calling it 0.8.1, but anyway, they’re getting there gradually.
None will play smoothly flash sites, but some things do work. swfdec is in general a bit ahead and play more content correctly.
Both play youtube videos, though (it’s been a priority for both projects). While both use 100% CPU on my box (P4 2.6 Ghz) swfdec plays them smoothly, while with gnash they are rather choppy. With none you can adjust the volume in the player, but at least with swfdec you get to see it correctly (gnash has a visual bug).
So I’d say that swfdec is one step ahead of gnash right now, but both need still work to be considered a decent replacement for Adobe’s flash player. They progress steadily, though, so maybe in a year or even less they’ll be ready to replace Adobe’s player in 95% of the cases.
>>So how does it compare to swfdec…?
>They’re both quite incomplete yet. I think swfdec is more realistic by calling its version 0.5.1 than gnash calling it 0.8.1, but anyway, they’re getting there gradually.
Another basic difference is the license.
One is GPL while the other is LGPL.
Why does it seem like every oss project is able to port their code to other platforms, or even extensions such as 64bit, but the proprietary companies such as adobe have trouble porting to just 64bit windows?
To some extent because these systems are all posix-compatible to a fault
Another one is that FLOSS-persons are geeks. They are doing it for the fun of it.
And a third: FLOSS is often developed after the KISS-principle.
And a four: Don’t underestimate the amount of man-power available for FLOSS. Adobe doesn’t have that kind of man-power available.
I wouldn’t be surprised to see Adobe open-source the Flash Player before Gnash gets ActionScript 3.0/Flash 9 support.
In my mind, everything points towards that. The Flex SDK is open-source and the ECMAScript interpreter for ActionScript was donated to Mozilla. Their AJAX framework, Spry, is open-source (rather than just being viewable JavaScript with a restrictive license). I can’t imagine Adobe feel they’ve done too badly out of the PDF standard either.
Then there’s the competition. Microsoft are open to the Moonlight open-source project right now – they’re smart enough to know it promotes Silverlight more than it promotes Linux. Being “unofficial” support, they get goodwill from Mono developers and people who like open-standards, but crucially they keep control. Meanwhile Windows Update does its work.
Of course, there are risks, but open-sourcing the Flex SDK was extremely telling IMHO. It’s easier to build a Flex Builder replacement on top of Eclipse than it is to build a full Flash authoring app so they seem ready to face those concerns.
Flash Player 9 itself is effectively two players in one. The ActionScript 3 side is a nice new code-base that’s ideal for open-sourcing. If Adobe are smart they’ll act swiftly.
OTOH, Flash Player contains proprietary VP6, NellyMoser, and Mainconcept code that Adobe probably cannot release. If Adobe released only partial source it would undermine their commitment to compatibility.
It’s not so much that they have trouble but they don’t do it simply because it’s not profitable for them. For example, spending an additional 10-20% or more to deliver a Linux port is not worth for getting maybe 3-5% additional customers (numbers are just examples). It’s even worse for 64bit versions as practically any user can just run the 32bit version (no additional customers). However, both may change as/if the adaption rate for 64bit platforms and alternative OSes increase. (As the shift to 64bit architectures is evident, I’d expect most vendors to release 64bit versions from the next major versions of their software, but not spend any additional money to deliver 64bit versions of existing apps unless it significantly increases performance for that app.)
In the case of Flashplayer, I’d say the main difference is new code on the side of the OSS project vs. tons of old legacy code on the proprietory side.
It is one thing to keep new code portable (easy) and another thing to make old code run on new platforms (hard, requires porting, etc)
Because OSS and portability are a good match. With every platform that a program is ported to, the project gains more developers.
Why does it seem like every oss project is able to port their code to other platforms, or even extensions such as 64bit, but the proprietary companies such as adobe have trouble porting to just 64bit windows?
A lot of proprietary code is crufty and old due to backwards compatibility. Free software code is usually cleaner and refactored more often. In addition to cleaner code free software always has someone who wants an application bad enough on their platform to port it themselves.
The OSS projects write portable code in first place.
Many companys have the “get it running on our reference machine, we will fix the glitches on some other machines later” attitude.
Developers need more time for really portable code (although its much easier on POSIX platforms). In a company, they want you to get the job done, and do it fast. The job is the target machine/platform, and nobody will ask you about another OS or platform because it isn’t in their business plan anyway. So you use every single (non-portable) feature of the target platform that shortens your work.
But if I code for free/fun, I want to write nice/elegant code, not only fast code.
I have high hopes for this project. Flash Player is one of the main reasons why I don’t run a 64-bit Linux box.
Edited 2007-08-29 23:40
If you want flash on 64-bit Linux you could try nspluginwrapper and just use the 32-bit Adobe pluggin. It works great for me.
Yes, I know all about nspluginwrapper, but the I hate running non-native stuff…
It is still native, and for all intents and purposes there will likely be no performance difference whatsoever.
I kind of know what you mean though, keeping 32bit libraries around as well as the 64 bit libraries can get to be a mess if the distribution packagers and the user is not careful.
32-bit Flash works perfectly on a 64-bit Firefox with nspluginwrapper. There is no reason at all – none – not to be running 64-bit Linux. Any and every problem 64-bit Linux had with application compatibility has been solved.
Remember, if nothing else, that 64-bit Linux can run 32-bit apps just fine (for AMD64, anyways; not sure about other 64-bit archs).
I’m not a fan of the Boost dependency – While they claim it adds portability, Compiling Boost alone on some systems takes several hours.
A bucket full of fail..
“Compiling Boost alone on some systems takes several hours.”
You don’t compile Boost. What are you talking about?
Edited 2007-08-30 03:07
Starting with 0.8.0, the boost libraries are required. Previously it was just the headers, which of course didn’t need to be compiled. This really isn’t a big deal since most OSes provide binary packages. The OpenBSD package, for instance, is a 4MB download.
Somebody has too. For smaller projects (like Syllable) the ever-growing list of dependencies for a lot of projects creates extra work. Not only do we have to validate that things like Boost or Glib or whatever actually build and work, we have to keep our packages for this software up to date. Not to mention the increased build times imposed by dependencies.
Introducing a dependency is not free. It is especially galling when the dependency is largely unnecessary (Say, Glib. Bah!)
Glib unnecessary? :O How come? Considering how great many apps use it I don’t see it as unnecessary..And since it is a cross-platform library (even supports Windows) your app doesn’t need to be modified much if at all to work on other platforms.
Large parts of Glib are simply unnecessary, having been superseded by things like C99 or simply duplicate existing standards (GThread: use PThreads!). The bits that remain are often used incorrectly. The original idea behind Glib was that a project should copy in the parts they required, but these days Glib is treated like an extended libc where projects link against the DSO.
I just don’t like Glib. I never have. It may be partially irrational, but my hatred is based on some good reasons.
I feel your pain but consider that gnash is a desktop app and mainly used as a firefox browser plugin. Many of the dependencies should already be satisfied by your browser itself, and if not, they’ll be needed eventually for other things besides gnash. Boost, for instance, is also needed by OpenOffice.Org.
I’m using it on a amd64 freebsd box and have noticed great improvements over the past year. When I visited certain sites I used to see these thumbnails which said I had to have the acrobat plugin.
Nowadays gnash shows me the pictures and at certain sites (www.sky-europe.com for instance), I can even see the animations.
Youtube is still on bridge too far, but I’m sure they will be able to take that last hurdle.
Keep up the good work gnash developers.
A happy Freebsd amd64 user.
>Youtube is still on bridge too far, but I’m sure they will be able to take that last hurdle.
YouTube should work since Gnash 0.8.0.
They’re doing a fine job and when most Flash sites work properly with Gnash I might switch over to use it instead. I just don’t have much use for Flash though, it’s only used to show those millions of ads and those few times I visit YouTube