Lightspark 0.4.2 Open Source Flash Player Released

suraj.sun writes "The Lightspark project has released version 0.4.2 of its free, open source Flash player. According to Lightspark developer Alessandro Pignotti, the alternative Flash Player implementation is 'designed from the ground up to be efficient on current and (hopefully) future hardware.' The latest release of Lightspark features better compatibility with YouTube videos, sound synchronization support and the ability to use fontconfig for font selection. Other changes include plug-in support for Google's Chrome/Chromium web browser and support for Firefox's out of process plug-in (OOPP) mode, which was added in version 3.6.4 of the browser."

Comments

Project page

[nacturation]

At least link to the project page rather than a rehashed "news" story: http://sourceforge.net/apps/trac/lightspark

Re:Project page

[tenco]

You must be new here.

Re:Project page

[Anonymous Coward]

Yeah, you must be new here. Or you must be thinking with clarity, precision and pragmatism. Either way, get with the program will you.

Damn Republicans.

Re:Project page

[deniable]

They can't link to Sourceforge. It's got a bad reputation. You wouldn't want Slashdot associated with that, would you?

Re:Project page

[Robert Zenz]

Excuse me?

Re:Project page

[Tubal-Cain]

He's joking. Sourceforge, Slashdot, and Thinkgeek all have the same corporate overlord.

Re:Project page

[Robert Zenz]

Ahhh...I think my sense for irony is broken...again. :(

The best feature they could add...

[Picass0]

...would be blacklisting for sites that serve ads and popups. I'd settle for restricting flash to site domain only.

Re:The best feature they could add...

[Surt]

Since it's OS, maybe that's the best feature YOU could add.

Re:The best feature they could add...

[Abstrackt]

Since it's OS, maybe that's the best feature YOU could add.

That sounds good in theory but not everyone's a (capable) programmer. Perhaps the best feature they could add is bounties, meaning people can offer cash for someone with the necessary skillset to implement the feature they want.

Re:The best feature they could add...

[farlukar]

I'd settle for restricting flash to site domain only.

What a novel concept!

Re:The best feature they could add...

[Anonymous Coward]

Maybe, maybe not.

But that condescending reply in response to an informal feature request is terrible.
You give open source a bad name.

Re:The best feature they could add...

[Anonymous Coward]

Offer -cash-?

Cash?!

Re:The best feature they could add...

[Abstrackt]

Offer -cash-?

Cash?!

s/cash/money

(Note to self, no more colloquialisms on Slashdot.)

Re:The best feature they could add...

[Anonymous Coward]

That's something that's better handled at a higher level than the browser plugin. With what you suggest, the plugin needs to be loaded first in order to decide whether it should display the element or not. If you end up on a page with nothing but blocked ads, the plugin is loaded only to be find out that it has nothing to display, which ends up just being a waste of resources.

Re:The best feature they could add...

[Nerdfest]

That sort of reply is now mandatory for any open source related story. It is now formally referred to as "Anonymous Coward's Law".

Re:The best feature they could add...

[westlake]

Since it's OS, maybe that's the best feature YOU could add.

If - and only if - he is a programmer.

Something to remember before the mod-up to "Insightful."

     

Re:The best feature they could add...

[fuzzyfuzzyfungus]

On a feature level, for the entire browser+addons stack, I agree that that is an extremely useful feature. Sturgeon's law applies, hard, to flash and most of it deserves to be blocked.

Architecturally, though, isn't the flash renderer plugin a silly place for blacklisting/whitelisting/domain control features? The browser is responsible for issuing the HTTP requests, rendering what it can, calling plugins for what it can't, and so forth. Why should the browser download the flash blob, load the renderer, and then have the renderer check a blacklist and allow or refuse rendering of the object?

Wouldn't it make much more sense for that to be handled at the browser level, with the renderer invoked only if you want the flash rendered?

Re:The best feature they could add...

[Surt]

It wasn't intended to be condescending. It was intended to be encouraging.

Re:The best feature they could add...

[Surt]

I figured on slashdot odds favored the programmer.

Re:The best feature they could add...

[Anonymous Coward]

Since it's OS, maybe that's the best feature YOU could add.

If - and only if - he is a programmer.

Something to remember before the mod-up to "Insightful."

Is anybody else going to bitch about Surt's reply or is this enough yet? After the first one, you're all redundant and should be modded as such. I don't share your offense at the suggestion that someone pitch in and help a free project but even if I did, once statement of such is enough.

Re:The best feature they could add...

[dotancohen]

Already exists for Firefox:
https://addons.mozilla.org/en-US/firefox/addon/433/

Re:The best feature they could add...

[Phisbut]

I figured on slashdot odds favored the programmer.

And that's why you never make assumptions... because you make an ass out of you and... mumptions...

Re:The best feature they could add...

[Actually, I do RTFA]

The browser is responsible for issuing the HTTP requests, rendering what it can, calling plugins for what it can't, and so forth. Why should the browser download the flash blob, load the renderer, and then have the renderer check a blacklist and allow or refuse rendering of the object?

Because that blob calls 800 other flash files from around the web. The biggest problem is one flash file including cross-domain other-flash. And Macromedia used to understand that and forbid it. Then, the content producers got it from Adobe.

Re:The best feature they could add...

[evJeremy]

It also already exists for Konqueror, reKonq, and Arora. No plugin/addon needed.

Re:The best feature they could add...

[Sethumme]

Internet surfers are a crabby bunch.

The most promising aspect of open source software, even beyond being free of locked-down monopolies, is the opportunity for anyone with an interest in software to get their hands dirty and experience what it feels like to help develop a project they actually use and care about. Even if the coding experience isn't there, there may be other ways to get involved. Participating in OSS has the potential to be very gratifying, and can entice more people to consider computer programming by leaping over the barrier of "who cares about a stupid program that prints 'hello world'?"

Re:The best feature they could add...

[fuzzyfuzzyfungus]

I wish that I were more surprised by that; but then I think back to what Adobe is doing to PDFs, which are slowly growing into a script-driven monstrosity with virtually everything embedded in... Why yes, Adobe, I've always wanted to embed fucking videos in a document format designed for accurate printing...

Re:The best feature they could add...

[Actually, I do RTFA]

Why yes, Adobe, I've always wanted to embed fucking videos in a document format designed for accurate printing...

In Adobe's defense, I want to embed fucking videos in everything.

Re:The best feature they could add...

[Anonymous Coward]

Offer -money-?

Money?!

Re:The best feature they could add...

[deniable]

The fucking videos fit perfectly with all of the stroke settings. Where's the problem?

Re:The best feature they could add...

[dirtyhippie]

pedant warning: you are missing a slash. :)

embrace and extend

[goombah99]

Now that open source has embraces the flash standard, no doubt Adobe will add proprietary additions so sow incompatibility.

The protentially nice thing about this howerve is that if
1) it's efficient
2) not buggy
3) supports DRM

then it answers apple's complaints about flash and Youtube's complaints about H264. The problme for apple was that it would be insane to make your player beholden to a closed 3rd party app, espeically one from a company that hsitorically dragged it's heels in incorproating your platforms new features. Apple thrives on offering distinguishing features and adobe smothers them if they don't incorporate them.

But if the source is open apple is free to make sure it keeps up. So long as it is not as buggy as flash was.

Likewise youtube complained they could not monetize Video under H264 as well as under flash. the ability to have linking and overlays and such was required for the cash register.

Again this is now possible if this supports DRM.

One nice thing is that since apple already has a sandboxing system in both OSX and iOS, having it open source may allow them to get a tighter sandbox. No need to count on Adobe's sandbox working.

Re:embrace and extend

[Anonymous Coward]

Now that open source has embraces the flash standard, no doubt Adobe will add proprietary additions so sow incompatibility.

The protentially nice thing about this howerve is that if
1) it's efficient
2) not buggy
3) supports DRM

4)has the potential to run on 64 bit and ARM platforms.

Re:embrace and extend

[natehoy]

It won't, however, answer Apple's biggest reason for not wanting to support Flash.

Flash is, simply, a proprietary format that they don't have any patent control over. They want h264, which is a proprietary format controlled by a consortium they are a major member of.

Apple wants Flash dead. They don't want it open, they don't want it closed, they don't want it with cherries and whipped cream on top. They want it dead. It's something they cannot control, and therefore it must die.

Re:embrace and extend

[Anonymous Coward]

Now that open source has embraces the flash standard, no doubt Adobe will add proprietary additions so sow incompatibility.

The protentially nice thing about this howerve is that if
1) it's efficient
2) not buggy
3) supports DRM

4)has the potential to run on 64 bit and ARM platforms.

5) there is a windows version planned (i loathe having to have any adobe product installed).

Re:embrace and extend

[sortius_nod]

If you had used flash on a mac you'd probably change your tune. Adobe have almost abandoned apple when most of their apps started on mac os. I can understand apple saying "fuck off" to adobe after the bullshit they've pulled over recent years.

Re:embrace and extend

[Yvanhoe]

Open source software is technically incompatible with DRMs.

Re:embrace and extend

[Anonymous Coward]

Indeed, try running an Adobe product using a networked home directory for example...

Re:embrace and extend

[unix1]

They want h264, which is a proprietary format controlled by a consortium they are a major member of.

I'm not sure what you mean by "major" but Apple only has 1 patent in the h264 patent pool that looks like nothing but a placeholder patent to satisfy the membership requirement.

Re:embrace and extend

[samkass]

Flash is, simply, a proprietary format that they don't have any patent control over. They want h264, which is a proprietary format controlled by a consortium they are a major member of.

h.264 and Flash aren't incompatible. And Apple's a minor member of that consortium with almost no patents in the game. Apple just wants the best products and doesn't want to have to depend on others to get them, and Flash is the opposite of both of those things.

Considering how much Apple has contributed to open source over the past few years, they obviously value it highly. Heck, their biggest competitor in their fastest-growing market is basing their entire web experience on Apple's browser engine, so it doesn't seem like Apple is too worried about competition there.

Re:embrace and extend

[Draek]

Apple just wants the best products and doesn't want to have to depend on others to get them, and Flash is the opposite of both of those things.

And proof of it is their excellent support for Ogg and FLAC on their products. Oh, wait.

Heck, their biggest competitor in their fastest-growing market is basing their entire web experience on Apple's browser engine

Apple's? me thinks you were a bit too generous with the kool-aid this morning.

Re:embrace and extend

[fuzzyfuzzyfungus]

Unfortunately, that depends... For classic "Hey, let's try to obfuscate on top of a standard OS running on general purpose hardware and hope nobody with a clue attaches a debugger" style DRM, OSS is indeed technically incompatible. Obtain code, recompile version with locks removed, go home happy. Game over.

However, if the code is under one of the OSS licenses that allows Tivoization(GPL2, among others), and if embedded hardware controlled by the vendor comes into play, you have a very different story. The code is OSS, you bought a product containing the binary. Sure, you are entitled to the source, here you go. Well, yeah, the device bootloader will only load images signed with our private key. Have a nice day. You are welcome to recompile the code for some other device, knock yourself out; but don't expect your device to be able to pass the challenge/response from our server that is handled by the TPM in our device...

If you control the hardware from a fairly low level, you can always enforce DRM that way. Worse, unless you screw up, any attack will actually require a silicon level crack, not just some software chops and patience.

Re:embrace and extend

[glwtta]

Apple wants Flash dead.

Huh, for once Apple and I agree on something.

Re:embrace and extend

[eldavojohn]

They don't want it open, they don't want it closed, they don't want it with cherries and whipped cream on top.

Adobe's Flash
- a poem by eldavojohn

I bash Jobs, Jobs I blash

That Jobs-I-bash, That Jobs-I-bash!
I do not like, that Jobs-I-bash

Do you like Adobe's flash?

I do not like it, Jobs-I-bash.
I do not like Adobe's flash.

Would you like it on your iPad?

I would not like it on my iPad.
I would not like it if it's a fad.
I do not like Adobe's flash.
I do not like it, Jobs-I-bash

Would you like it open or closed?
Would you like it
virtually imposed?

I do not like it open or closed.
I do not like it virtually imposed.
I do not like it on my iPad.
I do not like them if it's a fad.
I do not like Adobe's Flash.
I do not like it, Jobs-I-bash.

Would you install it on your box?
Would you install it in Firefox?

Not on my box.
Not with Firefox.
Not open or closed.
Not virtually imposed.
I would not install it open or closed.
I would not install it virtually imposed.
I would not install Adobe's Flash.
I do not like it, Jobs-I-bash!

Re:embrace and extend

[Nursie]

Flash on 64 it linux has been ok for a while, though it's borked again at the moment whilst adobe re-architect. As for ARM....

Works fine on my N900!

Re:embrace and extend

[h3]

>Flash is, simply, a proprietary format that they don't have any patent control over. They want h264, which is a proprietary format controlled by a consortium they are a major member of.

I think you got the Apple v. Flash "war" mixed up with the HTML5 v Flash war...

I'm pretty sure Apple's objection to Flash on their iOS devices has more with it being an alternate development platform that they can't control and little to do with the specialized use case of video delivery. In other words, they want to make sure HotSellingGame is written using *their* dev tools, not against Flash.

Not that the HTML5 v. Flash war makes that much more sense.

Re:embrace and extend

[dannys42]

The open source version solves the technical problems Apple may have with Flash.

But actually I think they're right in wanting Flash dead. It's true that it's a closed propriety format, and it will lead to a closed web. Perhaps they're doing it for their own selfish reasons. But in this case, I think those reasons coincide with what people want in the long term.

I'm just surprised Google hasn't realized the danger that flash poses. It'll completely demolish their search capabilities.

Re:embrace and extend

[molnarcs]

Apple's browser engine? How many times does this myth have to be corrected? KHTML was a pretty complete rendering engine before Apple adopted it under the name WebKit. It was the only major free software contender to gecko, and Apple was not the first to notice it. NOKIA used it to replace gecko in their handhelds (and they sent a nice thank you letter to the khtml mailing list). Yes, Apple did contribute a lot of code, but they did not write it. And as of now, they are not the only contributors either. So webkit is a bad example for Apple's contributions - they basically forked KHTML (and the first few releases of Safari were pretty much KHTML + a few patches) and they had no choice but to maintain it as free software because KHTML was GPL.

Re:embrace and extend

[natehoy]

I almost went Dr. Seuss.

I'm glad I didn't. It would have looked pathetic compared to your effort.

Bravo, sir.

Re:embrace and extend

[Anonymous Coward]

Actually Apple wants flash dead because if people start writing mobile games for a flash target that runs on iphone, android, windows mobile, etc, then the iphone becomes a generic phone with less lock in.

We are all used to thinking of flash as a closed platform, but to apple, it is way too open.

Re:embrace and extend

[abigor]

And proof of it is their excellent support for Ogg

Ogg is not an "excellent product", by any means. Also, no one cares about it.

And WebKit, while derived from KHTML way back when, really is Apple's. Sorry.

Re:embrace and extend

[StayFrosty]

From wikipedia: WebKit was originally derived by Apple Inc. from the Konqueror browser’s KHTML software library for use as the engine of Mac OS X’s Safari web browser and has now been further developed by individuals from the KDE project, Apple Inc., Nokia, Google, Bitstream, Torch Mobile and others.

Heck, their biggest competitor in their fastest-growing market is basing their entire web experience on Apple's browser engine, so it doesn't seem like Apple is too worried about competition there.

A couple of problems with this statement:

1. It's not Apple's browser engine, it's the community's. Just because Apple is a major member of that community does not mean they own the project. If anything, it's KDE's browser engine since they wrote KHTML in the first place.
2. KHTML is LGPL licensed. Because of this, any fork has to be compatible with the LGPL. This resulted in Webcore and the javascript portions of Webkit being LGPL licensed and the rest BSD licensed.
3. Whether they want to or not, Apple has no say in whether Google or anyone else can use KHTML/Webkit in a competing product. It wasn't a conscious decision to allow Android to use Webkit.

Re:embrace and extend

[moonbender]

How much of the current WebKit is Apple and how much is from other contributors? Does anybody actually know? I'm sure much of KHTML is gone, but the KDE (now Nokia, I guess?) people still work on it, and so does Google among others.

Re:embrace and extend

[goombah99]

Open source software is technically incompatible with DRMs.

Uh no.

Re:embrace and extend

[Draek]

Ogg is not an "excellent product", by any means. Also, no one cares about it.

It was for a long time the best codec for low-bitrate encoding until WMA stepped up its efforts and beat it. And even so it remains an excellent codec, one with very widespread availability thanks to its use on Wikipedia and various game engines among others. Meanwhile FLAC is unquestionably the best and most popular lossless codec in existence, so even if we allowed for a second your poor argument against Ogg, with FLAC there's really no excuse whatsoever.

And WebKit, while derived from KHTML way back when, really is Apple's. Sorry.

Sorry but no, it really isn't.

Re:embrace and extend

[Bill_the_Engineer]

More like Apple would like its iOS devices judged on the performance that can be achieved when compiled code is used (*their* dev tools is GNU gcc well actually GNU Objective-C) instead of being penalized for the poor performance experienced with Adobe flash. Sure they make Xcode, but I don't know anyone who seriously uses it.

Re:embrace and extend

[Xtifr]

Ogg is not an "excellent product", by any means. Also, no one cares about it.

If no one cares about it, why does almost every electronics vendor except for Apple support it? Of course, Ogg is just a wrapper, and the only widely supported codec used with Ogg is Vorbis (not Theora, which is not widely supported), but the simple facts of the matter would still seem to refute your second claim.

As for your first, I'm aware of one widely published criticism released by an extremely biased source, but I'm also aware of a rebuttal pointing out that that criticism assumed different priorities and arbitrarily preferred different tradeoffs than Ogg's designers used. I think the jury's still out on that one. Anyway, Vorbis is clearly among the best, if not single-handedly the best, audio codec out there. Good enough that the combination of Ogg+Vorbis (or Ogg+FLAC) is good enough to meet many people's definition of excellent. Theora, I'll admit, may be another matter, but Ogg itself is definitely good enough in my book, and worst case, I can't see any reason (aside from legal ones) why it couldn't be used with other video codecs.

Re:embrace and extend

[Xtifr]

Ogg is not an "excellent product" [...]

It was for a long time the best codec for low-bitrate encoding

Ogg's not a codec. Vorbis is a codec (and, in conjuction with Ogg, a widely supported one, and an excellent one), but in the context of video, original poster may have been referring to Theora, the video codec, and that one is, perhaps, a bit dubious.

Re:embrace and extend

[Anonymous Coward]

Er, yes. APPLE'S browser engine: each "owner" is tied to its Open Source informally --remember Netscape->Plain Mozilla->Firefird coexisting for a long time.

Apple started the WebKit fork merely in 2005. The matter at hand is that though Apple didn't write KHTML in 1998, they improved it to reach the mythical 100 in the Acid3 test, for instance. The good folks at KHTML have had years to learn from the Open Source WebKit repos. And with all the "good cheating" allowed due to open sources, KHTML is still 10 points behind the curve and marked as a "failing browser"

Re:embrace and extend

[Anonymous Coward]

