

Adobe doesn't want me to run Flash on 64 bit linux? - timclark
http://broadcast.oreilly.com/2011/06/one-year-later-adobe-abandons.html

======
brudgers
> _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
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
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
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
The same solution to the Flash on 64 bit browser issues which applies to Linux
applies to Windows as well - running a 32 bit browser is hardly a big deal.

The reasons for a lack of 64 bit OSX support are left as an exercise for the
reader.

------
wladimir
So that's another platform that doesn't support Flash.

Flash feels like a dead end more and more.

------
nathanb
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
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
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.

------
dmm
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.

~~~
bad_user

         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
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.

~~~
bad_user

         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).

~~~
dmm
>No you haven't.

In my top post I said:

> Other than the fact that amd64 provides more GPRs?

You should read what you're replying to.

> Also, 32-bits apps running on top of 64-bits are running in an emulated
> 32-bits environment

That's bullshit, at least on AMD64. "Because the full 32-bit instruction set
remains implemented in hardware without any intervening emulation, existing
32-bit x86 executables run with no compatibility or performance penalties" [0]

> but modern browsers would get a healthy boost in performance

Have you tested this?

[0] <http://en.wikipedia.org/wiki/X86-64>

~~~
cube13
>That's bullshit, at least on AMD64. "Because the full 32-bit instruction set
remains implemented in hardware without any intervening emulation, existing
32-bit x86 executables run with no compatibility or performance penalties" [0]

Which is true if you're running a 32-bit kernel on top of the 64-bit
processor.

If you're running a native 64-bit kernel, then the kernel needs a 32-bit
emulated layer that runs between the native kernel and the userland
application that handles virtual memory address translations(32-bit
executables are still limited to 4 gigs of RAM, but can be physically located
anywhere), system call translations, etc. That's a potential performance hit.

~~~
copper
You also need to keep 32-bit and 64-bit shared libraries, and then keep them
(more or less) in sync - admittedly, linux distros do manage that more or less
invisibly.

Mind you, when it comes to nvidia cards and the claims that newer versions of
flash make about hardware video decoding, it's not funny anymore.

------
danieldk
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
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> Last version available is
10.3.162 or something like that...

~~~
keeperofdakeys
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
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.

------
olefoo
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.

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

~~~
stephen_g
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
Netflix is why I have Silverlight on my Windows partition.

