Skip to main content
B
BunsenLabs_org
Participant
April 4, 2017
Answered

What Caused Adobe to Continue Support?

  • April 4, 2017
  • 1 reply
  • 1365 views

Hi everyone! I come from (not as a developer but just as a curious mind and  general feedback giver) the community of a small linux distribution called Bunsen-Labs. A continuation of the Crunchbang Linux OS.  Anyway It's common knowledge that Adobe at one point ceased support of 32 bit linux for Adobe flash for the NPAPI plugin. But recently has changed their position... what caused this? Why now has Adobe decided that NPAPI (firefox like browsers)  are okay to continue updating?

Also if someone can confirm this...while Adobe is planning to update NPAPI browser plugins for security, and limited features, they won't get the full set of suite of new flash features that the PPAPI plugin will receive? What's the point in providing to PPAPI but not NPAPI?  Will this be mirrored in 32 and 64 bit both?

My last question is, the Labs.Adobe site provides beta versions of Flash. Currently the beta is at 25.0.0.143, and the current stable release on the adobe site is 25.0.0.127.   So if 143 is proven to be stable enough, will the official flash player then go from 127 to 143?

Thanks everyone! Visit the bunsen website to check us out!

This topic has been closed for replies.
Correct answer jeromiec83223024

Revisiting decisions and evaluating whether or not they make sense in your current operational context is a healthy activity.  We believe that shipping a current version of the NPAPI Flash Player for Linux allows us to provide a much better outcome for the Linux community, and simultaneously provides a more efficient way to keep those releases secure from an engineering perspective.

The reason that we don't port things like DRM and Stage3D to NPAPI have roots in why building the PPAPI interface was so attractive in the first place.  PPAPI abstracts away much of the fragmentation-related complexity that otherwise makes hardware acceleration support on the long-tail of Linux distributions prohibitively expensive and painful, and it allows us to write much more platform-agnostic code.  Essentially, PPAPI allows us to reuse much of engineering effort that's more justifiably applied to the much larger audiences on commercial desktop platforms.

In general, we try to prioritize our efforts using the general philosophy of "do the most good for the most people".  Linux, and the subset of NPAPI users combined across all distros represents maybe 1% of our total audience.  We already invest a significantly disproportionate amount of resources in providing Linux support, and building a good experience across all NPAPI clients on Linux isn't really feasible.  The compromise lets us continue to provide NPAPI support that's measurably better than what was delivered with the 11.2 branch, in a way that's feasible from a cost perspective.  If you have a hard requirement for NPAPI, we're giving you something better than you had, and if you need the advanced functionality, then the PPAPI plug-in is available for you and provides much better functional parity with the commercial desktop environments.

Finally, the version numbers will continue to increase between the beta build and the actual GMC (it's all the same branch, so the numbers progress linearly). We typically follow up with general availability release with a beta update a couple days after that bring the builds into parity until a new beta from the next branch gets cut.

Hope that makes sense!

1 reply

jeromiec83223024
jeromiec83223024Correct answer
Inspiring
April 4, 2017

Revisiting decisions and evaluating whether or not they make sense in your current operational context is a healthy activity.  We believe that shipping a current version of the NPAPI Flash Player for Linux allows us to provide a much better outcome for the Linux community, and simultaneously provides a more efficient way to keep those releases secure from an engineering perspective.

The reason that we don't port things like DRM and Stage3D to NPAPI have roots in why building the PPAPI interface was so attractive in the first place.  PPAPI abstracts away much of the fragmentation-related complexity that otherwise makes hardware acceleration support on the long-tail of Linux distributions prohibitively expensive and painful, and it allows us to write much more platform-agnostic code.  Essentially, PPAPI allows us to reuse much of engineering effort that's more justifiably applied to the much larger audiences on commercial desktop platforms.

In general, we try to prioritize our efforts using the general philosophy of "do the most good for the most people".  Linux, and the subset of NPAPI users combined across all distros represents maybe 1% of our total audience.  We already invest a significantly disproportionate amount of resources in providing Linux support, and building a good experience across all NPAPI clients on Linux isn't really feasible.  The compromise lets us continue to provide NPAPI support that's measurably better than what was delivered with the 11.2 branch, in a way that's feasible from a cost perspective.  If you have a hard requirement for NPAPI, we're giving you something better than you had, and if you need the advanced functionality, then the PPAPI plug-in is available for you and provides much better functional parity with the commercial desktop environments.

Finally, the version numbers will continue to increase between the beta build and the actual GMC (it's all the same branch, so the numbers progress linearly). We typically follow up with general availability release with a beta update a couple days after that bring the builds into parity until a new beta from the next branch gets cut.

Hope that makes sense!

B
BunsenLabs_orgAuthor
Participant
April 7, 2017

Thanks Jeromeic! And sorry for the late response, I appreciate your well laid out response. So basically to summarize... there's a support branch for Linux PPAPI (used by Chrome, Chromium, Palemoon etc). This set of Linux PPAPI is being updated in step with the Windows version of PPAPI, bit for bit?  All functionality, and support for Flash features apply to both Linux and Windows PPAPI for the 32 and 64bit versions?

Then there's the Linux NPAPI (used by Firefox, Opera, Vivaldi I think..) This Linux NPAPI is getting supported again, but with limited functions of the Flash suite of tools. Basically it's getting updated with core features and security updates.

The Windows Version of NPAPI though is being updated fully to support all the functions of Flash, just like the Windows PPAPI correct?

So if I do have the above correct (if I don't please correct me!), what are the missing features that PPAPI has that Linux NPAPI won't be getting? Besides DRM and Stage3d

I really thank you for your time, and just hoping to better understand this complex web!

Firefly Community Gallery
Adobe Firefly

Remix with Firefly Community Gallery

Thousands of free creations to fall in love with and remix in Firefly.

Explore now
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices