Flash for amd64

[Todd Denniston]

D. Hugh Redelmeier wrote, On 03/05/2008 03:39 PM:
> | From: Tom Horsley <tom.horsley at att.net>
> 
> |  I find the nspliginwrapper helper app sitting in 100% cpu loops
> | most of the time with my firefox frozen. Using 32 bit firefox and
> | no nspluginwrapper works much better for me (and I actually find it
> | convenient to be able to run 64 bit firefox and know that annoying flash
> | content won't appear :-).
> 
> I used to do that too.  But the greatest inconvenience was that if you
> had ff64 running, any attempt to run ff32 would just hand off the
> request to ff64.  Too smart.
> 
> Another manifestation: if I try to run ff remotely, the remote ff just
> hands off the request to my local ff.  And, if that request involved
> file://, it will whine about there being no such file.  Too smart.
> 
> The problem is in the script /usr/bin/firefox.  I'm too lazy to hack
> it.  I don't actually know the consequences of two instances both
> writing stuff into ~/.mozilla
> 

How are you sure it is in the firefox script?
I just took a look at it (quickly) and did not see anything obvious that would 
make the script do a choice for run a new copy vise connect to the running copy.

I too find it annoying that ff will not allow you to start a new separate 
copy, and I only run in 32 bit land.
IIRC mozilla had an option to make it use the running copy, but it was not the 
default, and it was a visible option (mozilla --help would show it) that the 
user could choose.  too bad that they have decided to A) make it the default 
AND B) not give a switch to choose the other direction.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter