Actually, Flash content can be completely 508-compliant... *if* designed properly.
Keyboard Nav and ScreenReader compatibility is present; it has to be factored into your Flash design work (just as with any other development environment)
It will be slow starting up and after a page is loaded, it can execute very quickly
Don't rush to judgement on this without looking at the code. One of the design criteria for the JIT was to avoid this problem. Flash Player 9 (which uses this VM) can load and start executing jitted code very quickly. (Is "jitted" a real word?)
Plus, I'll bet that the JIT will be x86-32bit, Windows-only, meaning that on all other platforms, all you get is a much large JS engine than includes a VM.
The JIT is currently x86-32 for Windows and MacOSX, plus PPC-32 for MacOSX. There is also a prototype ARM implementation. x86-32 for Linux is functional but has not yet been merged into the CVS tree. x86-64 (Windows + Mac + Linux) is under development.
The downside is that lua currently beats the crap out of it when it comes to performance. The new JIT VM from adobe should reverse this tendency (at least regarding speed, maybe not regarding memory footprint).
Some speed benchmarks of Tamarin vs. Spidermonkey are here.
Some additional benchmarks of Flash Player 9 (which is essentially identical to Tamarin in this context) vs SpiderMonkey can be found here.
Multithreading isn't on the table, but the ECMAScript 4 proposal (which will eventually be implemented in Tamarin) does include generators and iterators, which is a nice partial step to some easier coding techniques:
"According to the official Penguin.SWF blog, the a beta release of the long-awaited Flash 9 for Linux is available for download, a mere year after the release for Windows."
What about 64bit? There is no Windows 64bit or OS X 64bit version either right now. As I said before it is not a question of 'recompiling' the source code, there is lots of generic non platform specific work which needs to be finished first. We will ship a 64bit version for Windows, OS X Leopard and GNU/Linux. It will happen. When?... When it is ready.
Distribution are *integrators*, they can't just ship everything unmodified (they'd all be the same otherwise).
I guess that just isn't The Linux Way, but as an app developer, that would be a feature, not a bug.
Saying "I am developing for Linux" really seems to mean "I am developing for a few dozen similar-but-not-identical operating systems", and if you are unwilling to ship source, life is WAY harder than it needs to be.
Yeahyeahyeah, shipping binary-without-source is Evil And Wrong and I'm probably going to Hell for it...
Can you imagine how life would be for distros if GNOME decided it doesn't get called GNOME unless it's the official GNOME release (no modifications)?
Yes, I can imagine it.
It would fucking ROCK.
Being able to assume that "GNOME 2.10" really is "GNOME 2.10" everywhere, and not "GNOME 2.10 plus some stuff that I thought might cool and without the stuff I thought I didn't need"... well, it would make life a lot simpler for app developers.
If Debian is as "totally free" as they claim, then presumably I could make my own distro and call it "Debian" too. (Or, hell, I could make a TOTALLY UNRELATED piece of software and call it "Debian"... the name is free, right?)
Slashdot Mirror
64-bit Macromedia Flash for linux isn't out yet
64-bit Adobe (RIP, "Macromedia") Flash isn't out for any platform yet.
But they're working on it.
Actually, Flash content can be completely 508-compliant... *if* designed properly.
h 8/faq.html
Keyboard Nav and ScreenReader compatibility is present; it has to be factored into your Flash design work (just as with any other development environment)
http://www.adobe.com/resources/accessibility/flas
If you don't know what Discrete Math is, you have no valid voice in this conversation.
What javaScript needs is optional strong typing and name spaces.
It's getting that, and a bunch of other cool stuff, in the ECMAScript 4 version that Tamarin will implement.
To see the current working proposals for ECMA for, go here: http://developer.mozilla.org/es4/
It will be slow starting up and after a page is loaded, it can execute very quickly
Don't rush to judgement on this without looking at the code. One of the design criteria for the JIT was to avoid this problem. Flash Player 9 (which uses this VM) can load and start executing jitted code very quickly. (Is "jitted" a real word?)
Plus, I'll bet that the JIT will be x86-32bit, Windows-only, meaning that on all other platforms, all you get is a much large JS engine than includes a VM.
The JIT is currently x86-32 for Windows and MacOSX, plus PPC-32 for MacOSX. There is also a prototype ARM implementation. x86-32 for Linux is functional but has not yet been merged into the CVS tree. x86-64 (Windows + Mac + Linux) is under development.
The downside is that lua currently beats the crap out of it when it comes to performance. The new JIT VM from adobe should reverse this tendency (at least regarding speed, maybe not regarding memory footprint).
Some speed benchmarks of Tamarin vs. Spidermonkey are here.
Some additional benchmarks of Flash Player 9 (which is essentially identical to Tamarin in this context) vs SpiderMonkey can be found here.
Comments from the Adobe engineers on 64-bit player work:
s o_difficult_64bit_editi.htmlf or-linux-beta-1.html
http://blogs.adobe.com/penguin.swf/2006/10/whats_
http://www.kaourantin.net/2006/10/flash-player-9-
Multithreading isn't on the table, but the ECMAScript 4 proposal (which will eventually be implemented in Tamarin) does include generators and iterators, which is a nice partial step to some easier coding techniques:
o rs_and_generators.html
http://developer.mozilla.org/es4/proposals/iterat
Well, it *used* to stand for ActionscriptByteCode.
Now, I think it just stands for... um... ABC.
(Maybe if they had chosen a monkey with a name starting with "A", the acronyms would have been more meaningful...)
Perhaps you should look at the code before calling it bloated.
Or maybe it's a mutant dolphin that is developing extra new sets of fins...
so they can RETURN TO LAND...
Point taken... but it's the original poster making the inaccurate comparison, not me:
the beta release of the long-awaited Flash 9 for Linux is available for download, a mere year after the release for Windows
Those are the sort of useful and intelligent bug reports that the team LOVES to see; please report them.
(But please don't report "I want 64-bit" as a bug. We already know. We're already working on it.)
From the /. headline:
"According to the official Penguin.SWF blog, the a beta release of the long-awaited Flash 9 for Linux is available for download, a mere year after the release for Windows."
From Tinic Uro's blog:
f or-linux-beta-1.html
... When it is ready.
http://www.kaourantin.net/2006/10/flash-player-9-
What about 64bit? There is no Windows 64bit or OS X 64bit version either right now. As I said before it is not a question of 'recompiling' the source code, there is lots of generic non platform specific work which needs to be finished first. We will ship a 64bit version for Windows, OS X Leopard and GNU/Linux. It will happen. When?
Flash Player 9 for Windows was officially released on June 28, 2006.
4 months != 1 year
Wow, modded down to zero... that sucks, dude.
For the record, I completely agree with you. (Which will probably get me modded down too.)
A single tookit (or at least a single well-defined API) would do wonders for app development.
You are mistaken.
h tml#faq-34.3
See http://www.parashift.com/c++-faq-lite/containers.
You forgot:
o CowboyNeal did it
(Repeating for benefit of the excellent comment posting as AC)
This one always tickles me: &array[0].
But that's the best way to use a std::vector as smart array.
Distribution are *integrators*, they can't just ship everything unmodified (they'd all be the same otherwise).
I guess that just isn't The Linux Way, but as an app developer, that would be a feature, not a bug.
Saying "I am developing for Linux" really seems to mean "I am developing for a few dozen similar-but-not-identical operating systems", and if you are unwilling to ship source, life is WAY harder than it needs to be.
Yeahyeahyeah, shipping binary-without-source is Evil And Wrong and I'm probably going to Hell for it...
the Debian logo is non-free though, and this is considered a bug by the way
Mr. Kettle? Meet Mr. Pot.
Mr. Pot, meet Mr. Kettle.
My, how dark you both are.
Can you imagine how life would be for distros if GNOME decided it doesn't get called GNOME unless it's the official GNOME release (no modifications)?
Yes, I can imagine it.
It would fucking ROCK.
Being able to assume that "GNOME 2.10" really is "GNOME 2.10" everywhere, and not "GNOME 2.10 plus some stuff that I thought might cool and without the stuff I thought I didn't need"... well, it would make life a lot simpler for app developers.
If Debian is as "totally free" as they claim, then presumably I could make my own distro and call it "Debian" too. (Or, hell, I could make a TOTALLY UNRELATED piece of software and call it "Debian"... the name is free, right?)