Linked by Thom Holwerda on Wed 29th Aug 2007 21:55 UTC, submitted by deanna
Multimedia, AV 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.
Order by: Score:
Code Cleanup
by luciocorrea on Wed 29th Aug 2007 22:45 UTC
luciocorrea
Member since:
2005-07-06

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.

Reply Score: 7

RE: Code Cleanup
by spikeb on Thu 30th Aug 2007 04:19 UTC in reply to "Code Cleanup"
spikeb Member since:
2006-01-18

heh that is why libswf is still around, actually

Reply Score: 2

Cool
by zizban on Wed 29th Aug 2007 22:58 UTC
zizban
Member since:
2005-07-06

Gnash is pretty nowadays; I've used it on OS/2 Warp 4 and its does just about everything, including YouTube.

Reply Score: 4

gnash vs swfdec
by gogglesguy on Wed 29th Aug 2007 23:29 UTC
gogglesguy
Member since:
2007-08-10

So how does it compare to swfdec http://swfdec.freedesktop.org/wiki
which also seems to be a flash player...?

Reply Score: 3

RE: gnash vs swfdec
by pinky on Wed 29th Aug 2007 23:38 UTC in reply to "gnash vs swfdec"
pinky Member since:
2005-07-15

> 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. ;)

Reply Score: 1

RE[2]: gnash vs swfdec
by tyrione on Thu 30th Aug 2007 03:42 UTC in reply to "RE: gnash vs swfdec"
tyrione Member since:
2005-11-21

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.

Reply Score: 2

RE[3]: gnash vs swfdec
by pinky on Thu 30th Aug 2007 09:39 UTC in reply to "RE[2]: gnash vs swfdec"
pinky Member since:
2005-07-15

>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.

Reply Score: 2

RE: gnash vs swfdec
by zizban on Wed 29th Aug 2007 23:39 UTC in reply to "gnash vs swfdec"
zizban Member since:
2005-07-06

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.

Reply Score: 3

RE: gnash vs swfdec
by Luis on Thu 30th Aug 2007 11:08 UTC in reply to "gnash vs swfdec"
Luis Member since:
2006-04-28

>>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.

Reply Score: 3

RE[2]: gnash vs swfdec
by JrezIN on Thu 30th Aug 2007 16:13 UTC in reply to "RE: gnash vs swfdec"
JrezIN Member since:
2005-06-29

>>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.

Reply Score: 2

Porting
by sc3252 on Wed 29th Aug 2007 23:29 UTC
sc3252
Member since:
2005-09-06

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?

Reply Score: 6

RE: Porting
by dylansmrjones on Wed 29th Aug 2007 23:55 UTC in reply to "Porting"
dylansmrjones Member since:
2005-10-02

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.

Reply Score: 4

RE[2]: Porting
by Cymro on Thu 30th Aug 2007 11:31 UTC in reply to "RE: Porting"
Cymro Member since:
2005-07-07

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.

Reply Score: 3

RE[3]: Porting
by Wes Felter on Thu 30th Aug 2007 21:12 UTC in reply to "RE[2]: Porting"
Wes Felter Member since:
2005-11-15

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.

Reply Score: 3

RE: Porting
by s-peter on Thu 30th Aug 2007 01:20 UTC in reply to "Porting"
s-peter Member since:
2006-01-29

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.)

Reply Score: 4

RE: Porting
by anda_skoa on Thu 30th Aug 2007 12:05 UTC in reply to "Porting"
anda_skoa Member since:
2005-07-07

...but the proprietary companies such as adobe have trouble porting to just 64bit windows?


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)

Reply Score: 2

RE: Porting
by Morin on Thu 30th Aug 2007 16:15 UTC in reply to "Porting"
Morin Member since:
2005-12-31

Because OSS and portability are a good match. With every platform that a program is ported to, the project gains more developers.

Reply Score: 3

RE: Porting
by abraxas on Thu 30th Aug 2007 19:24 UTC in reply to "Porting"
abraxas Member since:
2005-07-07

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.

Reply Score: 3

RE: Porting
by Ford Prefect on Thu 30th Aug 2007 21:27 UTC in reply to "Porting"
Ford Prefect Member since:
2006-01-16

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.

Reply Score: 3

One more step away from Adobe...
by MarcoCampos on Wed 29th Aug 2007 23:39 UTC
MarcoCampos
Member since:
2007-07-19

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

Reply Score: 1

johnboyholmes Member since:
2005-11-16

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.

Reply Score: 1

MarcoCampos Member since:
2007-07-19

Yes, I know all about nspluginwrapper, but the I hate running non-native stuff...

Reply Score: 1

Jondice Member since:
2006-09-20

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.

Reply Score: 2

elanthis Member since:
2007-02-17

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).

Reply Score: 1

Depencencies..
by BSDfan on Wed 29th Aug 2007 23:44 UTC
BSDfan
Member since:
2007-03-14

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..

Reply Score: 1

RE: Depencencies..
by saxiyn on Thu 30th Aug 2007 03:06 UTC in reply to "Depencencies.."
saxiyn Member since:
2005-07-08

"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

Reply Score: 3

RE[2]: Depencencies..
by deanna on Thu 30th Aug 2007 03:19 UTC in reply to "RE: Depencencies.."
deanna Member since:
2006-10-01

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.

Reply Score: 3

RE[2]: Depencencies..
by Vanders on Thu 30th Aug 2007 08:35 UTC in reply to "RE: Depencencies.."
Vanders Member since:
2005-07-06

You don't compile Boost.


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!)

Reply Score: 5

RE[3]: Depencencies..
by WereCatf on Thu 30th Aug 2007 08:41 UTC in reply to "RE[2]: Depencencies.."
WereCatf Member since:
2006-02-15

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.

Reply Score: 1

RE[4]: Depencencies..
by Vanders on Thu 30th Aug 2007 10:45 UTC in reply to "RE[3]: Depencencies.."
Vanders Member since:
2005-07-06

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. ;)

Reply Score: 2

RE[3]: Depencencies..
by deanna on Thu 30th Aug 2007 18:29 UTC in reply to "RE[2]: Depencencies.."
deanna Member since:
2006-10-01

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.

Reply Score: 1

kudus...Gnash is getting better
by djangoxl on Thu 30th Aug 2007 06:14 UTC
djangoxl
Member since:
2006-03-10

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.

Reply Score: 1

RE: kudus...Gnash is getting better
by pinky on Thu 30th Aug 2007 09:49 UTC in reply to "kudus...Gnash is getting better"
pinky Member since:
2005-07-15

>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.

Reply Score: 3

Progressing quite nicely :)
by WereCatf on Thu 30th Aug 2007 08:38 UTC
WereCatf
Member since:
2006-02-15

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 ;)

Reply Score: 1