Yeah, how's that dealing with all the sites that are checking for Flash 10.x these days? On my N900, that bit doesn't work so well. >:(

An open-source implementation means we'll only be as far behind as the desktop version. (Then again, OSS implementations of Flash have a serious taillights issue, so that may be as far behind as we are anyway...)

Re:embrace and extend

[evJeremy]

KDE is still it's own thing. Nokia simply bought Trolltech, who developed the Qt toolkit/framework that's used by KDE.

Re:embrace and extend

[Draek]

You're right, sorry about that, I meant Vorbis the audio codec rather than Ogg the container.

Re:embrace and extend

[moonbender]

Sure, but in the same process they also "acquired" many KDE developers, I just don't know whether the original or current KHTML/Webkit devs are among them. Nokia does contribute to Webkit, so it stands to reason they got at least some Webkit devs via the Trolltech acquisition.

Re:embrace and extend

[totally bogus dude]

Not if the Flash is well-designed, and if it's not well-designed then the site using it will lose ranking in the search engines. I don't think Google really needs to go out of its way to index content nowadays, as if you're not in Google then you don't exist for a lot of the web's users...

Re:embrace and extend

[dannys42]

Not if the Flash is well-designed

How can a Flash app be design to allow for search? The guys at google are smart, I guess they'd figure something out. But it really does change things quite a bit. And makes it much easier to obscure information.

I don't think Google really needs to go out of its way to index content nowadays, as if you're not in Google then you don't exist for a lot of the web's users...

That's true today. But with the current "battle for flash" on the mobile front, that could really change things. If Flash did not have anyone opposing it, many developers would (and currently are) choosing Flash as their platform of choice.

With the mobile market as large as it is and continuing to grow, that's going to be a significant portion of the web. And that'll be a significant portion that will be mostly invisible to search. I don't think it's something Google should readily dismiss.... unless they already have some killer Flash search technology.

Re:embrace and extend

[Anonymous Coward]

That's from 2-and-a-half years ago. The linked bug claims a 100% mark in February this year...

Re:embrace and extend

[totally bogus dude]

How can a Flash app be design to allow for search?

By putting most of the content in searchable formats (probably XML), and probably by following some kind of standards. I mean, Flash apps can be made accessible too, but most developers don't bother. Plus, a well-designed site can have a simple version that can easily be indexed (using e.g. the sitemap XML for search engines) and a "rich" version which might be harder to index. So it's a problem that can be solved in multiple ways. At worst, the .swf could be decoded, and any text blobs within it parsed.

But my point was, sites need search engine traffic more than the search engine needs the site. Yes both are dependent on the other, but unless a great big chunk of the web moves en masse, they'd only be hurting themselves (unless they're in some kind of niche where they don't care about search engine traffic). Or in other words, the onus isn't on Google to find a way to index their site, but on the site owners to make sure that whatever they do, they're still in Google. If a big site blocks a search engine from indexing it (whether via Flash or Java or robots.txt) then other sites will be more than happy to take the extra traffic.

Re:embrace and extend

[Yvanhoe]

Well, we are talking about a flash runtime here...

Ok let's be more precise. No OSS solution with a licence acceptable to the Debian project can implement DRMs on a regular PC (and be more than a joke).

Re:embrace and extend

[dannys42]

By putting most of the content in searchable formats (probably XML), and probably by following some kind of standards.

Well that's part of the problem. Flash applications don't have any standard of the sort. HTML for better or worse is an open standard. And by making websites that conform you automatically get searchability. Flash apps on the other hand require the user then to make the choice to be open. And when presented with that option, honestly I think most users and businesses will not even consider it.

Or in other words, the onus isn't on Google to find a way to index their site, but on the site owners to make sure that whatever they do, they're still in Google.

What you say there is logical. But as we can see in even the online advertising case I don't think businesses and web developers will do what makes sense in those cases.

Businesses especially like to choose flash because of the glitz. Then they figure out how to do SEO on top of that. They don't really think in terms of "if my content is good, they will come."

Also if you look at the mobile market, search is rather terrible in the application space, even on Android. I mean just finding the right application is hard, let alone searching for content within the apps. I'm not saying Google can't do it. But they're not right now. And this is a huge growing market for content. (both as standalone apps and web-based apps). (there's a great article that talks about this issue; I can't find it at the moment, though).

What about license?

[DMiax]

I seem to remember that the real problem Flash clones is that documentation is not completely free and if you read it you have to be under strong NDA for the rest of your life. This should also be why Gnash always lags behind. How did he overcome this issue? Or are we waiting for a lawsuit to strike as soon as the plugin becomes usable?

Re:What about license?

[kevinmenzel]

I seem to remember that the documentation that wasn't free was for video codec implementation? (Admittedly an issue, but one that could be piped to the system codecs, or integration with ffmpeg or something?)

Re:What about license?

[sreekotay]

That was historically true, but is no longer the case (I believe they changed the license coincident with the Open Screen Project release). See here. There are still the H.264 and On2 (as well as Nellymoser and other specific media codec) issues, but not any with open implementations of Flash itself.

Re:What about license?

[larry bagina]

GNASH lags behind for the same reason HURD lags behind.

Re:What about license?

[Anonymous Coward]

What?
The documentation I'm aware of is under the Creative commons Attribution-Non Commercial-Share Alike 3.0 License.
http://livedocs.adobe.com/flex/3/langref/

Gnash?

[jabuzz]

How does this compare to the FSF sponsered Gnash then?

Re:Gnash?

[Anonymous Coward]

Gnash does not support version two of the Actionscript Virtual Machine. (Most new Flash content uses that AVM version.) Lightspark is intended to support exactly that. There are many other differences, but that's the main one.

Re:Gnash?

[ink]

Gnash doesn't support ActionScript 3. Lightspark does. There has been talk on the Gnash list for a hybrid solution.

Gnash

[Anonymous Coward]

How is this different from the gnu flash player (gnash) ?

call me when there is a firefox addon

[Anonymous Coward]

not something i have to dl/compile..... https://addons.mozilla.org/en-US/firefox/

Re:call me when there is a firefox addon

[jedidiah]

...the guy kind of has a point.

When this can be a drop in replacement for the vendor's version that doesn't support video acceleration on most platforms, then it will be something.

For now, it is something that just looks very promising for now.

Re:call me when there is a firefox addon

[unix1]

After it's compiled, you'll end up with a standalone client and a Firefox add-on. It shouldn't be hard to provide an add-on download. As far as I can see, it's Linux only, however.

Re:call me when there is a firefox addon

[dotancohen]

For now, it is something that just looks very promising for now.

You work in the Department of Redundancy Department, no?

Re:call me when there is a firefox addon

[jedidiah]

>> For now, it is something that just looks very promising for now.
>
> You work in the Department of Redundancy Department, no?

IT occupational hazard.

which one

[Anonymous Coward]

By my count there are atleast 4 opensource flash project. Most of them seem to exist just for the developer's own benefit. Is there any analysis or review and comparison of the several open source flash clones?

Re:which one

[cortana]

I refer you to "Interesting times for Linux Flash support" at http://lwn.net/Articles/389266/. I don't know why more (any) LWN articles aren't linked to from Slashdot.

Efficient, yes. But...

[tenco]

...is it secure?

Re:Efficient, yes. But...

[owlstead]

... and is it stable?

Re:Efficient, yes. But...

[Anonymous Coward]

...is it secure?

It certainly can't be any less secure than the Adobe version.

No, that's-a fish!

[RevWaldo]

Chico and Harpo on the problems with Flash substitutes

http://www.youtube.com/watch?v=F5Ovh18nYwc

"Alright never mind c'mon we work without it.."

.

Re:No, that's-a fish!

[rufus t firefly]

"Tie on the bed, throw the rope out the window." Classic.

Hardware Acceleration and Benchmarks

[Flammon]

Has anyone done any benchmarking? Is it hardware accelerated (video, vector etc) on Linux?

Re:Hardware Acceleration and Benchmarks

[bioglaze]

I haven't done any benchmarking, but it is hardware accelerated. It also uses OpenGL Shading Language.

Hulu

[TechwoIf]

Will it work with www.hulu.com?

Re:Hulu

[Anonymous Coward]

Just compiled and installed on debian squeeze. Works with youtube, and thats about it. Hulu, pandora, grooveshark all crash firefox.

Re:Hulu

[evJeremy]

It's a good thing Firefox supports out of process plugins now, isn't it?

Re:Hulu

[jonwil]

Any open source Flash clone that added support for the encrypted version of the RTMP streaming protocol (which is what Hulu and others use) would be hit by a DMCA lawsuit.
If Adobe doesn't do EVERYTHING it can legally do to prevent programs that can save encrypted RTMP streams (or programs that can be modified to save such streams) sites like Hulu will go to their competitor or shut down altogether.

Hell will freeze over before NBC, Fox and ABC (the owners of Hulu) will allow their content to be distributed in a way that would allow people to save permanent unprotected copies to their PCs.

That's just as wrong as mono

[Anonymous Coward]

Stop helping these companies push their proprietary crap on us.

Re:That's just as wrong as mono

[betelgeuse68]

The irony is that if open source people didn't have a target to emulate, there's tons of things that would have never been written since a baseline and mindshare in the overall tech market wouldn't have existed:

lex = flex
yacc = bison
sh = bash
UNIX = LINUX
vi = vim

To name just a few.

So your complaint about "proprietary" falls on deaf ears. If nothing else, what you call proprietary seeds things.

Re:That's just as wrong as mono

[mandelbr0t]

i386 protected mode OS
ext2/3
emacs
Perl, Python and others
decss
bayesian spam filtering
eclipse

To name a few more. Proprietary is not necessarily first, just the first to try and make profit from the project.

Re:That's just as wrong as mono

[dannys42]

Don't forget rpm/deb and the entire package management and distribution infrastructure.

It still surprises me that this came from the open source community AND that to this day no commercial OS has anything close.

Even cygwin doesn't use it in it's distribution, though I understand they have their reasons. But then what reason does projects like macports have to not use real package management?

Re:That's just as wrong as mono

[lisaparratt]

You appear to have made a pretty much random list of technologies/programs - why?

Re:That's just as wrong as mono

[Grishnakh]

My understanding is that Flash has an open specification, just like PDF. So it's not the format that's proprietary, only most of the software that uses the format. This was a problem with PDF too for a long time, but now there's tons of both Free and non-Free tools for both creating and viewing PDF files.

As long as the spec is open, there's no problem; anyone can create compatible software. The problem is usually that it takes a lot longer for other people (especially F/OSS writers) to do it than the company that created the spec and has a vested interest in making it popular.

Re:That's just as wrong as mono

[Grishnakh]

Don't forget rpm/deb and the entire package management and distribution infrastructure.

It still surprises me that this came from the open source community AND that to this day no commercial OS has anything close.

It's simple: proprietary software places want to have control over everything. They don't want to be just another program on your desktop, they want to take it over with buttons everywhere on your desktop and start menu, their corporation name on your start menu (instead of just putting their program in a submenu called "Graphics programs"), etc. This is why proprietary software companies like Windows so much; it doesn't have any problems with them taking over a user's computer with their bloatware.

Package management systems take away control from software makers, and give it to users. Software makers don't like that.

Re:That's just as wrong as mono

[drsmithy]

It still surprises me that this came from the open source community AND that to this day no commercial OS has anything close.

That's because packaging systems exist primarily to address problems that - by and large - don't exist on "commercial OSes": cascading webs of slightly incompatible software versions (ie: "dependency hell") and ease of installation.

Re:That's just as wrong as mono

[Anonymous Coward]

All of those things listed are innovations and new inventions that were free software innovations. They are not works derived from proprietary sources.

Re:That's just as wrong as mono

[moonbender]

You appear to have made a pretty much random list of technologies/programs - why?

• Because he felt like it
• Out of spite
• For reasons unknown
• Oh I'm sorry I didn't see you there
• Google it yourself
• Because it's Wednesday
• The dog ate it

Re:That's just as wrong as mono

[Anonymous Coward]

Oh come off it! Almost all of them have proprietary predecessors that implemented the same functionality.

• i386 protected mode OS: prior art in Unix, mainframe OS's, VMS... any 32-bit OS that used an MMU. If we must be specific to the 386 (why?) then I think even then Xenix did this first.
• ext2/3: dozens of earlier (proprietary) filesystems had the same capabilities first, whether we are talking about basic filesystem capabilities or journalling.
• emacs: hardly the first text editor, emacs' only innovation was stealing Vi's crown by making text editing even more difficult.
• Perl, Python and others: whether these count as programming languages, virtual machines or scripting environments, there is a tonne of proprietary prior art, from C/Fortran to KSH and JCL.
• decss: just a reverse-engineered reimplementation of CSS surely?
• bayesian spam filtering: ok, you win this time... but if email wasn't the classic example of a badly thought out open standard that we're now stuck with, this wouldn't be needed.
• eclipse: pick your proprietary IDE; most likely it predates Eclipse.

While all of these things are valuable (except Perl and Emacs), they are hardly new inventions. Bit of intellectual honesty please!

Re:That's just as wrong as mono

[dannys42]

Well Windows apps did for a while have the DLL hell issue. Not sure if they still do.

But more important I think is the unified package distribution system. packagekit for gnome for example... I only need to get one notice from it that I have software updates. Whereas go to any presentation running a Windows laptop and you'll inevitably see at least one software update, though sometimes several from different apps during the presentation.

What I'm questioning is not the application providers, but the OS vendors lack of inclusion of a common platform for these issues.

Even Apple has this problem when you have lots of 3rd party apps.

Package management in the rpm sense also means to me easier control for the sysadmin to be able to install/uninstall software. The greatest feature is batch non-interactive installs/upgrades. You simply do not have this with commercial software.

Re:That's just as wrong as mono

[Xtifr]

emacs: hardly the first text editor

Not even the first programmers editor, but as a derivative of TECO, it could be argued to be the oldest still-widely-used text editor (with vi as a possible alternative, depending on how you measure the "release date"). Oh, and it couldn't "steal Vi's crown" at anything, because both were in development at about the same time. As for making text editing "more difficult", the state of the art at that time was TECO, and both vi and emacs were big improvements over that.

But your real flaw is looking at emacs purely as a text editor. That's like looking at the Xerox Star and saying it wasn't innovative because computer graphics already existed. The big innovation of Emacs was to embed a full high-level-language interpreter. TECO was programmable, but the programs (much like vi programs) were unreadable line-noise. This enhanced ease-of-use for the macro writer led to an explosion of emacs add-ons and plug-ins that ended up making emacs more-or-less the prototype of the modern IDE.

All that said, I mostly agree with you about the rest of the list, but that doesn't mean the original poster is wrong--merely that his list was poorly chosen. In the early days, most software was what we now call "open source", so pretty much all of modern computing is built on a basis of open source. Better examples might include Curses, Sendmail, Netnews, and, arguably, even compilers and interpreters and such fundamental CS concepts as lists and trees.

Re:That's just as wrong as mono

[Anonymous Coward]

TeX = TeX.

Re:That's just as wrong as mono

[Anonymous Coward]

What's proprietary? The left or the right side?

You talk like as someone would sit down and say "I now will do some proprietary app that will be awesome!".

Reality tells a different story:

"Look, what a cool app, bet those morons don't know what they got; let's make a proprietary version and tell everyone we're cooler!"

Re:That's just as wrong as mono

[drsmithy]

Well Windows apps did for a while have the DLL hell issue. Not sure if they still do.

Er, yeah. That ceased being a real issue back around the 1997-98 timeframe.

But more important I think is the unified package distribution system. packagekit for gnome for example... I only need to get one notice from it that I have software updates. Whereas go to any presentation running a Windows laptop and you'll inevitably see at least one software update, though sometimes several from different apps during the presentation.

The practical difference here is small. Certainly (and clearly) not enough for software developers to funnel all their software distribution through Microsoft (assuming the legal system would even allow them to).

What I'm questioning is not the application providers, but the OS vendors lack of inclusion of a common platform for these issues.

The "platform" exists, it's called Windows Update.

Package management in the rpm sense also means to me easier control for the sysadmin to be able to install/uninstall software. The greatest feature is batch non-interactive installs/upgrades. You simply do not have this with commercial software.

You can absolutely do batch and non-interactive installs with MSI (and other third-party Windows installation systems). Active Directory and Group Policy can do software distribution for anything that's an MSI, and there are third-party solutions for apps without MSI installers.

Re:That's just as wrong as mono

[Alex Belits]

Er, yeah. That ceased being a real issue back around the 1997-98 timeframe.

Really?

The "platform" exists, it's called Windows Update.

I see, you work at Microsoft.

You can absolutely do batch and non-interactive installs with MSI (and other third-party Windows installation systems). Active Directory and Group Policy can do software distribution for anything that's an MSI, and there are third-party solutions for apps without MSI installers.

Packaging system has nothing to do with non-interactive installation. The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.

Re:That's just as wrong as mono

[drsmithy]

Really?

As a common problem ? Absolutely.

Packaging system has nothing to do with non-interactive installation.

I think you need to complain to the poster I was replying to. He was the one using automated installation as an example of why a packaging system is good.

The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.

Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.

Re:That's just as wrong as mono

[dannys42]

The practical difference here is small. Certainly (and clearly) not enough for software developers to funnel all their software distribution through Microsoft (assuming the legal system would even allow them to).

You're just being silly there. Of course that approach would never work. People wouldn't go for it and Microsoft wouldn't want to deal with the hassle. The approach is just what the OSS people did with yum for example. Provide a software updater that others can hook into.

Take Adobe's acrobat reader for example. All I had to do was install their .repo file and now I can get acrobat reader updates along with everything else in the system. Simpler for Adobe, cause they don't have to write an updater tool. And less hassle for the user cause I don't get a separate update notification for every single app I have installed.

There's nothing stopping Apple or Microsoft from implementing those. It's not /that/ difficult to do. A 3rd party could implement it of course but what's their motivation? It's not something that users would pay for and it's not something developers would necessarily pay for. It is something however that directly affects the "user experience" of the operating system. So it makes most sense for Apple and Microsoft to develop.

(re: DLL-hell)

Really?

As a common problem ? Absolutely.

But as I understand it Windows apps solved this problem by simply including dlls in their own app directories. Or did they find a different solution? As a user I don't particularly care as long as everything works. Macs do this and I actually find it a very comfortable solution to the problem. Don't want an app anymore, delete it. No "cruft" lying around (less than Windows anyway). And when I do install an app I don't have to think about what the heck it depends on.

But from a technology standpoint, I like the sharing that RPM makes possible. Though I do agree it's a bit of work to keep things in sync in the back-end. However, I must say I think the public Linux repos/distros have gotten things a lot cleaner in recent years.

Packaging system has nothing to do with non-interactive installation.

I think you need to complain to the poster I was replying to. He was the one using automated installation as an example of why a packaging system is good.

It may be unnecessary to have a packaging system with a non-interactive installation. But the important thing I think it does provide is a unified way of installing/upgrading/tracking across all software on the system (also non-interactively).

The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.

Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.

It's been a while since I've used Debian, but the last time I did, I found it to be one of the most horribly interactive installation systems ever. To be fair, it's quite possible I chose the wrong installation option.

Redhat/Fedora-based systems however have never been interactive or required interactivity at the RPM level.

Sure yum /can/ be interactive. But it's easy enough to tell it to just install what it needs to. Basically what I mean is that I can easily install/upgrade software in batch across a number of systems relatively easily on Redhat-based systems. This is entirely different from a graphical installer that absolutely and always requires me to sit in front of it and click "OK" to move the dialog forward.

I've read things that imply non-interactive installs is possible in Windows. But the from what I've gathered it takes quite a bit of effort to setup an environment that allows for that.On top of that MSIs /may/ allow for non-interactivity but they also may not. It's really up to whoever

Re:That's just as wrong as mono

[drsmithy]

You're just being silly there. Of course that approach would never work. People wouldn't go for it and Microsoft wouldn't want to deal with the hassle. The approach is just what the OSS people did with yum for example. Provide a software updater that others can hook into.

The practical difference between them installing some sort of .repo equivalent, and special updater apps, is not significant. The end result (timely updates) is the same.

There's nothing stopping Apple or Microsoft from implementing those. It's not /that/ difficult to do.

Sure, but where's the motivation ? The practical results will be little different from today, and chances are fair to good third party vendors won't use it anyway.

But as I understand it Windows apps solved this problem by simply including dlls in their own app directories. Or did they find a different solution?

The solution is a _stable_ base of shared libraries providing large amounts of functionality provided in the base system and the ability of apps to package local copies of DLLs if they need them. The "stable" part is what's missing from OSS systems, as updating one part nearly always leads to a cascade of dependency updates as well, because ABI stability in the OSS world is, at best, an afterthought.

The solution on OS X, by the way, is identical - a large set of stable libraries in the base distribution and facilities for per-app libraries where required.

Sure yum /can/ be interactive. But it's easy enough to tell it to just install what it needs to. Basically what I mean is that I can easily install/upgrade software in batch across a number of systems relatively easily on Redhat-based systems. This is entirely different from a graphical installer that absolutely and always requires me to sit in front of it and click "OK" to move the dialog forward.

And, similarly, you can do batch and unattended installations on Windows. That doesn't change the fact that an individual installing a specific application they want using yum (or some graphical wrapper for it) is an interactive task.

I've read things that imply non-interactive installs is possible in Windows. But the from what I've gathered it takes quite a bit of effort to setup an environment that allows for that.On top of that MSIs /may/ allow for non-interactivity but they also may not. It's really up to whoever wrote the MSI.

Yes. Just like RPMs.

I was quite excited when I first heard about MSIs on Windows, but then got rather disappointed when most MSI apps I installed still ran interactively.

MSIs almost always have switches for non-interactive installs. They don't do that by default, of course, since 99% of the time they're being installed in a situation where the user wants an interactive task.

You /could/ argue that someone can get an RPM to require interactivity as well. But that's not quite the same thing. RPMs don't have specific features that allow it.. ie. it really is designed for batch operations. And you really break it's operation with things like yum if you try to do something like that.

The "interactive" part is typing 'yum install blah', or 'rpm -ivh blah'. That's the equivalent of running an MSI and hitting next a few times. Both are interactive tasks (ie: not automated, not transparent, not managed by a third party).

If you know how I can install any and all MSI's I come across non-interactively, I'd greatly appreciate a pointer to a tutorial or something.

As with Linux apps, it's utterly dependent on the developer (or someone else) to package it properly. With that said, most MSIs should come with an "unattended install" option. Try running 'someinstaller.msi /?'.

Re:That's just as wrong as mono

[dannys42]

Sure, but where's the motivation ? The practical results will be little different from today, and chances are fair to good third party vendors won't use it anyway.

I already addressed the motivation... several times.

The "stable" part is what's missing from OSS systems, as updating one part nearly always leads to a cascade of dependency updates as well, because ABI stability in the OSS world is, at best, an afterthought.

Agreed. OSS does need better care in that area. Though to be fair, I think there's far more dependency in OSS apps than commercial apps.

The "interactive" part is typing 'yum install blah', or 'rpm -ivh blah'. That's the equivalent of running an MSI and hitting next a few times. Both are interactive tasks (ie: not automated, not transparent, not managed by a third party).

I don't think you understand what people mean by "required interactivity". If you have the time, I suggest read the "Unix Philosophy". The author describes the issue in point as "Captive User Interfaces". These are interfaces that _require_ the user to sit there and baby sit an application. Yes, certainly typing "yum install..." requires an action by the user. However, a simple "yum -y install ..." will not _require_ further input from the user (unless of course there's some sort of failure). Contrarily, _every_ graphical installer I've ever used (Windows, Linux, Apple, etc.) always requires the user to sit through various choices and mixing in long operations with babysitting "click next to continue" type operations.

