After my last post was dugg (765 diggs) and after reading my blog's and diggers' comments, I feel I need to make some clarifications about the matter.
I'm not questioning the fact Adobe didn't compile it yet whatever reason is. To me they can even never compile it to amd64 or PPC for what matters. I'm questioning the lack of _clear_information_ from them about _when_ (because they'll be armtwisted by market forces to do it sooner or later) if ever. A timeframe would be nice, but more than ten months of silence about the progress (or lack thereof) of this port and ignoring recurrent complains from people is just disrespectful to us "consumers". A "No, we'll not port it to amd64, so move along, nothing to see there" statement would suffice, and we would have a clear message to motivate us to really _move_along_ and _do_something_ instead of wait the G*d's mana fall from Heavens. The current situation is different from to the one of XFree86's before the fork (diva programmers' overfilled-egos preventing a faster development of the de-facto X implmententation to maintain their own status quo - the change to the license just confirms it), but the result is the same: stagnant progress preventing people from doing something to get out of the "comfort zone", as people settle for "good enough".
Let me make clear and say 32bit Flash didn't prevent me from running a 64bit operating system. I know the cumbersome nspluginwrapper trick, but it's a sub-optimal situation, prone to crashes, performance killer (processor context changes), memory hungry (need to load tens of MB of 32bit compatibility layer just to check YouTube) and bloated (need to have 32bit compatibility layer installed in my machines). A PowerPC or z390 user can run Win98 on Bochs and enjoy Flash content. An amd64 user can choose to run a 32bit OS and lose the overall speed gain (around 30% in my tests encoding audio files) from additional 64bit registers and other niceties. The sad thing is people are resorting to such measures and subjecting themselves to it to be able to see content because of vendor lock-in.
The current Flash vendor lock-in is way more dangerous than O.S. lock-in or www browser lock-in, because it's so pervasive people don't seem to think about it. The present state of rich media internet is not reflected by W3C, ISO, ECMA (yes, I'm aware of ECMAScript), IETF or whatever regulatory/standards body of my knowledge, leaving us in a void not filled by the SVG spec or any of its implementations, having as only resort Adobe's Flash. And it makes business sense in short term, as almost every Mom 'N Pop's Store, Nvidia, AMD/ATi, Intel, ASUS, Google, Sun and even Microsoft use Flash to generate and display rich media. In medium and long terms it's another story, because the decomoditization of the world wide web will make the www browser less and less relevant as long as it serves as a shell to run Flash content.
Some initiatives are being done to level up the fight, as the sight of Silverlight cast new shadows on the tubes. Some people have the power to do something to change this situation, but let's number some of the outcomes:
1. Adobe updates Flash to retain market share and avoid dissent. Very unlikely based on current behavior.
2. Adobe's corporate heart is touched and they release a free, unencumbered specification just like they did with PDF, submitting it to evaluation by a standards body. And We The Coders(tm) implement it while Adobe maintains its stronghold with the creative tools. Acceptable.
3. Adobe ignores the Vocal Minority(tm) while Gnash and SwfDec try to catch on. Or, more precisely, the current situation.
4. Microsoft does to Silverlight what Adobe should have done to Flash in item 2, but with MS's track record of openness and transparency we may expect something like OOXML in the end.
5. Moonlight does to Silverlight what Gnash does to Flash, only spending 27MB of memory for a 160x100 "CLICK HERE!! NOW!!!" seizure-inducing banner. Tastes like moonshine.
6. Sun makes a rich media content creation suite with files playable via its Java plugin. Interesting.
7. Somebody else makes a rich media content creation suite with files playable via Sun's Java plugin. Less interesting.
8. Some regulatory/standards body starts to think about it and something shows up in at least ten years from now. Bringing a full-fledged implementation as useful as Amaya.
9. _We_ F/OSS people do something, organize a group, start a project and code, just like Xiph.Org Foundation has done with Vorbis, Theora, FLAC, Speex, Ogg and others.
10. Somebody hires me to put up or shut up. :D
The 2nd outcome is not out from ignorance: Tamarin's ECMAScript v4 Virtual Machine is slowly but steadily being adjusted to be able to compile in 64bit environments. But Tamarin/ECMAScript it is not the SWF and FLV File Format Specification as defined by Adobe, and the license agreement states in clause 3.a. "You may not use the Specification in any way to create or develop a runtime, client, player, executable or other program that reads or renders SWF files.". I'm not able to compare both so I will not be tainted by Adobe's license, but I'd like to know I'm wrong and both are the same thing, making Adobe's license a moot statement. A word from Tinic Uro or Mike Melanson about it would be very enlightening and drive some F/OSS developers in to it (me probably included).
Gnash, SwfDec, Moonlight, Wine and others help the Free/Open Source Movement to conform to the present but not to shape the future. Backward compatibility and being able to handle current formats are important to assure the recoverability of our data, but if we want to warrant our freedom for the coming years, we need to do something _now_, with or without Adobe's help. If Gnash, SwfDec, Plasma (hi, Aaron) and others join forces do develop a common specification for rich media content (or expand the Dynamic SVG spec to meet the demmand) and implement it at library level, allowing the creation of platform-independent web plugins, stand-alone players, embedded parts, desktop gadgets, creative media suites and other yet-to-be-seen applications, then we'll be really shaping the future.
No comments:
Post a Comment