Flash For Linux Will Only Be Available For Chrome(blogs.adobe.com)
blogs.adobe.com
Flash For Linux Will Only Be Available For Chrome
http://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html
39 comments
There are over 70 patents and licensed libraries in Flash. It would basically be impossible to get those companies to agree to open source and give away all their IP. For a while, Adobe was paying over a dollar per Android Flash install because some of their licenses only applied to desktop.
So one might say they should open source the core of Flash, the JIT compiler and virtual machine, and not the parts that are licensed. And you're right, that would be the correct move! They did that in 2006: http://en.wikipedia.org/wiki/Tamarin_%28software%29
They also open sourced the Flex SDK: http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK
What Adobe needs is a completely new product that is available to consumers for free, has it's source code public and free from patents. This way, Adobe tools can still be sold and used to develop, while the player is ubiquitous and as widely spread as possible. And that's what they're trying to do with HTML5: http://www.adobe.com/solutions/html5.html
Adobe's communication to developers is bad. No one knows about any this. Technology isn't their problem, marketing is.
So one might say they should open source the core of Flash, the JIT compiler and virtual machine, and not the parts that are licensed. And you're right, that would be the correct move! They did that in 2006: http://en.wikipedia.org/wiki/Tamarin_%28software%29
They also open sourced the Flex SDK: http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK
What Adobe needs is a completely new product that is available to consumers for free, has it's source code public and free from patents. This way, Adobe tools can still be sold and used to develop, while the player is ubiquitous and as widely spread as possible. And that's what they're trying to do with HTML5: http://www.adobe.com/solutions/html5.html
Adobe's communication to developers is bad. No one knows about any this. Technology isn't their problem, marketing is.
Exactly! Does anyone remember this: http://www.adobe.com/devnet/html5/articles/css-shaders.html
Exactly, http://osmf.org anyone?
EDIT: Make link a link :-)
EDIT: Make link a link :-)
If you visit the http://crash-stats.mozilla.org site, you may have noticed the obfuscated Flash symbols starting with F followed by some random number.
...okay? What is your point?
Why do you think the symbols had to be obfuscated?
Why do you think I would be asking what your point is?
It could be hard coded into the browsers like javascript.
Like Shumway? https://github.com/mozilla/shumway
This is an effort to render SFW inside the browser.
This is an effort to render SFW inside the browser.
[deleted]
Indeed, this is long overdue and I've been making this argument for years. Adobe has already lost a lot by keeping Flash Player closed and they only stand to lose more and more. This decision, for instance, will only promote HTML 5 adoption in lieu of Flash farther and farther. Adobe can still matter if they open-source Flash Player right now, but as you noted, the sweet spot is closing rapidly.
The fact of the matter is that if Flash had opened itself up earlier, there wouldn't even be an HTML 5 Canvas/WebGL as we know it, people just would have used and extended Flash and Adobe would still be making bank on their commercial IDE for the environment. Now Adobe's dominance is threatened and Flash is universally despised.
Adobe is obviously terrible at maintaining the runtime so I think the only logical explanation for their lack of OSS Flash Player is that they have some very prehistoric business guys somewhere along the way that don't understand open-source at all and choke this off in terror every time it gets mentioned.
The fact of the matter is that if Flash had opened itself up earlier, there wouldn't even be an HTML 5 Canvas/WebGL as we know it, people just would have used and extended Flash and Adobe would still be making bank on their commercial IDE for the environment. Now Adobe's dominance is threatened and Flash is universally despised.
Adobe is obviously terrible at maintaining the runtime so I think the only logical explanation for their lack of OSS Flash Player is that they have some very prehistoric business guys somewhere along the way that don't understand open-source at all and choke this off in terror every time it gets mentioned.
That's a rather naive way of looking at it. The name - Flash Player - is deceptive. Player is what users see and what it appears to be doing, but in reality it is much more than that. It is a content delivery system, and the Player is an essential part of it that is expected to play by the rules - DRM, collaborative p2p delivery, licensing, etc. 10% (maybe) of the player is about playback, the rest is what users don't really see, but what is of a huge value to Adobe. Guess what will be stripped off the second the player open sourced? Why would Adobe want that.
For everyone I know Flash amounts to YouTube, Ustream, some other video sites, and some web games.
Streaming video will work just fine with HTML5 or just an old fashioned browser video plugin. A lot of the Flash web games will be missed, but my sense is that the vast majority of those people are using Windows and Mac.
The day is coming when very few new projects will be started in Flash and it will go the way of Silverlight.
Streaming video will work just fine with HTML5 or just an old fashioned browser video plugin. A lot of the Flash web games will be missed, but my sense is that the vast majority of those people are using Windows and Mac.
The day is coming when very few new projects will be started in Flash and it will go the way of Silverlight.
I've been wondering why they haven't done this for a very, very long time. The player itself has not been a source of revenue for Adobe for quite some time (they used to license Flash Lite to handset manufacturers and made money off of that), instead they make all their money by selling tools to make content for that runtime. I'm hoping someone from Adobe is reading this, because I've never really heard a rational business reason for why the Player is not open source.
So here are my questions for Adobe:
Is there still income from Flash Player licensing? If not, how does keeping the Player closed source help your business interests?
Is it the client side DRM you have in place in the Player that's stopping you from making it open source?
Do you not have the resources to communicate with the community that would develop around an open sourced player (knowing that you would have spend some time to justify many things that exist in the codebase to maintain backwards compatibility)?
Are you concerned that a rival would clone some of the technology you developed and implement it in their proprietary player (e.g. MS, but they already gave up on Silverlight)?
Would the sudden influx of new security patches as vulnerabilities are discovered and fixed potentially compromise the performance of the Player?
Are you worried that individuals with malicious intent will find new vulnerabilities and exploit them?
What are your other concerns that are preventing you from open sourcing the Flash Player?
So here are my questions for Adobe:
Is there still income from Flash Player licensing? If not, how does keeping the Player closed source help your business interests?
Is it the client side DRM you have in place in the Player that's stopping you from making it open source?
Do you not have the resources to communicate with the community that would develop around an open sourced player (knowing that you would have spend some time to justify many things that exist in the codebase to maintain backwards compatibility)?
Are you concerned that a rival would clone some of the technology you developed and implement it in their proprietary player (e.g. MS, but they already gave up on Silverlight)?
Would the sudden influx of new security patches as vulnerabilities are discovered and fixed potentially compromise the performance of the Player?
Are you worried that individuals with malicious intent will find new vulnerabilities and exploit them?
What are your other concerns that are preventing you from open sourcing the Flash Player?
>The player itself has not been a source of revenue for Adobe for quite some time
Google pays lots of money for Adobe to auto opt-in Flash installs with Chrome.
Google pays lots of money for Adobe to auto opt-in Flash installs with Chrome.
I was not aware of that. Do you have any details on that arrangement? I don't see any record of that in any of their earning reports for the last two years.
My understanding of that arrangement is that it is a mutually beneficial relationship that guarantees that Chrome users have the latest version of Flash (and Chrome is thus more secure) and the Flash Player update adoption happens faster. It makes very little sense to me that Google would pay Adobe for that since Adobe benefits just as much as Google.
My understanding of that arrangement is that it is a mutually beneficial relationship that guarantees that Chrome users have the latest version of Flash (and Chrome is thus more secure) and the Flash Player update adoption happens faster. It makes very little sense to me that Google would pay Adobe for that since Adobe benefits just as much as Google.
Last I checked, Adobe had a deal with Google where when the user installs Flash for Firefox or Opera on Windows, Adobe also installs Chrome by default, in addition to Flash itself, unless the user opts out.
Now how much money this brings in, who knows.
Note that this is NOT the same as Flash being bundled with Chrome. This is Chrome being bundled with Flash.
Now how much money this brings in, who knows.
Note that this is NOT the same as Flash being bundled with Chrome. This is Chrome being bundled with Flash.
To responders: yes, I agree that DRM and patents are a big problem for this. I don't have an answer to that..
I agree they would probably benefit from open sourcing it. However I don't think they can. In order to "fully open source" it, they would have to include an open source H264/mp4 decoder. Which would probably not be allowed by everyone who owns H264. Alas.
You are confusing licensing of code and patents. You can have an implementation that is Open Source. The problem is licensing the patents and eventually having that license trickle down to "sublicensee". Usually this does not work.
So technically the code is Open Source but each distributor must get a patent license... that is restricted to redistributing binary form only.
(I deliberately did avoid the use of the word Free Software, as this actually might not be true if the code is licensed under the Free Software license GPL).
So technically the code is Open Source but each distributor must get a patent license... that is restricted to redistributing binary form only.
(I deliberately did avoid the use of the word Free Software, as this actually might not be true if the code is licensed under the Free Software license GPL).
You are right that you might be able to claim "open source" while still requiring a patent licence under the letter of the 'open source'. However that would definitly go against the spirit of "open source" and it would not be viewed by anyone as actually open source at all.
"Free Software" vs "Open Source" would not be relevant here, since both FS and OS would view this "you-still-need-a-patent-licence" clause as incompatible with FS & OS.
There are a few bits in the new GPLv3 that say "if you release under GPLv3 then you have to give everyone a patent licence". However I don't know how that works if you don't have a full patent licence…
"Free Software" vs "Open Source" would not be relevant here, since both FS and OS would view this "you-still-need-a-patent-licence" clause as incompatible with FS & OS.
There are a few bits in the new GPLv3 that say "if you release under GPLv3 then you have to give everyone a patent licence". However I don't know how that works if you don't have a full patent licence…
> In order to "fully open source" it, they would have to include an open source H264/mp4 decoder. Which would probably not be allowed by everyone who owns H264. Alas.
There are existing open source implementations of H264. Even the best encoder (x264) is open source. But I guess there are license issues with third party code/libraries used in Flash.
There are existing open source implementations of H264. Even the best encoder (x264) is open source. But I guess there are license issues with third party code/libraries used in Flash.
Yes there are H264 software that is released under an open source copyright licence. However the implementation might still be breech patents and might still be illegal to use.
It's a shame that a complete clean room open source implementation (e.g. x264) might still be illegal to use in some territories.
It's a shame that a complete clean room open source implementation (e.g. x264) might still be illegal to use in some territories.
That's just the question of having a license. Not whether the implementation is open source.
> they are losing interest in maintaining Flash, so opening it to the community would seem to make some sense
Sounds like what Oracle did with OpenOffice.org. Dumping it on the Apache Foundation and all that.
Sounds like what Oracle did with OpenOffice.org. Dumping it on the Apache Foundation and all that.
The part I'm not yet getting about Pepper - does it only support those native client objects as described here? https://developers.google.com/native-client/overview
Or do plugins like flash have the choice between native client and just using a shared library as they did and Pepper also supports that?
In the first case it would basically mean that flash would run sandboxed (and maybe on every system supported by Pepper, so once ARM support is added it could run there as well again). But probably with some speed-hit (~5% according to the documentation)
Or do plugins like flash have the choice between native client and just using a shared library as they did and Pepper also supports that?
In the first case it would basically mean that flash would run sandboxed (and maybe on every system supported by Pepper, so once ARM support is added it could run there as well again). But probably with some speed-hit (~5% according to the documentation)
We use Pepper to sandbox some fully native plugins, where NaCl is not yet a good option due to things like codebase incompatibilities and startup performance. Two examples of this are the native PDF reader (on all platforms) and Flash on Chrome OS.
NaCL would probably have been mentioned if it was involved. I think Chrome can still do less fine-grained, OS-assisted sandboxing, and Flash on Pepper is cooperating with that.
Why is there so much noise over this? How many times does Flash have to die? Yes, the Flash plugin will be with us for another decade, but shouldn't most of us have moved on? I uninstalled Flash on my two Macs in December. I'm doing fine so far. Sometimes, I need to switch over to Chrome for video, but so far I'm not missing it.
I have relatives on Linux and this will complicate things for me. Basically I have to install Chrome and explain why videos and other stuff work only on Chrome. However, it is the way I prefer it by now anyway: use a Firefox without Flash for daily browsing and Chrome for Flash things.
Don't underestimate how complicated it might be to explain this to "noobs", though.
Don't underestimate how complicated it might be to explain this to "noobs", though.
> Basically I have to install Chrome and explain why videos
> and other stuff work only on Chrome.
Starting 5 years from now, when Adobe actually drops support for Flash on Linux, right?
We'll see how much video and other stuff still requires Flash in 5 years. With any luck, not much.
Starting 5 years from now, when Adobe actually drops support for Flash on Linux, right?
We'll see how much video and other stuff still requires Flash in 5 years. With any luck, not much.
Missed the timeline. In five years, Flash should be gone for good.
This comes at a fine time--I've not been using flash at all. The only site that I regularly used flash for in the past was YouTube, and then only for some videos (the ones with ads). The open source Gnash plugin can play YouTube videos that require flash (it's useless for almost everything else--it can't even play YouTube's ads :P). All the videos that work with HTML5 are better that way. (In a pinch, Gnash would work there too.)
So really, the only things I'm missing are flash games I don't play and ads I don't watch. (Some flash games actually sort of work, but it's not dependable.)
So really, the only things I'm missing are flash games I don't play and ads I don't watch. (Some flash games actually sort of work, but it's not dependable.)
Didn't Google actually allow you to watch Youtube videos with HTML5 instead of flash?
Not the ones with ads.
I can watch every single YouTube video. I recently did a fresh install of OS X and have not yet bothered to install Flash (it's no longer installed by default). Every single YouTube video I want to play I can play. Those that used to have ads no longer have them.
The only YouTube videos I occasionally can't watch are the embedded ones. Clicking through to the YouTube page, however, solves that problem.
The only YouTube videos I occasionally can't watch are the embedded ones. Clicking through to the YouTube page, however, solves that problem.
To my fellow developers, please don't develop anything else for Flash. Thanks! (Within the next year Google will have you go full screen in GTK inside Chrome/Debian ... then that's your desktop ... Adobe is hedging this decent bet .... BARF!)
> Within the next year Google will have you go full screen in GTK inside Chrome/Debian ... then that's your desktop
Source? Or is that just conjecture?
Source? Or is that just conjecture?
The one thing where Flash is still apparently unavoidable is something like tinychat.com (or chatroulette) which does web-based videoconferencing. The last time I checked, it isn't possible to replicate that without Flash.
WebRTC <http://www.webrtc.org/>; development is ongoing between Google, Mozilla, and Opera. You can try it out in the latest Chrome canary/dev channel.
Good riddance. Flash has never been anything but trouble for Linux. It consumes huge amount of power on Linux and they are not inclined to fix it. Hopefully we will see better HTML5 support in future.
All I see lately is that Flash is becoming less and less relevant. It's not on iOS; I purposefully didn't install it on my latest Android devices.
Is it really Chrome or is it the new "pepper" plugin API driving this?
ie. if other browsers decide to support the new plugin API, will Adobe also support them too?
ie. if other browsers decide to support the new plugin API, will Adobe also support them too?
The API was developed jointly by Adobe and Chrome, so its not Chrome or the API causing it, it's both parties wanting a better solution. It makes it cheaper for Adobe to support more platforms with less development hours.
Adobe has stated (not in any press releases, but from the mouth of employees) that they will work with any other browser wanting to implement the same API.
Adobe has stated (not in any press releases, but from the mouth of employees) that they will work with any other browser wanting to implement the same API.
Now it is time that Google do the right thing and drop Flash, as well as hold their over a year-old promise to drop H264 in Chrome.
Not holding my breath though.
Not holding my breath though.
Anyone else shocked to see that they were still using a "Netscape plugin API"? How many years old is that?
Flash player is the worst CPU hog in my Linux and Mac computers. But, could we live without it? I doubt.
[deleted]
That's good. In Chrome, when Flash crashes, it only takes out a couple of tabs.
I laughed out loud — shocking how different Adobe’s headline and the HN submission title are!
"Adobe and Google Partnering for Flash Player on Linux" — zzZZZ, good for them
"Flash For Linux Will Only Be Available For Chrome" — Holy balls, Flash is really dying, isn’t it?
"Adobe and Google Partnering for Flash Player on Linux" — zzZZZ, good for them
"Flash For Linux Will Only Be Available For Chrome" — Holy balls, Flash is really dying, isn’t it?
Works for me.
I'm surprised that everyone seem to think that this is some sort of exclusive Chrome thing. I'm willing to bet that this is more from Adobe's inability to understand how to do auto-updates correctly and the fact that Chrome is the only browser to support Pepper.
Adobe gets free auto-updates and there is no hassle or extra steps for users, since there is only one way for them to effectively use it. I'm sure if Firefox were to support Pepper that they would make it available in a PPA or something.
Adobe gets free auto-updates and there is no hassle or extra steps for users, since there is only one way for them to effectively use it. I'm sure if Firefox were to support Pepper that they would make it available in a PPA or something.
Sorry, didn't mean to detract from the Google haterade.
Btw, really? Downvote me but you've got nothing to say?
To weigh in on the pro flash side: say you're developing applications for large enterprises, many of which still run ie7 or 8 (mind you, not websites, but applications that run in a browser and are delivered over the Internet). Since HTML5 (by which, none of you actually mean html5 in that case, it's mostly some kind of JavaScript front end with frameworks far from mature (though I like both backbone and ember/sproutcore, they've got a ways to go before being comparable to flex w/ robot legs, and js will never be as3)) will not work well in this situation, what do you propose?
For Adobe's part, I wish they'd be a bit more transparent, but regardless, I think I'm good to go with a pretty wide and stable cross-browser feature set today and will be that way for a while while JS frameworks play catch up. And meanwhile, good luck getting an IT dept at a fortune 500 to upgrade all their browsers to the latest version of firefox or chrome and to make that a requirement to use your software. And what would you gain by doing that today exactly if that's your target market?
What can HTML5/JS do today for RIA's that flash can't do better, faster, and cheaper?
To weigh in on the pro flash side: say you're developing applications for large enterprises, many of which still run ie7 or 8 (mind you, not websites, but applications that run in a browser and are delivered over the Internet). Since HTML5 (by which, none of you actually mean html5 in that case, it's mostly some kind of JavaScript front end with frameworks far from mature (though I like both backbone and ember/sproutcore, they've got a ways to go before being comparable to flex w/ robot legs, and js will never be as3)) will not work well in this situation, what do you propose?
For Adobe's part, I wish they'd be a bit more transparent, but regardless, I think I'm good to go with a pretty wide and stable cross-browser feature set today and will be that way for a while while JS frameworks play catch up. And meanwhile, good luck getting an IT dept at a fortune 500 to upgrade all their browsers to the latest version of firefox or chrome and to make that a requirement to use your software. And what would you gain by doing that today exactly if that's your target market?
What can HTML5/JS do today for RIA's that flash can't do better, faster, and cheaper?
Correct me if I'm wrong, but it looks like other browsers are free to implement the "pepper" API as well. It seems as though they are not saying "we're only supporting Chrome". They are saying "Chrome is the only browser that has implemented Pepper so far, and we're only supporting Pepper on Linux".
Except that other browser users won't be able to acquire Flash Player without installing Chrome:
the Flash Player browser plugin for Linux will only be available via the “Pepper” API as part of the Google Chrome browser distribution and will no longer be available as a direct download from Adobe
the Flash Player browser plugin for Linux will only be available via the “Pepper” API as part of the Google Chrome browser distribution and will no longer be available as a direct download from Adobe
And again, couldn't Firefox at least theoretically implement this part of the API? Would it just be a legal issue?
The announcement says:
> Because of this work, Adobe has been able to partner with Google in providing a “Pepper” implementation of Flash Player for all x86/64 platforms supported by the Google Chrome browser. Google will begin distributing this new Pepper-based Flash Player as part of Chrome on all platforms, including Linux, later this year.
It says that the plug-in will be bundled with Chrome, and Adobe have said they won't be releasing more Flash players for Linux, but the announcement does not even hint whether a stand-alone Pepper plug-in will be available from Google. I hope the Chromium blog will clarify this in due course.
I guess Adobe might forbid Google from developing a plug-in, but I don't see why they would want that, seeing as they have been distributing plug-ins for years. If Google could but didn't, that would make them look unsupportive of Chromium.
> Because of this work, Adobe has been able to partner with Google in providing a “Pepper” implementation of Flash Player for all x86/64 platforms supported by the Google Chrome browser. Google will begin distributing this new Pepper-based Flash Player as part of Chrome on all platforms, including Linux, later this year.
It says that the plug-in will be bundled with Chrome, and Adobe have said they won't be releasing more Flash players for Linux, but the announcement does not even hint whether a stand-alone Pepper plug-in will be available from Google. I hope the Chromium blog will clarify this in due course.
I guess Adobe might forbid Google from developing a plug-in, but I don't see why they would want that, seeing as they have been distributing plug-ins for years. If Google could but didn't, that would make them look unsupportive of Chromium.
Think licensing.
If the Adobe blog post is correct and the pepper plugin is only distributed with Chrome and isn't open source and part of Chromium then how is another browser going to support it? They'd have to tell you to install Chrome and then open the plugin from within Chrome's installed directory. Pretty ugly solution. If it's open source and part of Chromium then they can at least take the source out and ship their own, assuming the licensing allows for that and is compatible with their license.
All in all, this sounds like a pretty complex scenario for non-Chrome browser.
If the Adobe blog post is correct and the pepper plugin is only distributed with Chrome and isn't open source and part of Chromium then how is another browser going to support it? They'd have to tell you to install Chrome and then open the plugin from within Chrome's installed directory. Pretty ugly solution. If it's open source and part of Chromium then they can at least take the source out and ship their own, assuming the licensing allows for that and is compatible with their license.
All in all, this sounds like a pretty complex scenario for non-Chrome browser.
I'm betting the distro packagers like Canonical will solve the problem for end users.
Meanwhile, Flash continues to circle the drain, and this might hasten its inevitable, but slow demise.
Meanwhile, Flash continues to circle the drain, and this might hasten its inevitable, but slow demise.
I'm betting the distro packagers like Canonical will solve the problem for end users.
They might simply shift to Chrome as their default browser.
They might simply shift to Chrome as their default browser.
Not Chrome, they can't it is not open source. They could switch to Chromium, which could presumably run flash, but it is not clear how you obtain it if only Chrome will distribute it. Presumably they will have to distribute it as they say they will ship security updates, but that is unclear, as Linux flash does not auto update from Adobe.
[deleted]
If I understand things correctly, there are actually two things going on:
1) Adobe is effectively stopping work on Flash for Linux on their end; it's just not worth it to them. 2) Google is going to support Flash for Linux for Chrome specifically. They can do this because they have access to Flash source and because the Pepper version of the plug-in is much more cross-platform than the NPAPI version, so the support effort is not too great. Given that they already ship a modified Flash, not the stock one, it's not that big a difference from what they're already doing.
So I think you're wrong; even if other browsers implemented the Pepper API, they would also need source licenses from Adobe or would be dependent on Google to get the Flash plug-in.
1) Adobe is effectively stopping work on Flash for Linux on their end; it's just not worth it to them. 2) Google is going to support Flash for Linux for Chrome specifically. They can do this because they have access to Flash source and because the Pepper version of the plug-in is much more cross-platform than the NPAPI version, so the support effort is not too great. Given that they already ship a modified Flash, not the stock one, it's not that big a difference from what they're already doing.
So I think you're wrong; even if other browsers implemented the Pepper API, they would also need source licenses from Adobe or would be dependent on Google to get the Flash plug-in.
In that case I realy hope to see this site change soon: https://wiki.mozilla.org/NPAPI:Pepper
Apple and Mozilla have already stated that Pepper is entirely redundant with ongoing standardization efforts and even counterproductive to them. So why is Google pushing it? Answer for yourself.
Apple's initial third-party app system in the iPhone was web-based.
While WebOS stuck with the open technologies, the next Apple phone introduced closed-source binary application as the main third party extension platform. If WebOS could make the open web technologies work as primary development method on a phone, why did Apple go back to the installable programs of the last century?
Google's Pepper is at least open standard with an open implementation, while I don't have any way to run iOS apps on any other platform than those tightly controlled by Apple themselves.
Strangely, we can look to Microsoft for providing an open standards HTML5 based version of an app like "Cut the Rope": http://www.cuttherope.ie/ -- imagine if iOS devices ran HTML5 apps well and this game (which sold 3 million copies on iOS!) was HTML5 from the start. You could run it on the iPhone or any Android device or your desktop right from the start.
While WebOS stuck with the open technologies, the next Apple phone introduced closed-source binary application as the main third party extension platform. If WebOS could make the open web technologies work as primary development method on a phone, why did Apple go back to the installable programs of the last century?
Google's Pepper is at least open standard with an open implementation, while I don't have any way to run iOS apps on any other platform than those tightly controlled by Apple themselves.
Strangely, we can look to Microsoft for providing an open standards HTML5 based version of an app like "Cut the Rope": http://www.cuttherope.ie/ -- imagine if iOS devices ran HTML5 apps well and this game (which sold 3 million copies on iOS!) was HTML5 from the start. You could run it on the iPhone or any Android device or your desktop right from the start.
I get the feeling this isn't going to be that much of a problem. I've not got the flash plugin installed in Firefox and I'm not finding any great hardship these days.
Perhaps it'll kill Flash a bit quicker considering the amount of Kiosks and Internet cafes running Firefox+Flash on Linux.
Perhaps it'll kill Flash a bit quicker considering the amount of Kiosks and Internet cafes running Firefox+Flash on Linux.
>I'm not finding any great hardship these days.
You must not watch many videos in your browsers then outside the odd one on Youtube. The reality out there is that Flash is still the main choice for delivering video. Flash is a necessary evil. It may be dying but for many it's still necessary and its removal from Firefox removes significant usability for its users.
You must not watch many videos in your browsers then outside the odd one on Youtube. The reality out there is that Flash is still the main choice for delivering video. Flash is a necessary evil. It may be dying but for many it's still necessary and its removal from Firefox removes significant usability for its users.
Not really. I prefer written words as the content is easier to scan through. Video is almost laborious watching.
I watch plenty of videos and I've never had a problem with the big streaming sites delivering h264 versions. The only flash videos I still encounter are on older, lightly, maintained sites or sites that just download flv files.
And if iPad sales are any indication I don't think it's as big a deal as you make it out to be.
And if iPad sales are any indication I don't think it's as big a deal as you make it out to be.
The iPad includes H264 support, as does Chrome. Firefox doesn't (and neither does Chromium, does it?). So this does screw anyone over who wants to watch H264, which really is the majority of video on the web.
nobody wany yo watch h264, they want to watch video, its up to the site to accomodate them
Yeah right, websites really care for the Linux user on Firefox and are willing to go to extra lengths to accommodate him.
People won't serve you HTML 5 video unless you impersonate a mobile device. It's still a problem if you don't want to change your user-agent every time you visit a website and just cross your fingers that they think you're mobile and therefore serve up HTML 5 (and as others have pointed out, often in a format that non-Chrome won't play anyway).
youtube.com/html5
Right, YT is one among a handful of exceptions that serve HTML 5 to a desktop browser. That doesn't really change the general argument -- almost all sites are not going to give HTML 5 video as an option to desktop clients.
I didn't realize anybody used other sites for video :)
They somewhat appear to want to: http://daringfireball.net/linked/2012/02/21/apple-google-col...
I don't think this is "Fuck Google" so much as it is "Fuck people uploading stuff through this interface."
If I write some software that costs $999 and only works on HP/UX, it's not "Fuck Microsoft" or "Fuck Apple". It's "Fuck me."
I think they call it cutting off your nose to spite your face.
If I write some software that costs $999 and only works on HP/UX, it's not "Fuck Microsoft" or "Fuck Apple". It's "Fuck me."
I think they call it cutting off your nose to spite your face.
I run ArchLinux, use Chrome, and have the flashplugin-prelease installed. This is version 10.0 of Flash. Because this plugin is out of date Chrome will disable flash on all websites I visited that use Flash. It would then show a little bar at the top indicating that my flash plugin is out of date and therefore disabled. If I wanted to run Flash anyway it gave me the option to run it for the current page. I noticed that I rarely ever want to run flash unless i'm specifically visiting a youtube link. I really think this "Run Flash for current page" functionality should be the default though. I like having the option of turning on flash only when i absolutely want it. If I just keep running the older versions of Flash I can continue getting this desired functionality.
There's no reason to run an out of date flash plugin. You can enable click-to-play for flash in the chrome settings. It's in the content settings area of the "under the hood" section I believe.
Click-to-play isn't friendly to music streaming services which use 1px flash player for their music.
Flashblock plugins are ridiculous by requiring you to blacklist or whitelist flash domain instead of web domain. The former happens to be on CDN and suddently you can't do it :(
Flashblock plugins are ridiculous by requiring you to blacklist or whitelist flash domain instead of web domain. The former happens to be on CDN and suddently you can't do it :(
Confirmed (for Chromium 7.0.963.56 on Arch, w/ up-to-date Flash)
The real reason it'll not be much of a problem is that the current Flash 11.2 plugins won't spontaneously disappear when the next version gets released. Indeed they'll have 5 more years of security updates.
So the only thing non-Chrome-using Linux users will miss out on are things that use the new features of Flash introduced after that date.
So the only thing non-Chrome-using Linux users will miss out on are things that use the new features of Flash introduced after that date.
That makes sense. I was starting to wonder if this was the end of flash for Mozilla on major websites like YouTube, but 5 years is a really long time for support. Hopefully, we'll see an emergence of widespread html5 use by then and not have to worry about having proprietary web technologies working.
This might be more of a problem for FreeBSD than it is for Linux; at the moment, one can use flash on FreeBSD via linux firefox and hackery. I'm not aware of a way to use linux chrome as yet.
Check out FlashVideoReplacer [1]. It replaces videos with your browser media plugin or can launch it in a separate player. I use it with gecko-mediaplayer and love it!
[1] https://addons.mozilla.org/en-US/firefox/addon/flashvideorep...
[1] https://addons.mozilla.org/en-US/firefox/addon/flashvideorep...
You still be able to use flash 11.2 and receive security updates for another 5 years. Unless there is going to be massive progress for flash (which we already know there isn't) this isn't really news. They are basically saying if there ever is a flash 12 it will not be supported on linux.
That hasn't been true for a very long time. Just using the linux flash plugin with nspluginwrapper on a native firefox has been the preferred method for flash on FreeBSD for several years now. I have not yet tried to use the linux chrome plugin with a native chromium, but that may also be a possibility now or sometime in the future.
Or just maybe any improvement makes Flash usable on Linux without crashing the browser. People might actually start enabling Flash on Linux if that happens.
I don't find Flash crashing my browser on Linux too often, but it crashes itself pretty regularly.
Plus the older hardware I run Linux on can barely show a 288p Hulu video, with lots of stuttering, even though the machine can play videos twice that resolution flawlessly in any of the native video players.
Plus the older hardware I run Linux on can barely show a 288p Hulu video, with lots of stuttering, even though the machine can play videos twice that resolution flawlessly in any of the native video players.
>I don't find Flash crashing my browser on Linux too often, but it crashes itself pretty regularly.
Before recentish versions of Firefox, a Flash crash would bring down the whole browser.
Before recentish versions of Firefox, a Flash crash would bring down the whole browser.
I'll give you that. It's one of the reasons I don't have the flash plugin installed.
I've used Chrome since it was available for Linux and I've never once had Flash take down the entire browser. In fact, I can't say I've ever had a Flash crash at all in Chrome. Funny enough it crashes rather frequently in Firefox (still doesn't crash the browser itself though...)
Right, it's obviously dependent on a lot of factors. Apple wouldn't even support it on the Iphone. For general users it may work well enough with the right environement, but I use Linux for development and I have little use for Flash compared to the relatively big impact that it has on system resources.
Here, Gnash already works fine when I really need Flash, which isn't often.
Let's hope this is one more step to Flash irrelevance.
I don't count the times that Flash caused me trouble, and I'll be happy to see it go away.
I think Adobe is nuts to be so hostile to its Linux users. Surely it can't be that expensive to continue developing the old plugin? The thing Flash had going for it was its ubiquity: it worked on all (desktop) browser. Now that that's gone, this will be another good reason not to have new projects depend on Flash.
Adobe has always been this hostile to Linux users. It hasn't seemed to had much of a dent in their success.
Meanwhile, Flash is dead, it just hasn't stopped kicking yet. It's been a long decade, but many people will be cheering it and kicking the corpse when it finally shuffles off to the great /dev/null in the sky.
Meanwhile, Flash is dead, it just hasn't stopped kicking yet. It's been a long decade, but many people will be cheering it and kicking the corpse when it finally shuffles off to the great /dev/null in the sky.
Adobe killing AIR for Linux didn't impact/slow AIR's growth in the slightest, so I would have to assume this change will also have zero impact.
Can't tell if you are serious. Who uses AIR? I've never seen it.
http://www.balsamiq.com is a popular software among people doing wireframes. The Desktop version is based on AIR (and it's the only reason why I've installed AIR on my Mac).
BBC use it for their iPlayer app (well hidden though) so I imagine the UK installation base of Air to be pretty large in comparison to other regions.
Certain Twitter clients. That seems to be about it. :)
(It's sometimes used for in-house stuff, but then what isn't?)
(It's sometimes used for in-house stuff, but then what isn't?)
League of Legends still uses AIR I believe.
Yeah, most Linux users either have Flash enabled for the family and hate it or they don't install it. This is a tiny market. Nobody else will care. Linux users already didn't care. Nothing to see here.
I'm sure adobe will mourn all 3 of the users they'll lose by doing this.
Just reminded me to uninstall my flash-plugin.
Adios flash ads!
Hello html5 ads.
sigh
So, Google agreed to make Flash on Linux available only via Chrome? Damn...
But, if major Linux browsers implement Pepper API, on the other hand it will mean that we (the users) won't have to bother installing (deb/rpm/etc) packages every now or then. Maybe it will turn out better.
But, if major Linux browsers implement Pepper API, on the other hand it will mean that we (the users) won't have to bother installing (deb/rpm/etc) packages every now or then. Maybe it will turn out better.
I guess the Google is initiator of this project and thus won't care (will make adobe not care) about other browsers implementing this API.
Just another step in pushing Chrome down everyone's throat.
Just another step in pushing Chrome down everyone's throat.
So Google really are evil after all.
On the whole I don't think this is evil. More of a lateral move, morally.
I can't imagine what Google hopes to accomplish with this since Flash is currently circling the drain, relevancy-wise, but if it does anything to hasten the move away from using Flash at all, then it's a plus.
I can't imagine what Google hopes to accomplish with this since Flash is currently circling the drain, relevancy-wise, but if it does anything to hasten the move away from using Flash at all, then it's a plus.
So Google is not evil because forcing Adobe to remove flash support from other 'vendors' browsers is actually a good thing? Basically Google knows best and anyone who thinks that they might actually want to continue to use flash on Linux in a non-Google browser (or at least without installing Chrome) is wrong?
This looks like the sort of heavy-handed monopoly activity that made Microsoft so great.
It's possible that Adobe were intending to cease all Linux-based browser support and Google prevented that by buying back Chrome support; in which case Google has slipped in their PR big time.
This looks like the sort of heavy-handed monopoly activity that made Microsoft so great.
It's possible that Adobe were intending to cease all Linux-based browser support and Google prevented that by buying back Chrome support; in which case Google has slipped in their PR big time.
I think Pepper also supports their native client applications (x86 code which runs in a sandbox) and google probably would like to see that more used.
I think it's reasonable to assume that Adobe wants to kill Flash on GNU/Linux, but can't yet do it for Chrome due to some engagement with Google. If this is really their intent, they are going to have much more trouble justifying a kill operation on other platforms.
I forsee a slow and painful death for Flash.
I forsee a slow and painful death for Flash.
It's only been about a year since the flash plugin started assuming any sort of stability. Did Adobe just find Linux too hard to implement on?
Given that it took them something like 5 years to make a 64-bit version, I would imagine that Flash is such a mass of spaghetti code that, yes, they did find Linux too hard.
[deleted]
For reference, here are the thoughts of Robert O'Callahan from Mozilla (and those of Simon Fraser from Apple) on Pepper: https://mail.mozilla.org/pipermail/plugin-futures/2010-April...
The thread (which continues into May) goes over pretty clearly why they felt Pepper was a bad idea.
The thread (which continues into May) goes over pretty clearly why they felt Pepper was a bad idea.
Google has a nasty habit of developing some technology in a dark room, then dropping it on the web community and being confused when no one is that interested (Dart is the other big example). It makes me wonder if they really want these projects to be cross-platform successful or not.
Adobe is dropping linux support after 11.2. With the except of Chrome due to a new API that "aims to provide a layer between the plugin and browser that abstracts away differences between browser and operating system implementations."
Given that linux really hasn't been a priority for them and they are dropping flash all together; this isn't really news.
The press release says Adobe worked with Google on Pepper. So for them to have a bias towards it isn't groundbreaking.
Given that linux really hasn't been a priority for them and they are dropping flash all together; this isn't really news.
The press release says Adobe worked with Google on Pepper. So for them to have a bias towards it isn't groundbreaking.
With the except of Chrome due to a new API
This is what's hard to understand: they are not dropping NPAPI on Windows, so it's not like the Chrome API is the enabler here.
This is what's hard to understand: they are not dropping NPAPI on Windows, so it's not like the Chrome API is the enabler here.
From the press release it seems NPAPI is OS dependent while Pepper is less so.
This all assume there is actually going to be something more than security updates after 11.2 for other platforms. And that it is going to be something we would want on Linux.
This all assume there is actually going to be something more than security updates after 11.2 for other platforms. And that it is going to be something we would want on Linux.
>From the press release it seems NPAPI is OS dependent while Pepper is less so.
Correct. The NPAPI version of Flash is very platform-dependent; whereas Pepper Flash is almost completely platform neutral, and Chrome OS needs most of the same Pepper platform bits anyway. So, our maintenance overhead for Pepper Flash on Linux is very small. On top of that, Linux is broadly deployed throughout Google (and is very popular among Chrome developers), so we're scratching our own itch a bit.
Correct. The NPAPI version of Flash is very platform-dependent; whereas Pepper Flash is almost completely platform neutral, and Chrome OS needs most of the same Pepper platform bits anyway. So, our maintenance overhead for Pepper Flash on Linux is very small. On top of that, Linux is broadly deployed throughout Google (and is very popular among Chrome developers), so we're scratching our own itch a bit.
Flash provides a lot of hardware abstractions, from H.264 accelerated video, to webcam and microphone access, and accelerated 3d (openGL) rendering. Does the Pepper API provide wrappers for all this stuff? Otherwise it would seem that Flash for Linux would still need to carry a lot of platform-dependent plumbing.
Yes, the sandbox disallows direct hardware access. So, the PPAPI provides abstractions to those underlying capabilities.
>This all assume there is actually going to be something more than security updates after 11.2 for other platforms. And that it is going to be something we would want on Linux.
There will be updates and they will be desirable in Linux assuming people continue creating Flash content that makes use of the new features: http://news.ycombinator.com/item?id=3621096.
There will be updates and they will be desirable in Linux assuming people continue creating Flash content that makes use of the new features: http://news.ycombinator.com/item?id=3621096.
Interesting. So there will be another 3 version with the following features:
Keyboard input support in full-screen mode
Improved audio support for working with low-latency audio
Ability to progressively stream textures for Stage 3D content
LZMA compression support for ByteArray
Frame label events
ActionScript workers (enables concurrent ActionScript execution on separate threads)
Support for advanced profiling
Support for more hardware-accelerated video cards (from 2005/2006) in order to expand availability of hardware accelerated content
Improved ActionScript performance when targeting Apple iOS (What the??? iOS???)
Performance index API to inform about performance capabilities of current environment
Release outside mouse event API
Refactoring and modernizing the current core Flash runtime code base
Work on the ActionScript Virtual Machine
Updates to the ActionScript language
--
Doesn't seem like there will be anything new that can not be currently albeit less efficiently.
Keyboard input support in full-screen mode
Improved audio support for working with low-latency audio
Ability to progressively stream textures for Stage 3D content
LZMA compression support for ByteArray
Frame label events
ActionScript workers (enables concurrent ActionScript execution on separate threads)
Support for advanced profiling
Support for more hardware-accelerated video cards (from 2005/2006) in order to expand availability of hardware accelerated content
Improved ActionScript performance when targeting Apple iOS (What the??? iOS???)
Performance index API to inform about performance capabilities of current environment
Release outside mouse event API
Refactoring and modernizing the current core Flash runtime code base
Work on the ActionScript Virtual Machine
Updates to the ActionScript language
--
Doesn't seem like there will be anything new that can not be currently albeit less efficiently.
My assumption is that among {NPAPI/Windows, NPAPI/Linux, PPAPI/Windows, PPAPI/Linux}, NPAPI/Linux provides the least value for the work required.
If you read the responses from Chrome engineers on that thread you'll see why a new API was necessary. The requirements and guarantees of your API fundamentally change when you move it out of process for sandboxing and stability. Naive approaches lead to awful performance, deadlocks, or the need to poke massive holes in your security architecture. After a few engineering years of trying to make NPAPI work, it became clear that the result was so different and banned so much of NPAPI that a clean break was the only correct approach.
I think the responses from the other browser manufacturers were pretty convincing. The problem, if you read the thread, was not that NPAPI was sufficient. The problem was that Chrome wanted to reinvent all sorts of APIs that already existed in the Web platform. They ignored that issue and did Pepper anyway.
This is what I meant by "naive approaches." Take your example of Pepper API layer versus NPRuntime. When you try to use a sandboxed NPRuntime plugin you hit a hard performance wall with synchronous dispatch overhead. You also introduce huge potential for deadlocks that can be very difficult to detect. This isn't the kind of thing you notice in a simple simple proof-of-concept or casual discussion, but it becomes painfully obvious when trying to implement a real-world plugin.
So extend the Web APIs to handle this. You don't have to do synchronous calls.
Robert O'Callahan talked in that thread about the potential for extending the capabilities of Web Workers to allow the kind of things you want to do to be done asynchronously. I know I'd love to have the ability to render to a 2D or 3D canvas context in a Web Worker, for example (the kind of thing that sandboxed plugins want to do), but all the effort that could have gone to that went to this weird plugin- (and NaCl-)specific API instead.
It's kind of sad, because I would like to use these APIs in my web content, but I can't. The cynic in me would say that it's because Google wants to push NaCl. I don't want to program C++ to get access to these goodies; I want to program in CoffeeScript.
Robert O'Callahan talked in that thread about the potential for extending the capabilities of Web Workers to allow the kind of things you want to do to be done asynchronously. I know I'd love to have the ability to render to a 2D or 3D canvas context in a Web Worker, for example (the kind of thing that sandboxed plugins want to do), but all the effort that could have gone to that went to this weird plugin- (and NaCl-)specific API instead.
It's kind of sad, because I would like to use these APIs in my web content, but I can't. The cynic in me would say that it's because Google wants to push NaCl. I don't want to program C++ to get access to these goodies; I want to program in CoffeeScript.
PPAPI is a platform for plugins to safely port existing native code, and implement performance critical components. The PPAPI platform capabilities (audio, canvas, webgl, etc) already exist as regular JavaScript APIs in Chrome. So, if you want to use them on normal web content you can. However, in doing so you incur both the strengths and limitations of the web platform (e.g. JavaScript dispatch, IPC overhead, and a single-threaded execution context).
You gave the example of using canvas from a web worker. Unfortunately, the whole web platform is built on the assumption of a single-threaded execution pipeline. Web workers get around this by using postMessage and not having access to the DOM, shared variables, and other stateful parts of the platform. Canvas and WebGl as spec'd and implemented are tied to these stateful parts of the platform (DOM, etc.), which is why you cannot use them from a worker.
So, your desired change would involve either a major overhaul of the web as spec'd and implemented, or a change to the Canvas and WebGL standards. The first is probably not going to happen. The second is achievable and implementable, but wouldn't help address the use cases I described in my first sentence.
You gave the example of using canvas from a web worker. Unfortunately, the whole web platform is built on the assumption of a single-threaded execution pipeline. Web workers get around this by using postMessage and not having access to the DOM, shared variables, and other stateful parts of the platform. Canvas and WebGl as spec'd and implemented are tied to these stateful parts of the platform (DOM, etc.), which is why you cannot use them from a worker.
So, your desired change would involve either a major overhaul of the web as spec'd and implemented, or a change to the Canvas and WebGL standards. The first is probably not going to happen. The second is achievable and implementable, but wouldn't help address the use cases I described in my first sentence.
I'm well aware that, at the moment, the canvas context is restricted to a single thread. But this could be changed. All you have to do is to provide an API to move a canvas context to a different thread/worker. This is quite simple. There's a Mozilla bug on it: https://bugzilla.mozilla.org/show_bug.cgi?id=709490
It requires no more engineering effort than it took to implement the corresponding code in the PPAPI, and probably a lot less. Moreover, non-NaCl and non-plugin code could benefit from it.
As explained before, what would need to be done is simply to expose native versions of the Web APIs. These APIs would mirror the Web APIs more or less exactly (maybe using pointers to buffers instead of typed arrays, for example, but otherwise they'd be the same). In the cases in which Web APIs are not sufficient, both the native and JavaScript versions would be extended. In this way, "performance critical components" of native code and Web content would both benefit.
It requires no more engineering effort than it took to implement the corresponding code in the PPAPI, and probably a lot less. Moreover, non-NaCl and non-plugin code could benefit from it.
As explained before, what would need to be done is simply to expose native versions of the Web APIs. These APIs would mirror the Web APIs more or less exactly (maybe using pointers to buffers instead of typed arrays, for example, but otherwise they'd be the same). In the cases in which Web APIs are not sufficient, both the native and JavaScript versions would be extended. In this way, "performance critical components" of native code and Web content would both benefit.
What are you talking about? Are you suggesting that Adobe provide an implement Flash via Web APIs and Javascript? We're talking about the challenges of having a plugin interface for Chrome and how NPAPI is limited/flawed and you're suggesting... Web APIs?
Maybe I'm really confused because I don't understand.
Maybe I'm really confused because I don't understand.
The proposal that roc and smfr put forth is this: Native code could call Web APIs, slightly tweaked for the benefit of native code and to satisfy the security/isolation guarantees that Chrome wants to enforce. These same APIs would have JavaScript versions, so that ordinary Web content could use them as well. For example, the same asynchronous 3D command stream API that Pepper exposes would be available to Web Workers.
Here's some further reading:
* https://mail.mozilla.org/pipermail/plugin-futures/2010-May/0...
* https://mail.mozilla.org/pipermail/plugin-futures/2010-May/0...
Note that Darin's followup message included this:
"I do agree however we want to keep Pepper APIs in sync with existing Web APIs. That will obviously be a challenge if they are not one and the same, but I don't think it is impossible or even that difficult to achieve with them being separate APIs."
This has already failed. Web Workers cannot render even 2D content asynchronously today, while Pepper can (which advantages plugins and NaCl over ordinary Web content). This is exactly the problem that roc and smfr were trying to avoid.
I don't think that Darin's example, of an <embed> tag being untouchable by Web content, is an insurmountable problem. In fact, I think this is exactly the kind of thing you want JavaScript content to be able to do -- high-fidelity JS versions of PDF and Flash would be great. And the issue of Web Workers and audio APIs needing shared memory is a Chrome problem (because Chrome puts each worker in a separate process), but not a problem for browsers generally.
Also, the argument that "it's an existing plugin, you don't want them to rewrite their code" doesn't hold water. It's an entirely new set of plugin APIs. Adobe has to rewrite its code anyway. It's just that the other browser vendors wanted the Web as a whole to benefit from this, not just Adobe.
Here's some further reading:
* https://mail.mozilla.org/pipermail/plugin-futures/2010-May/0...
* https://mail.mozilla.org/pipermail/plugin-futures/2010-May/0...
Note that Darin's followup message included this:
"I do agree however we want to keep Pepper APIs in sync with existing Web APIs. That will obviously be a challenge if they are not one and the same, but I don't think it is impossible or even that difficult to achieve with them being separate APIs."
This has already failed. Web Workers cannot render even 2D content asynchronously today, while Pepper can (which advantages plugins and NaCl over ordinary Web content). This is exactly the problem that roc and smfr were trying to avoid.
I don't think that Darin's example, of an <embed> tag being untouchable by Web content, is an insurmountable problem. In fact, I think this is exactly the kind of thing you want JavaScript content to be able to do -- high-fidelity JS versions of PDF and Flash would be great. And the issue of Web Workers and audio APIs needing shared memory is a Chrome problem (because Chrome puts each worker in a separate process), but not a problem for browsers generally.
Also, the argument that "it's an existing plugin, you don't want them to rewrite their code" doesn't hold water. It's an entirely new set of plugin APIs. Adobe has to rewrite its code anyway. It's just that the other browser vendors wanted the Web as a whole to benefit from this, not just Adobe.
Good. So now I don't have to use it anymore.
Dear Adobe: just kill Flash already, for good. The world (wide web) will be a better place.
I think it's safe to assume they've already killed it. Web developers can no longer make a reasonable assumption that their users will have flash, therefore flash is no longer a useful general purpose tool. It'll stick around for a long time yet due to enterprise and other lazy programmers, but for wide-audience web content flash is dead.
In effect they are. No android support, now nothing except Chrome support on Linux. I'd assume that if my theory is true, Mac OS X will take a similar route(why it didn't happen first is beyond me) before Windows finally meets a similarly gimped fate.
I'll rephrase that:
F* Adobe: just kill Flash already, for good. The world (wide web) will be a better place.
I feel absolutely no love for Adobe. Flash was a great technology and Macromedia was a dream company (at least for 14-year old me). They ruined Flash and other Macromedia inventions after taking over.
I truly wish Adobe dies alongside Flash. And Oracle also.
F* Adobe: just kill Flash already, for good. The world (wide web) will be a better place.
I feel absolutely no love for Adobe. Flash was a great technology and Macromedia was a dream company (at least for 14-year old me). They ruined Flash and other Macromedia inventions after taking over.
I truly wish Adobe dies alongside Flash. And Oracle also.
This announcement further convinces me that Flash is gearing down to obsolescence.
Indeed. I've run FlashBlock for years, and minus Hulu and a couple other sites, I find I almost never have a need to click on the blocked Flash objects.
And it seems like the days of sites implemented entirely in Flash have pretty much come to an end.
Given the nature of Flash I could never understand why it was so much trouble to implement on Linux, or to create a 64-bit version. I can't imagine what a colossal mass of spaghetti code that app must be. I've been waiting impatiently for it to die since at least 2001.
And it seems like the days of sites implemented entirely in Flash have pretty much come to an end.
Given the nature of Flash I could never understand why it was so much trouble to implement on Linux, or to create a 64-bit version. I can't imagine what a colossal mass of spaghetti code that app must be. I've been waiting impatiently for it to die since at least 2001.
https://github.com/mozilla/shumway
> Shumway is an HTML5 technology experiment that explores building a faithful and efficient renderer for the SWF file format without native code assistance.
> Shumway is community-driven and supported by Mozilla. Our goal is to create a general-purpose, web standards-based platform for parsing and rendering SWFs. Integration with Firefox is a possibility if the experiment proves successful.
> Shumway is an HTML5 technology experiment that explores building a faithful and efficient renderer for the SWF file format without native code assistance.
> Shumway is community-driven and supported by Mozilla. Our goal is to create a general-purpose, web standards-based platform for parsing and rendering SWFs. Integration with Firefox is a possibility if the experiment proves successful.
I've been following that project and there's a lot of activity on it. So I wouldn't be surprised if they have something working in 6 months or so. I can see this being useful when flash becomes a strictly legacy technology.
Bye flash. Welcome flash alternatives. And downloading/torrenting even more videos.
Trying to keep the tinfoil hat off, but... when I tried to post a comment on the Adobe blog asking whether Linux is being singled out in this respect and if so, why, I got a database error.
I can't make much sense of this. Adobe declared Flash dead. Apple declared Flash dead. Google declared Flash dead in Chrome for Android.
Now, they're going to continue working on Flash, but only on a new API that is implemented only in a single browser in Linux (and from statements from Apple and Mozilla, will stay that way), but keeping it compatible with the old NPAPI on Windows?
What I don't even....
Edit: Could it be that Google is planning to release (or has released) some Linux-based appliance where Flash support is a must?
Now, they're going to continue working on Flash, but only on a new API that is implemented only in a single browser in Linux (and from statements from Apple and Mozilla, will stay that way), but keeping it compatible with the old NPAPI on Windows?
What I don't even....
Edit: Could it be that Google is planning to release (or has released) some Linux-based appliance where Flash support is a must?
Adobe never declared desktop Flash dead, they're just hedging their bets with HTML5 tools.
Where does Adobe declare Flash on the desktop dead?
In the same place where they declare mobile (a bit of a misnomer, tablets aren't exactly mobile, not much more than notebooks anyway) Flash dead.
Flash is appealing because it has features HTML/CSS/JS do not have and because everyone on every platform has it. Since mobile devices are becoming ever more important and Flash is not supported on those devices (or will not be) the second part of that sentence is no longer true.
Conclusion: Flash is dead. We will have to deal with it for years but it's on its way out. A web technology that will not work on mobile devices has no future.
Flash is appealing because it has features HTML/CSS/JS do not have and because everyone on every platform has it. Since mobile devices are becoming ever more important and Flash is not supported on those devices (or will not be) the second part of that sentence is no longer true.
Conclusion: Flash is dead. We will have to deal with it for years but it's on its way out. A web technology that will not work on mobile devices has no future.
They never did that. They declared the Flash Player for mobile dead. but it's still very viable to make Flash applications for mobile, using AIR.
That's Adobes biggest problem, for so many people "Flash" means "browser plugin." They need to kill that notion, the Flash Player is just a part of the Flash platform.
Which isn’t part of the web.
Flash may well survive as AIR - that’s an uphill battle but it's possible – but that’s kinda irrelevant for the web.
Flash may well survive as AIR - that’s an uphill battle but it's possible – but that’s kinda irrelevant for the web.
I may agree, but you didn't show where _Adobe_ states this for the _desktop_ ...
If you were on Wikipedia you'd see a [Citation needed] here.
If you were on Wikipedia you'd see a [Citation needed] here.
They are basically saying due to Pepper there is no or little work in getting flash to work in Chrome on Linux... so there will be continued support.
The real question is if this is true, why are they dropping flash for android?
The real question is if this is true, why are they dropping flash for android?
There are definitely other reasons. Remember "Thoughts on Flash" [1]?
“First, there’s Open… Rather than use Flash, Apple has adopted HTML5…” — and CSS3, SVG, and HTML5 have indeed provided most of the capabilities that once were Flash’s domain.
“Third, there’s reliability, security and performance.” — which is really three things, each of which Flash has an outstandingly poor track record with.
“Fourth, there’s battery life.”
“Fifth, there’s Touch. ¶ Flash was designed for PCs using mice, not for touch screens using fingers. For example, many Flash websites rely on ‘rollovers’…”
[1]: http://www.apple.com/hotnews/thoughts-on-flash/
“First, there’s Open… Rather than use Flash, Apple has adopted HTML5…” — and CSS3, SVG, and HTML5 have indeed provided most of the capabilities that once were Flash’s domain.
“Third, there’s reliability, security and performance.” — which is really three things, each of which Flash has an outstandingly poor track record with.
“Fourth, there’s battery life.”
“Fifth, there’s Touch. ¶ Flash was designed for PCs using mice, not for touch screens using fingers. For example, many Flash websites rely on ‘rollovers’…”
[1]: http://www.apple.com/hotnews/thoughts-on-flash/
Probably because Native Client on ARM isn't as well-developed.
http://www.chromium.org/nativeclient/reference/arm-overview#...
http://www.chromium.org/nativeclient/reference/arm-overview#...
No. Just that Google will do it for them in Chrome. That's what they already do anyway because of the security hole that Flash is.
Where'd you pull that idea out of? Google's not implementing the Flash player, only providing new API for the Flash engineers to build against, the same as they always have.
From previous statements and actions of Google regarding Flash (fixing security holes in a way that implies they have source code access), it is very likely that it is indeed Google that are doing this.
Flash has been given some life on mobile via http://news.ycombinator.com/item?id=3623319
> Google declared Flash dead in Chrome for Android.
This is excellent news for web security. It will force other browsers to at least implement the Pepper API. Hopefully it will encourage them to use Native Client as well.
"Other browsers" have already commented why things like Native Client are absolutely a no-go area. As far as I can tell, the arguments against Pepper run much along the same lines - being dependent on Native Client sure won't help.
If you see the arguments against Native Client, it's also obvious using it to be able to keep supporting Flash would be rather...ironic.
If you see the arguments against Native Client, it's also obvious using it to be able to keep supporting Flash would be rather...ironic.
What are the arguments against NaCl?
You made sense until the last 2 sentences.
You're saying Google is enforcing whatever it wishes upon others. Aka, non-standard stuff.
The Pepper API would be all nice if it wasn't hiding the NaCl vessel. NaCl is a very hard to standardize (yes, being open source has nothing to do with ease of implementation, or proper standards. News at 11.). NaCl is also (one of) the vessel for Google to get more control over the web, due to the above, and that it can do stuff such as "take your C/C#/etc. app and run in it Chrome, via Chrome market!", while they know others can hardly ever implement it.
you can be relatively sure that Google pushed Adobe a little bit in that direction, and that eventually flash may be Pepper API only. Its easier for Adobe too.
You're saying Google is enforcing whatever it wishes upon others. Aka, non-standard stuff.
The Pepper API would be all nice if it wasn't hiding the NaCl vessel. NaCl is a very hard to standardize (yes, being open source has nothing to do with ease of implementation, or proper standards. News at 11.). NaCl is also (one of) the vessel for Google to get more control over the web, due to the above, and that it can do stuff such as "take your C/C#/etc. app and run in it Chrome, via Chrome market!", while they know others can hardly ever implement it.
you can be relatively sure that Google pushed Adobe a little bit in that direction, and that eventually flash may be Pepper API only. Its easier for Adobe too.
The Native Client source code repository is huge, but it is not that hard to find your way around in. I have been studying it because I plan to build something on top of it. I am by no means a stellar programmer, and I have found it reasonably navigable. (It did take me a few days to get my bearings, though, and I plan to use a much simpler, custom API to minimize the application's attack surface. Haven't looked much at Pepper.)
yes - but
implement it in opera, ie, or firefox - you'll find that you've to rearchitecture a lot of your browser - or might as well just grab webkit (of course, in our case you can just try firefox since its the only open source one of the 3)
I must admit, I hadn't thought about the changes necessary in the browser. What major rearrangements does it require?
[deleted]
I've been living flash-free for about 6 months, now that youtube autoloads html5 video the only thing pissing me off on a regular basis are the charts on Google Finance and Yahoo Finance.
Wow. I remember waiting for flash to come to 64 bit Linux systems...
Perhaps Adobe has to continue supporting Chrome to support Googles Chromebooks.
In a perfect world, we would have open standards and would never need to rely on a company. Hopefully flash will die quickly (I wish I had a dollar for everytime I have heard this).
Perhaps Adobe has to continue supporting Chrome to support Googles Chromebooks.
In a perfect world, we would have open standards and would never need to rely on a company. Hopefully flash will die quickly (I wish I had a dollar for everytime I have heard this).
Based on other comments in this thread, it sounds like less of "Adobe supporting Chrome" than "Google using its source license for Flash to keep supporting Chrome on Linux". And yes, presumably at least in part due to Chromebooks.
Unsurprising, both products are provided free in order to facilitate the tracking of users, and I suspect that the vast majority of users do not turn off Flash cookies.
So long as Google's Youtube defaults to Flash, it's a case of mutual interests.
So long as Google's Youtube defaults to Flash, it's a case of mutual interests.
Flash has obviously been very beneficial to them in the long run. It has given them the only remaining well-controlled proprietary piece of the web. This helps them sell their IDE, and more importantly, gets their brand out there.
Now, I'd argue that these goals have now been accomplished. Adobe is well-entrenched in web history, and everyone knows what Flash is. However, the relevance of Flash is clearly declining, due to HTML5, and stigma and disgruntlement is increasing. This means they will get less and less sales of their IDE and their name will fizzle out.
Imagine for a second that they open sourced the Flash player. Just the player. Suddenly it would no longer carry such a stigma with Linux, it would be easy to include in distros, developers would contribute fixes and make it more efficient on hard-to-support systems. It would literally stretch out its life-time as a product, and keep Adobe's name on the web.
I argue that Flash has played out its role for Adobe, and if they open source it now it could only benefit them. I did not think this was true in the past, and I think it will not be true in 5 to 10 years when HTML5 has surpassed Flash adoption in the most important venues. However, right now I think it would benefit them immensely.
There also seems to be a sentiment from some of the comments here that they are losing interest in maintaining Flash, so opening it to the community would seem to make some sense. If the "standard" ends up evolving in any way, they'd always have a head-start in their IDE support, since it will easily remain ahead of the curve.