If an operation is going to take a while I want to make my choices up front, walk away and be able to come back and have it be done. That's the difference between interactivity and non-interactivity. Don't confuse this with action vs non-action.

The inherent problem with a graphical installer is that even if you reduce it to a single "OK" click in the beginning of the app, it doesn't solve the problem. The reason is when I have to do a batch operation, eg because I'm installing multiple apps, I want to just "set it up and go".

RPMs are inherently scriptable and I have this ability.

And, similarly, you can do batch and unattended installations on Windows.

Again... theoretically possible is one thing. Practical possibility is another. Can I take most of the software I'd want to install on Windows and do this? I know I certainly can for Linux.

Tools that I typically want on a Windows system would be Firefox, putty, 7-zip, Acrobat Reader. Perhaps the Gimp and OpenOffice. In a business setting MS Office of course. Can I get all those programs to install non-interactively on Windows? I've seen technotes for how to do this with MSOffice. But honestly it's way more work than it was worth to me. To me it wasn't both practical AND possible.

As with Linux apps, it's utterly dependent on the developer (or someone else) to package it properly. With that said, most MSIs should come with an "unattended install" option. Try running 'someinstaller.msi /?'.

Again, you've ignored my statement. Of course some developer could do something wrong. That always happens. But that's not what I'm talking about. I'm talking about the usual case of (theoretically) competent developers following the documentation and design of the tools available to them. With RPMs it actually is entirely wrong to have an interactive RPM. While someone may be able to figure it out, there's certainly nothing in the documentation that tells you how to do that. And unless I am mistaken, it is _NOT_ wrong to create an MSI that requires interactivity. I seem to recall seeing in Microsoft's documentation them describing just how you can do it. And making it entirely a developer choice.

I'm not making a value judgement on Microsoft's case for MSIs. But I am pointing out the inherent difference in the system and what that means to me when I have to manage Microsoft systems.

Re:That's just as wrong as mono

[Alex Belits]

As a common problem ? Absolutely.

Then Windows users have strange definition of a "problem". Every time one has to combine products that use incompatible versions of libraries, havoc ensues unless each products drags absolutely everything with itself. It became easier for software vendors to distribute trivial programs as 1G packages, however users still have to deal with incompatibilities and duplication of everything at runtime.

I think you need to complain to the poster I was replying to. He was the one using automated installation as an example of why a packaging system is good.

"Automated" means that it handles dependencies, configuration and resolves conflicting settings.

Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.

You obviously never used those tools. They have interactive mode used to give the user choice of settings and merge user-modified configuration with modifications in a package, however both can (and should) be turned off when performed unattended or when user intends to always rely on updates in the package.

Interactivity is not the issue in the first place -- you seem to unable to realize that functionality is not the same as presence or absence of user interface doodads.

Re:That's just as wrong as mono

[Kjella]

It's not that it doesn't exist, it's more that they took the brute force approach to solving it. A lot of it is distributed on CD/DVD, just put everything on the disc. Even digital downloads now rather bloat their installers than deal with it, for example because you might not be online anymore when you try to install it or you're running it from a different PC. They just assume you have the bandwidth, if not get the boxed/burned version.

Re:That's just as wrong as mono

[Anonymous Coward]

The practical difference between them installing some sort of .repo equivalent, and special updater apps, is not significant. The end result (timely updates) is the same.

The practical difference is in ease of management. Is being able to manage all your updates from a single interface significant? You might be able to argue is isn't, but it sure is nice and convenient.

Re:That's just as wrong as mono

[Tubal-Cain]

Package management systems take away control from software makers, and give it to users.

In what way?

Re:That's just as wrong as mono

[drsmithy]

Then Windows users have strange definition of a "problem".

I can't even remember the last time I saw a DLL related problem.

Every time one has to combine products that use incompatible versions of libraries, [...]

Something that happens quite rarely these days, which is my point.

It became easier for software vendors to distribute trivial programs as 1G packages, however users still have to deal with incompatibilities and duplication of everything at runtime.

Can you give some examples of "trivial programs being distributed as 1G packages", and/or common, contemporary software that has or causes DLL conflicts ?

"Automated" means that it handles dependencies, configuration and resolves conflicting settings.

And.... Your point is ?

You obviously never used those tools.

I'm responsible for a couple of hundred Linux machines, I probably run yum at least once a day, on average. Admittedly I don't use apt much since we're pretty much completely a CentOS/RHEL shop, but I have some personal VMs with Ubuntu installed.

They have interactive mode used to give the user choice of settings and merge user-modified configuration with modifications in a package, however both can (and should) be turned off when performed unattended or when user intends to always rely on updates in the package.

Which is relevant how, exactly ? My point was that and end user using those tools to install or update software *is an interactive task*. The fact that they can also be scripted to do stuff as well is utterly irrelevant.

Interactivity is not the issue in the first place -- you seem to unable to realize that functionality is not the same as presence or absence of user interface doodads.

And you seem completely incapable of actually understanding and contributing anything to the discussion except rhetoric and comical exaggeration.

Re:That's just as wrong as mono

[drsmithy]

I already addressed the motivation... several times.

Not really. The updater apps are already written, and getting notifications every other day for different apps is really no different whether it comes from an individual application or a central tool.

I don't think you understand what people mean by "required interactivity". If you have the time, I suggest read the "Unix Philosophy".

"The UNIX Philosophy" is almost entirely about writing commandline tools for highly competent end users to automate tasks with. It's relevance to interactive GUI interfaces for mostly ignorant users is rather suspect.

To pick one rather obvious point, when the typical end user runs some program and gets no response or feedback, they assume it hasn't done anything and/or failed. The UNIX Philosophy is pretty much the complete opposite.

Contrarily, _every_ graphical installer I've ever used (Windows, Linux, Apple, etc.) always requires the user to sit through various choices and mixing in long operations with babysitting "click next to continue" type operations.

Really ? Because most installers I can recall (though I will readily admit to installing things rarely) ask a few questions to start with about location, EULA, install for all users, etc, then go off and do their thing until the last "I'm done" screen where you just have to click finish.

The inherent problem with a graphical installer is that even if you reduce it to a single "OK" click in the beginning of the app, it doesn't solve the problem. The reason is when I have to do a batch operation, eg because I'm installing multiple apps, I want to just "set it up and go".

You're _way_ outside the normal use case for just about everyone except a UNIX nerd here.

Tools that I typically want on a Windows system would be Firefox, putty, 7-zip, Acrobat Reader. Perhaps the Gimp and OpenOffice. In a business setting MS Office of course. Can I get all those programs to install non-interactively on Windows? I've seen technotes for how to do this with MSOffice. But honestly it's way more work than it was worth to me. To me it wasn't both practical AND possible.

As with Linux, it depends on the developer to package it properly. Again, a batched/scripted/unattended install is so far outside the common use case for a Windows (or OS X, or indeed pretty much anything) end user that it not being the default is both understandable and expected. If you want to batch/script unattended installs, it's expected you'll be doing it in a managed environment, and thus have the requisite knowledge (or be prepared to learn).

Clearly we have different definitions of "interactive". Mine is one where end user interaction is required. Yours is one where end user interaction above a certain level is required.

Re:That's just as wrong as mono

[Alex Belits]

Something that happens quite rarely these days, which is my point.

Only because libraries are now are either Microsoft products, or everything is tied to the executables -- they can just as well be statically linked now.

Can you give some examples of "trivial programs being distributed as 1G packages"

Each and every piece of software released after 2000.

, and/or common, contemporary software that has or causes DLL conflicts ?

Only because they all come with their own copy of everything, and it stays that way in memory, causing performance problems. How many copies of, say, JPEG library do you have in your RAM right now?

And.... Your point is ?

My point is, Windows does not have it. If it did, people would not have 8-core boxes running 10 VMWare instances, each running a single "server" product.

I'm responsible for a couple of hundred Linux machines, I probably run yum at least once a day, on average. Admittedly I don't use apt much since we're pretty much completely a CentOS/RHEL shop

Then you are incompetent at your job.

, but I have some personal VMs with Ubuntu installed.

Oh wow.

Which is relevant how, exactly ? My point was that and end user using those tools to install or update software *is an interactive task*. The fact that they can also be scripted to do stuff as well is utterly irrelevant.

What the Hell are you arguing about? If you run a single, customized desktop installation, you would want update started manually and running interactively. If you run large number of boxes with predictable or identical configuration, you launch can have everything running with a cron job.

However if you are a competent sysadmin maintaining a large system, you run the update on a staging box, check if it is safe to run with default settings on production hosts, then run cssh to update everything at once (possibly after some other updates that you find necessary -- you may, for example, revert some customization, produce pre-merged configuration, etc). Anything less is unsafe -- you either delay security-related fixes or apply upgrades that may be incompatible with your setup. Anything more wastes time that can be used for something more productive.

Windows is so far behind this, "sysadmins" like you can't even imagine what responsible maintenance procedure looks like. "Interactivity" and "scripting" are of about the same relevance as the color of the box installation media came in -- what matters is the amount of work package manager does to keep things consistent, so human doesn't have to.

And you seem completely incapable of actually understanding and contributing anything to the discussion except rhetoric and comical exaggeration.

My understanding is that you are an experienced Windows sysadmin (a.k.a. VMWare jockey), who does not realize that it's possible to have efficient and straightforward package manager and reliable installation and update procedure, so he makes idiotic claims about irrelevant details.

Re:That's just as wrong as mono

[drsmithy]

Only because libraries are now are either Microsoft products, or everything is tied to the executables -- they can just as well be statically linked now.

Er, yeah, that's kind of the point. The solution to dependency hell is a properly controlled set of stable, binary compatible (forwards and backwards) base libraries, and standardised locations for third parties to install their own.

Each and every piece of software released after 2000.

Uh huh. Even our whole install point for Office 2007 is less than a gig, and I can see at least a dozen "trivial applications" in our software distribution share whose installers are less than 20MB.

It'd be a lot easier if people like you just said you were trolling from the get-go.

Only because they all come with their own copy of everything, and it stays that way in memory, causing performance problems. How many copies of, say, JPEG library do you have in your RAM right now?

Can you point to some examples of applications that do this ?

My point is, Windows does not have it.

Absolutely it does. You can automate and batch unattended installs. Individual application developers might write their application in such a way that you can't do that, but that's not the fault of Windows.

If it did, people would not have 8-core boxes running 10 VMWare instances, each running a single "server" product.

Struggling to see the relevance between automating software installation and this. Not to mention your scenario is also quite common with Linux VMs, in no small part because of dependency hell (though being able to run the ideal scenario of one service per server is also nice).

What the Hell are you arguing about?

That using yum (or whatever) on Linux to install something is an interactive task.

Windows is so far behind this, "sysadmins" like you can't even imagine what responsible maintenance procedure looks like.

Yet strangely you've described an implementation of the standard practice I've been using for around a decade, across Windows, FreeBSD, Solaris and Linux servers.

"Interactivity" and "scripting" are of about the same relevance as the color of the box installation media came in -- what matters is the amount of work package manager does to keep things consistent, so human doesn't have to.

What's even better is when you have a platform that doesn't need to do all that work in the first place, because it actually has some understanding of "standard functionality" and "binary compatibility".

I can understand if you're caught up in the Linux mindset of "updating X must also cascade into updates for Y, A, J and a replacement of Q with N" then you might have trouble grasping the concept of just updating X, but don't worry, it'll come with time.

My understanding is that you are an experienced Windows sysadmin (a.k.a. VMWare jockey), who does not realize that it's possible to have efficient and straightforward package manager and reliable installation and update procedure, so he makes idiotic claims about irrelevant details.

Considering I haven't adminned Windows machines in anger for going on 5 years now, and I've been adminning various UNIX platforms for 10-15 years, I'd say your understanding is - unsurprisingly - awful. I do look after a few VMware clusters, however, so I guess you're not completely wrong.

Re:That's just as wrong as mono

[dannys42]

Not really. The updater apps are already written, and getting notifications every other day for different apps is really no different whether it comes from an individual application or a central tool.

That's not true. With a single tool implementation like PackageKit, I get a single notification that there are many updates. In a "typical" windows setup, I'll get popups and notifications from all sorts of apps where I just have to keep clicking through them. Think of all the users out there that don't immediately update software when a notification comes in. Just recently, I got continuous notifications from Adobe Acrobat Reader on Windows nagging me about a new update. Then when I finally did install it, it kept reminding me I had to reboot. I really didn't want to at the time, I was busy with actual work and don't like rebooting often. The software, despite what they're saying still works. So I don't want the nag. And if you magnify that issue to all apps installed, it'd be just a horrible pop-up fest of "update me now" dialogs.

To pick one rather obvious point, when the typical end user runs some program and gets no response or feedback, they assume it hasn't done anything and/or failed. The UNIX Philosophy is pretty much the complete opposite.

Yes, there's some fundamental differences about what Unix command-line assumes about the user and what most people deem appropriate for "the desktop". But, you'll notice most of the tenets of the Unix Philosophy say nothing of the example you mention. The only one that comes close is the one about making every program a filter and that's down at #9.

The lessons in the book are still important to understand even in GUIs. The reason the author talks about "captive user interfaces" is because a GUI does not specifically "have" to be captive. And it's perfectly possible to write captive command line programs.

I'll give you a great example that's still a problem on Windows and I believe Linux. I think however, that Macs do this correctly.

If you move a whole bunch of files from one directory to another. As soon as there's any sort of issue (eg. a file is marked read-only or the file will overwrite an existing one), then the copy operation stops as it prompts the user. The concept of the "captive user interface" is still there. Well if I'm moving a large enough data set, that operation could take hours. I want to be able to leave it and come back and expect it to either (1) be done or (2)do as much as it can and have a checklist of things i should manually acknowledge. The typical "Yes, Yes All, No, No All" options are really dumb and not sufficient. (Ideally the UI should also allow me to treat this as an atomic operation, but that's another story).

As with Linux, it depends on the developer to package it properly.

You're ignoring my comments again. On Windows, a "setup.exe" is perfectly "proper". It's the defacto standard. On Fedora, sure it's "possible" but it's really not proper. It's not how most apps are installed.

If you want to batch/script unattended installs, it's expected you'll be doing it in a managed environment, and thus have the requisite knowledge (or be prepared to learn).

And that's exactly my point. It's something that's difficult to to do in Windows. And not difficult to do in Linux. I'm not talking about teaching someone who barely knows how to center text in MSOffice how to do system administration. I'm talking about how much effort it is for someone with reasonable administrative experience being able to figure out and implement.

With rpms, you learn a few options like "-e, -U" etc and you can get through. On Windows, what do I have to do? Install an Exchange server or something? And only if I'm lucky if the app I wanted had an appropriate MSI will I be able to do it? It's completely not the same level of work or effort.

Cl

Re:That's just as wrong as mono

[Alex Belits]

Er, yeah, that's kind of the point. The solution to dependency hell is a properly controlled set of stable, binary compatible (forwards and backwards) base libraries,

Typical Microsoft -- solution to progress creating problem is to stop progress.

and standardised locations for third parties to install their own.

There are no "third parties" (unsupported second class citizens) in a properly designed system.

Uh huh. Even our whole install point for Office 2007 is less than a gig, and I can see at least a dozen "trivial applications" in our software distribution share whose installers are less than 20MB.

Exaggeration apparently is completely lost on you. 20M for an application that has 100K of original code is not acceptable in any sanely developed system -- considering that all this code will end up separately loaded into memory.

Can you point to some examples of applications that do this ?

All of them. Try to find any dynamically linked library that is not shipped by Microsoft in any package that is known to use that library, and you will either find none (so it is statically linked) or a separate copy. And this happens with each and every application/library combination. This duplication causes performance degradation because CPU can't re-use library code in its cache across context switches.

Absolutely it does. You can automate and batch unattended installs. Individual application developers might write their application in such a way that you can't do that, but that's not the fault of Windows.

And those automated installs will still create massive amounts of duplicated copies of everything, or cause failures, or both. The fact they are running without you clicking on icons is absolutely irrelevant, I am talking about installers actually doing something useful.

Struggling to see the relevance between automating software installation and this.

This means, you are stupid.

Not to mention your scenario is also quite common with Linux VMs, in no small part because of dependency hell (though being able to run the ideal scenario of one service per server is also nice).

This only happens when those "Linux VMs" are administered by Windows admins such as yourself. Using VM as a replacement for package manager is a typical Windows technique, that exists because Windows has no usable package manager. Obviously Windows admins do it on Linux for the same purpose.

That using yum (or whatever) on Linux to install something is an interactive task.

Stop bringing up this stupid strawman, this is completely irrelevant to anything I am talking about. init can be run interactively -- does it matter, too?

What's even better is when you have a platform that doesn't need to do all that work in the first place, because it actually has some understanding of "standard functionality" and "binary compatibility".

Windows does not have such thing, unless you are talking about compatibility between Microsoft products with other Microsoft products of the same generation.

Yet strangely you've described an implementation of the standard practice I've been using for around a decade, across Windows, FreeBSD, Solaris and Linux servers.

On Windows, if Microsoft-sanctioned update breaks anything, you have only two choices -- not to update, or break and replace everything. Without a package manager on any system you have to manually produce a consistent configuration on every such update, what takes entirety of sysadmin's time. With package manager sysadmin most of the time relies on updates and only occasionally has to perform configuration that he didn't initiate himself.

I can understand if you're caught up in the Linux mindset of "updating

Re:That's just as wrong as mono

[drsmithy]

Typical Microsoft -- solution to progress creating problem is to stop progress.

It's hardly a "Microsoft" solution, it's the solution on essentially every platform except Linux (or those using software primarily derived from Linux sources).

Linux is the _only_ mainstream platform that treats standardised, stable, binary-compatibility as a bad thing. Everyone else considers it an architectural requirement.

There are no "third parties" (unsupported second class citizens) in a properly designed system.

Your definition of "third party" is broken.

Exaggeration apparently is completely lost on you.

Well that's the problem with foaming zealots. You can never be sure when they're serious.

All of them.

Name some.

Try to find any dynamically linked library that is not shipped by Microsoft in any package that is known to use that library, and you will either find none (so it is statically linked) or a separate copy. And this happens with each and every application/library combination. This duplication causes performance degradation because CPU can't re-use library code in its cache across context switches.

Perhaps you missed the point of %PROGRAMFILES\Common Files, or just %SYSTEMROOT%\System[32] for poorly written applications.

For a counter-example, Apple (shockingly enough, given their history of Windows software) put a set of DLLs used by their applications in %PROGRAMFILES%\Common Files\Apple\Apple Application Support.

And those automated installs will still create massive amounts of duplicated copies of everything, or cause failures, or both. The fact they are running without you clicking on icons is absolutely irrelevant, I am talking about installers actually doing something useful.

You seem to be working from a false premise.

This only happens when those "Linux VMs" are administered by Windows admins such as yourself. Using VM as a replacement for package manager is a typical Windows technique, that exists because Windows has no usable package manager. Obviously Windows admins do it on Linux for the same purpose.

False. Note the presence of multiple solutions (Zones, Jails, Xen, UML, chroot) that are used in a similar fashion, most of which are _only_ capable of running Linux or some other UNIX.

Stop bringing up this stupid strawman, this is completely irrelevant to anything I am talking about.

That's because you're so desparate to go Windows-bashing you ignored the actual topic of discussion.

Windows does not have such thing, unless you are talking about compatibility between Microsoft products with other Microsoft products of the same generation.

False. Trivially demonstrable as such too, simply by firing up any one of a zillion old Windows applications on a newer release than the one they were written to.

On Windows, if Microsoft-sanctioned update breaks anything, you have only two choices -- not to update, or break and replace everything.

Just like RHEL, Ubuntu, Solaris, OSX, or basically any other platform, you mean ?

Without a package manager on any system you have to manually produce a consistent configuration on every such update, what takes entirety of sysadmin's time.

This is so far from the truth I can only assume you're back into "every Windows application is a minimum 1GB package" territory again.

Replacement of packages and required upgrades are not something some guy writes for each and every situation, and it's not something a human has to worry about -- it's all generated automatically, and automatically applied to a running system. The only alternative to this is to abandon all development not done by OS vendor, something that Microsoft, obviously tries to promote.

And this one is just so far from _reality_ that I'm beginning to think you're just on some nasty trip.

I have 24 years of experience in software development a

Re:That's just as wrong as mono

[drsmithy]

That's not true. With a single tool implementation like PackageKit, I get a single notification that there are many updates. In a "typical" windows setup, I'll get popups and notifications from all sorts of apps where I just have to keep clicking through them. Think of all the users out there that don't immediately update software when a notification comes in. Just recently, I got continuous notifications from Adobe Acrobat Reader on Windows nagging me about a new update. Then when I finally did install it, it kept reminding me I had to reboot. I really didn't want to at the time, I was busy with actual work and don't like rebooting often. The software, despite what they're saying still works. So I don't want the nag. And if you magnify that issue to all apps installed, it'd be just a horrible pop-up fest of "update me now" dialogs.

The practical difference between a single "unified updater" nagging about an update every other day, and a different "per-app" nagging about an update every other day, is not really significant. Either way, you end up getting nagged, it's just the nagging has a different skin each time.

Yes, there's some fundamental differences about what Unix command-line assumes about the user and what most people deem appropriate for "the desktop". But, you'll notice most of the tenets of the Unix Philosophy say nothing of the example you mention. The only one that comes close is the one about making every program a filter and that's down at #9.

I was actually thinking about ESR's "Rule of Silence: When a program has nothing surprising to say, it should say nothing". However, there's also Lesser Tenet #5: "silence is golden". Basically, the "no news is good news" principle is a cornerstone of UNIX tool implementation and, more importantly in the context of this discussion, describes the fundamental core of your argument. Again, I will make the point that UI behaviour acceptable to highly-experienced UNIX users, is of questionable relevance to the typical desktop PC user.

I'll give you a great example that's still a problem on Windows and I believe Linux. I think however, that Macs do this correctly.

Macs do not behave in the way you describe. When they hit some sort of roadblock copying, they stop (and they have some *very* unintuitive and destructive behaviour when doing things like copying two directories with the same name to one place). In some situations (generally involving network operations), not only do they stop, but they don't allow the possibility of resuming.

In fact, I can't think of _any_ UI off the top of my head which behaves the way you want, unless explicitly told to (cp -f, for example). If you want one justification as to why, I shall point you to ESR's ""Rule of Repair: When you must fail, fail noisily and as soon as possible".

You're ignoring my comments again. On Windows, a "setup.exe" is perfectly "proper". It's the defacto standard.

A properly built setup.exe will also allow unattended installs.

And that's exactly my point. It's something that's difficult to to do in Windows. And not difficult to do in Linux. I'm not talking about teaching someone who barely knows how to center text in MSOffice how to do system administration. I'm talking about how much effort it is for someone with reasonable administrative experience being able to figure out and implement.

I would argue that someone with reasonable _Windows_ sysadmin admin experience shouldn't have too much trouble, assuming their tools (the MSIs and setup.exe's, etc) are properly built. Obviously if they have to fight against the developer, then it's going to be more difficult - but so is installing (and especially maintaining) packages outside the control of the package manager.

With rpms, you learn a few options like "-e, -U" etc and you can get through. On Windows, what do I have to do? Install an Exchange server or something? And only if I'm lucky if the app I wanted had an appropriate MSI wil

Re:That's just as wrong as mono

[Alex Belits]

It's hardly a "Microsoft" solution, it's the solution on essentially every platform except Linux (or those using software primarily derived from Linux sources).

That's because Linux implemented a proper solution first, you dumbass. Everyone else is far behind.

Your definition of "third party" is broken.

No, it is not. For the user there should be no distinction between components provides by OS vendor and by everyone else.

Well that's the problem with foaming zealots. You can never be sure when they're serious.

Microsoft fanboys call everyone else zealots.

Name some.

HP printer drivers. A whole CD of dependencies. Surprisingly, HP maintains software with the same functionality for Linux -- in packaged form it has no built-in dependencies, and properly interacts with CUPS, SANE, KDE, GNOME and every frontend in existence.

Perhaps you missed the point of %PROGRAMFILES\Common Files, or just %SYSTEMROOT%\System[32] for poorly written applications.

I don't think, you recognize anything you are supposedly arguing with. To be honest, I can't even determine which part of things you actually know anything about because you bring up random facts about Windows installation mechanism, that have absolutely nothing to do with its deficiencies I am talking about. Are you just trying to get the last word by sprinkling some idiotic statements with insults? It doesn't work that way.

For a counter-example, Apple (shockingly enough, given their history of Windows software) put a set of DLLs used by their applications in %PROGRAMFILES%\Common Files\Apple\Apple Application Support.

This is exactly the problem -- same DLLs of slightly different versions end up in multiple locations. Then, when applications run, DLLs are simultaneously mapped into multiple location in memory. As context switches between processes, there is no performance gain from reusing library image in RAM that would happen otherwise, and that was the reason for creating dynamic libraries in the first place (CPU cache lines can persist across context switches, less page-out/page-in of read-only pages when memory is full, etc).

Or did you think, it's all harmless as long as you have enough memory?

That's because you're so desparate to go Windows-bashing you ignored the actual topic of discussion.

Let me refresh your memory:

Someone (not me) said:

Package management in the rpm sense also means to me easier control for the sysadmin to be able to install/uninstall software. The greatest feature is batch non-interactive installs/upgrades. You simply do not have this with commercial software.

You replied:

You can absolutely do batch and non-interactive installs with MSI (and other third-party Windows installation systems). Active Directory and Group Policy can do software distribution for anything that's an MSI, and there are third-party solutions for apps without MSI installers.

I replied:
Packaging system has nothing to do with non-interactive installation. The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.

So first and foremost , you are arguing with the wrong person.

Second, you have claimed:

Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.

and then went on a long chain of rebuttals "explaining" that you can still call package managers "interactive" because they can run interactively by the user.

I guess, this was intended to somehow counter my position that existence of interactive installers is broken. This means, you are either too stupid or pretend to be too stupid to realize the obviou

Re:That's just as wrong as mono

[dannys42]

The practical difference between a single "unified updater" nagging about an update every other day, and a different "per-app" nagging about an update every other day, is not really significant. Either way, you end up getting nagged, it's just the nagging has a different skin each time.

Again... the problem with multiple updates is that you get nagged simultaneously or one right after the other.

Basically, the "no news is good news" principle is a cornerstone of UNIX tool implementation and, more importantly in the context of this discussion, describes the fundamental core of your argument.

No, that's the cornerstone of Unix command line tools. And is specifically NOT the core of any of my arguments. It's the cornerstone of the argument you think I'm arguing even though I've repeatedly said otherwise. I do highly suggest you read "The UNIX Philosophy" by Mike Gancarz.

But in real terms the difference between "double clicking"/"running rpm -ivh" and "clicking next a few more times" is not large.

For single program one-off situations, that may be the case. But again I don't think that was ever the argument.

Anyway, I've enjoyed debating with you, but I think this thread has lost it's focus.

Waste of time

[betelgeuse68]

Some projects are worthwhile, this smells of things like "ReactOS", i.e. something I would never use. I would suggest to the people on this project to go contribute to open source projects that would get people to even have an inclination of using a LINUX desktop.

Re:Waste of time

[Narishma]

What makes you think those developers are interested in getting people to use Linux?

Re:Waste of time

[Draek]

Some projects are worthwhile, this smells of things like "ReactOS", i.e. something I would never use.

But fortunately, the Open Source community comprises a lot more people than just you.

I would suggest to the people on this project to go contribute to open source projects that would get people to even have an inclination of using a LINUX desktop.

And I would suggest *you* to go contribute to those projects if you want to see them succeed.

Re:Waste of time

[Anonymous Coward]

I would suggest to the people on this project to go contribute to open source projects that would get people to even have an inclination of using a LINUX desktop.

Why?

You believe there is only open source when there is Linux? This kind of thinking doesn't help the open source community.

Re:Waste of time

[Abcd1234]

Some projects are worthwhile, this smells of things like "ReactOS", i.e. something I would never use.

Ah, I see, so unless *you* would use it, it's a "waste of time".

Uhuh.

Re:Waste of time

[Grishnakh]

One of the big problems in Linux is Flash support. For better or worse, Flash is needed to view a lot of websites, most notably Youtube. An open-source flash player promotes Linux on the desktop, by making it so that users can do all the same things in Linux that they currently do in Windows.

You're not going to get people to switch to Linux by making it impossible to do all the things they do in Windows. However, if you can make it even easier to do things in Linux that they currently do in Windows, or allow them to do the same things but also add capabilities that are locked out in Windows, they might just switch. For instance, a browser/flash player that lets them right-click and save a copy of a video (even though the website doesn't want to allow that), is something that many users would like. Or a browser that lets them block certain flash content (ads) while allowing others (videos); this is something you usually don't find from proprietary vendors like MS, because they're more interested in other corporations' interests than in users' interests.

Re:Waste of time

[drsmithy]

Ah, I see, so unless *you* would use it, it's a "waste of time".

ReactOS is a "waste of time" because it will never, ever be a genuinely viable alternative to running Windows.

Re:Waste of time

[Abcd1234]

I never said anything about ReactOS. Why are you changing the subject?

Re:Waste of time

[Nutria]

Flash is needed to view a lot of websites, most notably Youtube.

To heck with YouTube... My wife needs Flash to watch /Brothers and Sisters/ and my kids "need" it to play the games thy like.

Mixed bag

[noidentity]

The good news: it's an open-source Flash player

The bad news: for better compatibility with web browsers, it's written in Flash

As long as it's nothing like...

[Anonymous Coward]

As long as it produces effects that are nothing like those of AllSpark (tm)...

And the critical question.. Does it support FV?

[Maxo-Texas]

Mafia Wars, etc?

Re:And the critical question.. Does it support FV?

[drinkypoo]

I feel dirty for asking this particular question, but did they make some change to mafia wars that requires flash? It's been some time since I played it (and I have no intention of starting up again regardless of your answer, I just want to know how well-informed you are in this case)

Re:And the critical question.. Does it support FV?

[Maxo-Texas]

I "play" farmville to maintain connection with a couple friends. I've blocked mafia wars and had the medieval games. I'm not sure if they use flash.

FV has gotten very annoying lately. You click on "send gifts" and it inserts other pages in the flow to force you to participate in the tuscan wedding.

I am down to about 1 day out of 4 now. The recipes and bushels and other activities are starting to sound like EQ trade skilling and don't match my '20 minutes a day' metric.

Re:And the critical question.. Does it support FV?

[drinkypoo]

The interstitial stupidity is a part of the reason I stopped playing those retarded games. the fact that they're lame had something to do with it too. Now I'm playing another lame game without any added stupidity called dragon's call.

PulseAudio

[Anonymous Coward]

I'm trying to build it now and in case anybody wants to bitch about audio systems, it appears to use PulseAudio.
Of course I have ALSA.

Shit is going to ensue.

Re:PulseAudio

[Jorl17]

Code your own ALSA backend or find somebody who can! For some reason it is an open-source project!

Re:PulseAudio

[loufoque]

Then run pulseaudio on top of ALSA, like everyone. You can still use ALSA directly if you want to.

Solution

[neoshroom]

I seem to remember that the real problem Flash clones is that documentation is not completely free and if you read it you have to be under strong NDA for the rest of your life. This should also be why Gnash always lags behind. How did he overcome this issue? Or are we waiting for a lawsuit to strike as soon as the plugin becomes usable?

The creator of the project trained a chimpansee to understand code, a literal code-monkey if you will or rather a code-ape to be more accurate. This code-ape then reads the Flash documentation and explains it with sign language to the project creator. Since the code-ape cannot be properly held to an NDA the project continues unencumbered by draconian laws or demonic contracts.

Re:Solution

[Anonymous Coward]

If you had ever used Gnash you would know the code-ape is the one writing the code as well. This makes it fall short of clean-room implementation.

Re:Solution

[assertation]

You forget that Europe is about to extend basic human rights to the great apes.

Well, I did manage to compile it

[Anonymous Coward]

After installing a few packages, it compiled easily on Arch Linux, but it mostly failed the test SWF they asked me to use:
http://www.adobe.com/devnet/flash/samples/drawing_1/1_coordinates.swf

The background is white instead of blue, and I can't drag the little widget around.

I ran one more test before giving up:
-- Homestar Runner SWF "DNA Evidence" - Lightspark doesn't even open a window to try and play it. :/

Good try, but I think Gnash can at least play the Homestar cartoons, although with some small graphical artifacts.

No Windows?

[Anonymous Coward]

I would gladly run this instead of adobe flash if it ran on windows. Flash is the kind of thing I use lightly enough that I wouldn't mind reporting bugs and trying to help out that way.

x86 biased project

[pinkishpunk]

Lightspark is using a Jit(just in time) compiler framework that as it stands right now is x86 only, there will go a long time before this project can help those that adobe doesnt support with their flash player. Those using Powerpc, arm are still without any working flash implementation, can only hope it will support those at a later stage, but I am rather pesemistic.

Re:x86 biased project

[loufoque]

That's just silly. It should have used LLVM.

A few bugs in that list!

[Anonymous Coward]

emacs - based on TECO, yes proprietary to MIT, but modified by damned near everyone
perl - borrows strongly from C, AWK, sh, grep, and RPG - all proprietary at one time or other
decss - reverse engineering of a proprietary algorithm
eclipse - began life as a proprietary IBM product Visual Age

need I continue?

Fuck Off

[seanonymous]

The best thing about Flash, from a programming perspective, is that you don't have to write in a bunch of special cases for different platforms like you do when writing HTML/CSS/JS for IE/Mozilla/WebKit.

If this project catches on, it better be perfect or I'll be one of many writing a sniffer to block my apps from running on it.

Also, the 'Flash is buggy' stuff needs to stop. It makes you sound ignorant. Flash is a runtime. People can write wonderfully stable, efficient code in ActionScript or they can take down the whole process, just like they can in Java, C++, Objective C, or whatever. If flash wan't around, advertisers would hire the same half-wits to write banner ads in Java or JavaScript and your CPU fan would spin just as fast. (This is why you need adblock.)

Re:Fuck Off

[Anonymous Coward]

Hey retard: Adobe's Flash runtime is buggy.

Re:Fuck Off

[TheDugong]

A closed source non-standard is better at cross platform than closed and open source implementations of standards.

What is the world coming to?

Re:Fuck Off

[Anonymous Coward]

> A closed source non-standard is better at cross platform than closed and open source implementations of standards.

The keyword here is closed.

"Closed and open" standards can make an unusable mess. Only pure free/open standards can be really trusted.

IMHO, it's possible -- and many monopolies thrive on that -- to make a closed environment perform better that apps on a mix of open and closed standards.

Re:Fuck Off

[ConceptJunkie]

Also, the 'Flash is buggy' stuff needs to stop. It makes you sound ignorant.

No, it makes you sound like a Linux user where Flash _is_ buggy and hideously slow.

I have no problems with Flash on Windows.

Re:Fuck Off

[seanonymous]

I would think by now a Linux user would be used to ports from Windows being less reliable or capable than their Windows counterparts. (Or not existing at all.)

If every program out there isn't buggy to some extent, why do we keep getting all these annoying updates?

Clearly Linux is buggy: http://www.ubuntu.com/usn

Needs a windows version

[Dwedit]

Flash Player is a bloated slow pig of a program. Windows users need a Flash Player alternative just as much as Linux users do.

So when I hear about a release, I look for the Standalone EXE player, which unfortunately doesn't exist.

I also wonder how this compares to Gnash. I've tested out Gnash, and it crashed on several SWF files I played through the program on Windows. Gnash also obviously wasn't designed at all to run on Windows, since it is missing the essential feature of Drag-Drop files onto the standalone player window.

Open-source DRM? WTF?

[GameboyRMH]

How can open source DRM work? DRM relies on the source being closed to slow attempts to reverse-engineer it. Open-source DRM could be cracked in minutes.

Re:Apple's Browser engine?

[mrawhimskell]

Heck, their biggest competitor in their fastest-growing market is basing their entire web experience on Apple's browser engine, so it doesn't seem like Apple is too worried about competition there.

Let's not forget webkit's roots - KHTML - which they took and improved upon. Let's not be too cheeky in calling it Apple's browser engine. The opensource licence requires them to use, improve and release the source so others can do the same. many unsung heroes/companies have been doing that for ages. The fact that Apple did it to the original KHTML source doesn't doesn't make the derived product their own. Someone correct me if I'm wrong.

Does it support FV? No.

[crow]

I just tried it, and the plugin is just grey for Mafia Wars and Farmville.