11 ms·

Adobe doesn't want me to run Flash on 64 bit linux?

49 points by timclark 15y ago

dmm 15y ago
Is there a reason to run a 64-bit browser? (Other than the fact that amd64 provides more GPRs?) Do people run browser sessions that use huge amounts of memory? EDIT: Is it standard practice to compile everything as 64-bit on AMD64? This is not the case on early 64-bit arch such as sparc and ppc. The reason for this is that compiling as 64-bit doubles the size of longs and pointers and is only an advantage when you need to address large amounts of memory. For example if you run linux on ppc64 almost all of your userland is probably compiled 32bit.
- FooBarWidget 15y ago
  Yes. The 64-bit browser came with the OS.
  - dmm 15y ago
    A 32-bit browser runs just fine on all of the 64-bit OSs I know of. On all of the OSs I have experience with, compiling an app as 64-bit is the exception, done only when it needs lots of memory. What advantages does running a 64-bit browser on a 64-bit OS have over running a 32-bit browser on a 64-bit OS? Do the 8 extra GPRs bring significant performance benefits? Do individual browser processes need to address lots of memory?
    - stingraycharles 15y ago
      More memory capacity is just one of the use cases. Just to name one example, when doing string comparisons, you can use long integer comparisons under the hood. When using 8 byte longs instead of 4 byte longs, string comparisons are faster.
      - dmm 15y ago
        > you can use long integer comparisons under the hood That's interesting. Does it make up for the increased size of pointers? Caches are under a lot of pressure these days. AMD64 is a weird arch. Is it possible to use 64bit instructions with a 32bit address space?
        mjg59 15y ago
        Yes, but it's ABI incompatible with 32-bit or full 64-bit. https://sites.google.com/site/x32abi/ https://sites.google.com/site/x32abi/ is an implementation.
        mjb 15y ago
        > Caches are under a lot of pressure these days. More from data sizes than code sizes, at least in most performance-critical applications. Sure, bigger pointers will lead to higher miss rates in caches that contain code, but that is unlikely to prove to be a bottleneck for real-world browser use (in the current version of the real world).
- adamtulinius 15y ago
  Well, for one it would be lovely not having to clutter a 64-bit system with a ton of 32-bit libraries, just because of Adobes software being less than stellar.
  - jsight 15y ago
    Yes, and it's nice to avoid the increased memory overhead of running 32-bit GTK and 64-bit GTK. The increase in shared lib overhead is still fairly significant.
- bad_user 15y ago
  compiling as 64-bit doubles the size of longs and pointers Obese longs and pointers, imagine the horror - but, no, that's not the reason. The reason for why apps don't get compiled to 64-bits has more to do with the effort required to port said apps to 64-bits. Truth is running 64-bits apps yields other advantages than access to more than 4GB of memory - a 64-bits app has access to the processor's 64-bits instruction set and some architectures allow access to more general purpose registers, memory-mapped files are easier to implement (MongoDB, last time I tried it, was unusable on 32-bits) and performance of applications such as encoders/decoders/encryption software is increased. A 64-bits Flash would clearly benefit from the transition, even if you don't have more RAM.
  - dmm 15y ago
    Every arch I've worked with(ppc, sparc) 64bit binaries are almost universally slower than 32bit unless they use the bigger address space. > Obese longs and pointers, imagine the horror Take a break from javascript and look up how processor caches work, doubling the size of pointers increases cache pressure and can definitely make programs slower. > allow access to more general purpose registers, memory-mapped files are easier to implement I specifically mentioned more registers and a bigger address space. My question was whether this made a difference for web browsers.
    - Symmetry 15y ago
      Yes, doubling the number of registers and making SSE2 a requirement increased performance across the board (except for flash). http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-... I've never heard of a processor architecture that got a performance boost from going to 64 bits except x86-64, though.
    - bad_user 15y ago
      I specifically mentioned more registers No you haven't. Take a break from javascript and look up how processor caches work A personal attack doesn't do any good. There are techniques available to reduce pressure on the cache, but more and bigger registers gives you an immediate advantage that can't be replicated - some apps have speed gains just by recompiling. Also, 32-bits apps running on top of 64-bits are running in an emulated 32-bits environment and so they take a penalty just for that. It is true in practice that 32-bits is all you'll ever need and you won't notice the difference, but modern browsers would get a healthy boost in performance (yes, 15% matters).
- keeperofdakeys 15y ago
  Why don't we use 16 bit apps anymore, they worked? The answer is because the libraries they depend on are no longer 16 bit. Getting 32 bit code to work on a 64 bit system involves having BOTH the 32 and 64 bit versions of the library installed. Using which program you want to use, 64 or 32 bit, is not a choice like a window manager; you should use the one that is supported by your system. If your system is 64 bit, it supports 64 bit apps. The fact that it CAN run 32 bit apps is just an extra. And personally, yes, I could easily blow this limit if I allowed my normal browsing behavior to blossom (that is having lots of tabs I want to reference later and leaving them open).
- mjb 15y ago
  > Is there a reason to run a 64-bit browser? (Other than the fact that amd64 provides more GPRs?) Increased effectiveness of ASLR (Address space layout randomization) and PIE (position independent executables) is one such reason. Using ASLR and 64 bit pointers can make some common classes of attack much more difficult, and potentially infeasible. I don't think mainstream linux distributions take full advantage of them yet, though.
wladimir 15y ago
So that's another platform that doesn't support Flash. Flash feels like a dead end more and more.
nathanb 15y ago
I have a feeling that this will work like broadband to small towns. The major carriers are only marginally interested in making it work well right up until someone makes a move toward municipal broadband, and then suddenly everyone takes a great interest in providing service. Until there's a viable competitor in the Linux space, Flash on x64 will continue to be a choice between several bad solutions. The only thing that could change this would be if Arm CPUs started supporting the x64 instruction set. Then Android's position in the market would likely make a compelling business argument for a 64-bit Flash. I'm not holding my breath.
- makmanalp 15y ago
  Sort of, but not really. The problem is that we don't pick whether we're going to use Flash or an alternative. The website does. And you bet that a lot of websites also aren't going to care about the tiny 64 bit linux segment. "Competition" in this case would have to provide an exact drop-in replacement of Flash, which I don't think will happen soon. (The open flash replacements mostly sucked the last time I tried them.)
  - nathanb 15y ago
    Sorry; by alternative I didn't mean HTML5 or Silverlight or whatever but whether to use gnash + Lightspark or an old, buggy 64-bit flash or 32-bit flash.
- reemrevnivek 15y ago
  x64 uses a complex instruction set, which has a huge number of instructions that can do non-primitive operations in one step. ARM uses a reduced instruction set, which limits the available operations to basic load, store, arithmetic (on register data only), and a couple jump/branch instructions. These design philosophies are incompatible. An x64 chip would be spinning its wheels, wasting power, if it tried to run ARM assembly. An ARM chip would have to virtualize a huge percentage of the operations that an x64 chip would do in a single instruction, and would be painfully slow, mitigating any power savings it might have. ARM will never run x64 binaries. Good thing you're not holding your breath. This is why we write portable code in higher-level languages that can be compiled for both architectures. Not sure that Android is a motivating factor for Adobe to produce code for desktop Linux, though. Virtualized x64 compatibility would be slower than ARM, and Flash is already a dog on Android.
brudgers 15y ago
>Adobe doesn't want me to run Flash on 64 bit linux? It is hardly surprising that a large company doesn't see much ROI in tailoring a consumer oriented product for a tiny market segment. Given that Flash Player is losing relative and perhaps absolute web presence and the frequency with which Adobe must patch it for security vulnerabilities, creating a version for the tiny minority of consumers who use 64 bit linux for browsing doesn't make a lot of sense from an economic standpoint. The fact that the beta wasn't being brought up to date is probably a reflection of market realities rather than any bias against the platform, and given that a reasonable workaround was available (i.e. a 32bit version), it is hardly surprising that the overall project was dropped.
- icefox 15y ago
  It depends upon what management has as their goal. If they want flash everywhere than they need to make sure it works on places like 64bit Linux. If they are in the final days of the product (which it seems like they are) they just trying to milk it for what it is worth before it dies (i.e. make sure those XP users are not too unhappy).
  - brudgers 15y ago
    Given that there is a viable option for 64 bit Linux users (i.e. 32 bit browsers), the only practical result from the development of a 64 bit Linux version of Flash Player is to placate a handful of zealots not a significant market segment. It is inevitable that Flash will not be everywhere - it will not even be on a significant portion of mobile devices, e.g. iphones.
    - greyfade 15y ago
      But why no 64-bit support on Windows or Mac OS X, where 64-bit is on track to become the norm? The lack of 64-bit for Linux is just a symptom of what seems to be a problem at Adobe.
      - brudgers 15y ago
