[Tfug] 32-bit browser plugins on 64-bit OS

[Rich]

Hi John,

On Oct 27, 2008, at 5:27 pm, John Gruenenfelder wrote:

> On Mon, Oct 27, 2008 at 07:44:14AM -0700, Rich wrote:
>> First option: nspluginwrapper
>> So far, I have the 64-bit Firefox, with some 64-bit plugins, plus
>> nspluginwrapper, which provides a platform for 32-bit plugins on  
>> 64-bit
>> browsers.
>>
>> Acroread, flash, and helix work fine. But the 32-bit java plugin  
>> doesn't
>> work. I get something similar to this (not at the box right now)
>>
>>   # nspluginwrapper -i <path-to-java-plugin>
>>   This is not a valid NPAPI plugin
>>
>> I know the next version of Java is supposed to include a 64-bit  
>> plugin.
>> Great. So in six months time I'll stop asking...
>
> As far as I know, Java's plugin does not work with nspluginwrapper  
> and there don't appear to be any plans to make it work.
Yep.

> But, the latest Java packages, not sure if it is just GCJ or a  
> combination of that and OpenJDK-6, come with a working plugin.  On  
> Debian and Ubuntu the package is called icedtea-gcjwebplugin.  I've  
> used it recently on some Ubuntu machines and it worked just fine...  
> which makes me wonder why it's taking Sun so long with their plugin.
Thanks. I'll give that some thought.

>> Question 4 (marked philosophical/OT): Why bother with 64-bit  
>> browsers at
>> all? The point of 64-bit apps is to gain access to >4GB of RAM.  
>> But if
>> your browser is using more than 4GB of RAM, there's a problem, right?
>
> I'm assuming this is for system consistency and to avoid the need  
> of having two copies of every library installed, one for 32bit and  
> one for 64bit.  Just as they are different on disk, they'll be  
> different in memory so they can't be shared thus increasing memory  
> usage.
I don't think it's this reason, because GTK+ is installed as both 32-  
and 64-bit on a 64-bit system. There's plenty of other examples...
  for n in $( find /usr/lib ) ; do ls $( echo $n | sed -e 's/ 
^.usr.lib/%64/' ) ; done (or something like that)

> Shared libraries and a desire to not maintain two of everything  
> (or, most
> everything) for a single system is, I think, enough of an advantage  
> to warrant
> keeping a system all 32bit or all 64bit (at least, close to that).
Definitely, but a 64-bit system must be 32-bit compatible; at least  
minimally. "Minimal" can be quite huge.

> Early in the 64bit transition on Linux there was some talk about  
> designing a merged system where the directory layout and package  
> manager were aware of 32/64 bit versions of things and kept them  
> straight (the linker can already do this).  I believe Solaris and  
> IRIX (and proabably others) do this.  But, that idea never seemed  
> to gain traction, probably because it was to much work for the  
> gains to be had.  Also, by the time 64bit CPUs have arrived to the  
> masses (i.e. now) you can reasonably expect most vendors to ship  
> 64bit binaries "Real Soon Now".  This was definitely not the case  
> when the first 64bit Sun CPUs arrived, for example.
Yeah, the enterprise Linuxes tend to be a year or two behind the  
stable OSs, which tend to be a year or two behind the breeding edge  
stuff. Of course, the most vocal users want this stuff now... which  
isn't a problem, if I can make it work!

R.


> -- 
> --John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
> Try Weasel Reader for PalmOS  --  http://weaselreader.org
> "This is the most fun I've had without being drenched in the blood
> of my enemies!"
>         --Sam of Sam & Max
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org