danieldk 15y ago
I wonder why nspluginwrapper is not mentioned, which supports the use of 32-bit plugins with a 64-bit browser. In fact, when installing /flashplugin-nonfree/ on Ubuntu x86_64 it will nspluginwrapper. It's not ideal, but works fine for casual Flash website use.
- riledhel 15y ago
  As the article mentions, there's also a "preview" for 64-bit linux flash plugin. It's called "Square", runs fairly ok and it's available at http://www.adobe.com/devnet/flashplayer.html http://www.adobe.com/devnet/flashplayer.html Last version available is 10.3.162 or something like that...
  - keeperofdakeys 15y ago
    No, nsplugin wrapper allows you to run the 32 bit plugin on a 64 bit system with 64 bit apps. I haven't had that much luck with it, too much stuttering on my machine.
    - riledhel 15y ago
      I know, I was trying to highlight there's another option from Adobe itself. I found it after trying to use the nsplugin wrapper itself and failed to do so.
yalogin 15y ago
Well Silverlight still does not work on 64 bit macs. It prompts me to restart the browser in 32-bit mode everytime.
- stephen_g 15y ago
  People use Silverlight? I'm actually being serious - I don't have it installed on any of my computers and I've never been to a site that asked me to download it... But perhaps that's because it's mostly used for video streaming and in Australia we don't get any sites like Netflix, Hulu etc.
  - sixtofour 15y ago
    Netflix is why I have Silverlight on my Windows partition.
olefoo 15y ago
Adobe is not allowed to set standards in my world. If my main daily experience of dealing with your company is cursing at you when I restart software I feel forced to use (npviewer.bin), I'm probably going to look for alternatives to your other software as well.

49 points by timclark 15y ago

dmm 15y ago

Is there a reason to run a 64-bit browser? (Other than the fact that amd64 provides more GPRs?) Do people run browser sessions that use huge amounts of memory? EDIT: Is it standard practice to compile everything as 64-bit on AMD64? This is not the case on early 64-bit arch such as sparc and ppc. The reason for this is that compiling as 64-bit doubles the size of longs and pointers and is only an advantage when you need to address large amounts of memory. For example if you run linux on ppc64 almost all of your userland is probably compiled 32bit.

FooBarWidget 15y ago
Yes. The 64-bit browser came with the OS.
- dmm 15y ago
  A 32-bit browser runs just fine on all of the 64-bit OSs I know of. On all of the OSs I have experience with, compiling an app as 64-bit is the exception, done only when it needs lots of memory. What advantages does running a 64-bit browser on a 64-bit OS have over running a 32-bit browser on a 64-bit OS? Do the 8 extra GPRs bring significant performance benefits? Do individual browser processes need to address lots of memory?
  - stingraycharles 15y ago
    More memory capacity is just one of the use cases. Just to name one example, when doing string comparisons, you can use long integer comparisons under the hood. When using 8 byte longs instead of 4 byte longs, string comparisons are faster.
    - dmm 15y ago
      > you can use long integer comparisons under the hood That's interesting. Does it make up for the increased size of pointers? Caches are under a lot of pressure these days. AMD64 is a weird arch. Is it possible to use 64bit instructions with a 32bit address space?
      - mjg59 15y ago
        Yes, but it's ABI incompatible with 32-bit or full 64-bit. https://sites.google.com/site/x32abi/ https://sites.google.com/site/x32abi/ is an implementation.
      - mjb 15y ago
        > Caches are under a lot of pressure these days. More from data sizes than code sizes, at least in most performance-critical applications. Sure, bigger pointers will lead to higher miss rates in caches that contain code, but that is unlikely to prove to be a bottleneck for real-world browser use (in the current version of the real world).
adamtulinius 15y ago
Well, for one it would be lovely not having to clutter a 64-bit system with a ton of 32-bit libraries, just because of Adobes software being less than stellar.
- jsight 15y ago
  Yes, and it's nice to avoid the increased memory overhead of running 32-bit GTK and 64-bit GTK. The increase in shared lib overhead is still fairly significant.
bad_user 15y ago
compiling as 64-bit doubles the size of longs and pointers Obese longs and pointers, imagine the horror - but, no, that's not the reason. The reason for why apps don't get compiled to 64-bits has more to do with the effort required to port said apps to 64-bits. Truth is running 64-bits apps yields other advantages than access to more than 4GB of memory - a 64-bits app has access to the processor's 64-bits instruction set and some architectures allow access to more general purpose registers, memory-mapped files are easier to implement (MongoDB, last time I tried it, was unusable on 32-bits) and performance of applications such as encoders/decoders/encryption software is increased. A 64-bits Flash would clearly benefit from the transition, even if you don't have more RAM.
- dmm 15y ago
  Every arch I've worked with(ppc, sparc) 64bit binaries are almost universally slower than 32bit unless they use the bigger address space. > Obese longs and pointers, imagine the horror Take a break from javascript and look up how processor caches work, doubling the size of pointers increases cache pressure and can definitely make programs slower. > allow access to more general purpose registers, memory-mapped files are easier to implement I specifically mentioned more registers and a bigger address space. My question was whether this made a difference for web browsers.
  - Symmetry 15y ago
    Yes, doubling the number of registers and making SSE2 a requirement increased performance across the board (except for flash). http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-... I've never heard of a processor architecture that got a performance boost from going to 64 bits except x86-64, though.
  - bad_user 15y ago
    I specifically mentioned more registers No you haven't. Take a break from javascript and look up how processor caches work A personal attack doesn't do any good. There are techniques available to reduce pressure on the cache, but more and bigger registers gives you an immediate advantage that can't be replicated - some apps have speed gains just by recompiling. Also, 32-bits apps running on top of 64-bits are running in an emulated 32-bits environment and so they take a penalty just for that. It is true in practice that 32-bits is all you'll ever need and you won't notice the difference, but modern browsers would get a healthy boost in performance (yes, 15% matters).
keeperofdakeys 15y ago
Why don't we use 16 bit apps anymore, they worked? The answer is because the libraries they depend on are no longer 16 bit. Getting 32 bit code to work on a 64 bit system involves having BOTH the 32 and 64 bit versions of the library installed. Using which program you want to use, 64 or 32 bit, is not a choice like a window manager; you should use the one that is supported by your system. If your system is 64 bit, it supports 64 bit apps. The fact that it CAN run 32 bit apps is just an extra. And personally, yes, I could easily blow this limit if I allowed my normal browsing behavior to blossom (that is having lots of tabs I want to reference later and leaving them open).
mjb 15y ago
> Is there a reason to run a 64-bit browser? (Other than the fact that amd64 provides more GPRs?) Increased effectiveness of ASLR (Address space layout randomization) and PIE (position independent executables) is one such reason. Using ASLR and 64 bit pointers can make some common classes of attack much more difficult, and potentially infeasible. I don't think mainstream linux distributions take full advantage of them yet, though.

wladimir 15y ago

So that's another platform that doesn't support Flash. Flash feels like a dead end more and more.

nathanb 15y ago

I have a feeling that this will work like broadband to small towns. The major carriers are only marginally interested in making it work well right up until someone makes a move toward municipal broadband, and then suddenly everyone takes a great interest in providing service. Until there's a viable competitor in the Linux space, Flash on x64 will continue to be a choice between several bad solutions. The only thing that could change this would be if Arm CPUs started supporting the x64 instruction set. Then Android's position in the market would likely make a compelling business argument for a 64-bit Flash. I'm not holding my breath.

makmanalp 15y ago
Sort of, but not really. The problem is that we don't pick whether we're going to use Flash or an alternative. The website does. And you bet that a lot of websites also aren't going to care about the tiny 64 bit linux segment. "Competition" in this case would have to provide an exact drop-in replacement of Flash, which I don't think will happen soon. (The open flash replacements mostly sucked the last time I tried them.)
- nathanb 15y ago
  Sorry; by alternative I didn't mean HTML5 or Silverlight or whatever but whether to use gnash + Lightspark or an old, buggy 64-bit flash or 32-bit flash.
reemrevnivek 15y ago
x64 uses a complex instruction set, which has a huge number of instructions that can do non-primitive operations in one step. ARM uses a reduced instruction set, which limits the available operations to basic load, store, arithmetic (on register data only), and a couple jump/branch instructions. These design philosophies are incompatible. An x64 chip would be spinning its wheels, wasting power, if it tried to run ARM assembly. An ARM chip would have to virtualize a huge percentage of the operations that an x64 chip would do in a single instruction, and would be painfully slow, mitigating any power savings it might have. ARM will never run x64 binaries. Good thing you're not holding your breath. This is why we write portable code in higher-level languages that can be compiled for both architectures. Not sure that Android is a motivating factor for Adobe to produce code for desktop Linux, though. Virtualized x64 compatibility would be slower than ARM, and Flash is already a dog on Android.

brudgers 15y ago

>Adobe doesn't want me to run Flash on 64 bit linux? It is hardly surprising that a large company doesn't see much ROI in tailoring a consumer oriented product for a tiny market segment. Given that Flash Player is losing relative and perhaps absolute web presence and the frequency with which Adobe must patch it for security vulnerabilities, creating a version for the tiny minority of consumers who use 64 bit linux for browsing doesn't make a lot of sense from an economic standpoint. The fact that the beta wasn't being brought up to date is probably a reflection of market realities rather than any bias against the platform, and given that a reasonable workaround was available (i.e. a 32bit version), it is hardly surprising that the overall project was dropped.

icefox 15y ago
It depends upon what management has as their goal. If they want flash everywhere than they need to make sure it works on places like 64bit Linux. If they are in the final days of the product (which it seems like they are) they just trying to milk it for what it is worth before it dies (i.e. make sure those XP users are not too unhappy).
- brudgers 15y ago
  Given that there is a viable option for 64 bit Linux users (i.e. 32 bit browsers), the only practical result from the development of a 64 bit Linux version of Flash Player is to placate a handful of zealots not a significant market segment. It is inevitable that Flash will not be everywhere - it will not even be on a significant portion of mobile devices, e.g. iphones.
  - greyfade 15y ago
    But why no 64-bit support on Windows or Mac OS X, where 64-bit is on track to become the norm? The lack of 64-bit for Linux is just a symptom of what seems to be a problem at Adobe.
    - brudgers 15y ago

danieldk 15y ago

I wonder why nspluginwrapper is not mentioned, which supports the use of 32-bit plugins with a 64-bit browser. In fact, when installing /flashplugin-nonfree/ on Ubuntu x86_64 it will nspluginwrapper. It's not ideal, but works fine for casual Flash website use.

riledhel 15y ago
As the article mentions, there's also a "preview" for 64-bit linux flash plugin. It's called "Square", runs fairly ok and it's available at http://www.adobe.com/devnet/flashplayer.html http://www.adobe.com/devnet/flashplayer.html Last version available is 10.3.162 or something like that...
- keeperofdakeys 15y ago
  No, nsplugin wrapper allows you to run the 32 bit plugin on a 64 bit system with 64 bit apps. I haven't had that much luck with it, too much stuttering on my machine.
  - riledhel 15y ago
    I know, I was trying to highlight there's another option from Adobe itself. I found it after trying to use the nsplugin wrapper itself and failed to do so.

yalogin 15y ago

Well Silverlight still does not work on 64 bit macs. It prompts me to restart the browser in 32-bit mode everytime.

stephen_g 15y ago
People use Silverlight? I'm actually being serious - I don't have it installed on any of my computers and I've never been to a site that asked me to download it... But perhaps that's because it's mostly used for video streaming and in Australia we don't get any sites like Netflix, Hulu etc.
- sixtofour 15y ago
  Netflix is why I have Silverlight on my Windows partition.

olefoo 15y ago

Adobe is not allowed to set standards in my world. If my main daily experience of dealing with your company is cursing at you when I restart software I feel forced to use (npviewer.bin), I'm probably going to look for alternatives to your other software as well.