On Sat, Nov 20, 2010 at 3:25 PM, Lars Hecking lhecking@users.sourceforge.net wrote:
Possibly. Or possibly not. On a closely related topic, can you comment on whether or not it's a good idea to install the nspluginwrapper rpms on x86_64? They seem to be fundamentally broken.
I don't think you need it anymore with FF 3.6.
Mike Fedyk writes:
On Sat, Nov 20, 2010 at 3:25 PM, Lars Hecking lhecking@users.sourceforge.net wrote:
??Possibly. Or possibly not. On a closely related topic, can you comment on ??whether or not it's a good idea to install the nspluginwrapper rpms on x86_64? ??They seem to be fundamentally broken.
I don't think you need it anymore with FF 3.6.
It's broken regardless. Try this: install Oracle's java and link the plugin into /usr/lib64/mozilla/plugins. Run firefox and go to about:plugins. No java in sight. Then close firefox and, as root, link the java plugin into /usr/lib64/mozilla/plugins-wrapped. Run firefox again and go to about:plugins. No java. Close firefox and look at /usr/lib64/mozilla/plugins-wrapped; the java plugin link is now gone.
There are several unexpected features here. First, the firefox wrapper uses .../plugins-wrapped instead of .../plugins if mozilla-plugin-config is found, i.e. nspluginwrapper is installed. So no matter what you think you're installing into .../plugins has no effect whatsoever. Secondly, mozilla-plugin-config removes the java plugin from plugins-wrapped and it is unclear why - in typical Linux fashion, there is no documentation on what exactly it does, how it does it, and there seems no way to configure it. Third, why is mozilla-plugin-config messing around in system dirs in the first place when a user runs firefox? Here's the answer:
$ ll /usr/lib64/nspluginwrapper/plugin-config -rwsr-xr-x 1 root root 60432 Jul 17 2008 /usr/lib64/nspluginwrapper/plugin-config $
SUID? WTF? This is on CentOS 5.4 btw, but the firefox wrapper hasn't changed in 5.5.
Essentially, this behaviour renders all the well-meaning firefox+java setup guides useless. And unless I'm mistaken, nspluginwrapper is needed for 32-bit binary blobs like flash and adobe.
Next, I haven't yet successfully managed to get java to work on x86_64 with the 32-bit browser. Installing the 32-bit plugin from the corresponding jre doesn't seem to be enough.
--------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---------------------------------------------------------------
On Nov 21, 2010, at 8:10 AM, lhecking@users.sourceforge.net wrote:
Mike Fedyk writes:
On Sat, Nov 20, 2010 at 3:25 PM, Lars Hecking lhecking@users.sourceforge.net wrote:
??Possibly. Or possibly not. On a closely related topic, can you comment on ??whether or not it's a good idea to install the nspluginwrapper rpms on x86_64? ??They seem to be fundamentally broken.
I don't think you need it anymore with FF 3.6.
It's broken regardless. Try this: install Oracle's java and link the plugin into /usr/lib64/mozilla/plugins. Run firefox and go to about:plugins. No java in sight. Then close firefox and, as root, link the java plugin into /usr/lib64/mozilla/plugins-wrapped. Run firefox again and go to about:plugins. No java. Close firefox and look at /usr/lib64/mozilla/plugins-wrapped; the java plugin link is now gone.
There are several unexpected features here. First, the firefox wrapper uses .../plugins-wrapped instead of .../plugins if mozilla-plugin-config is found, i.e. nspluginwrapper is installed. So no matter what you think you're installing into .../plugins has no effect whatsoever. Secondly, mozilla-plugin-config removes the java plugin from plugins-wrapped and it is unclear why - in typical Linux fashion, there is no documentation on what exactly it does, how it does it, and there seems no way to configure it. Third, why is mozilla-plugin-config messing around in system dirs in the first place when a user runs firefox? Here's the answer:
$ ll /usr/lib64/nspluginwrapper/plugin-config -rwsr-xr-x 1 root root 60432 Jul 17 2008 /usr/lib64/nspluginwrapper/plugin-config $
SUID? WTF? This is on CentOS 5.4 btw, but the firefox wrapper hasn't changed in 5.5.
Essentially, this behaviour renders all the well-meaning firefox+java setup guides useless. And unless I'm mistaken, nspluginwrapper is needed for 32-bit binary blobs like flash and adobe.
Next, I haven't yet successfully managed to get java to work on x86_64 with the 32-bit browser. Installing the 32-bit plugin from the corresponding jre doesn't seem to be enough.
Java has always been a challenge. I run x86_64 workstations with CentOS current releases of firefox. I have had some luck with 64 bit firefox and various plugins but found adobe flash is pretty poor for 64 bit thus if flash is needed in your browser it lays to go 32 bit for firefox. Thus you need 32 bit plugins for java and flash etc. After firefox 3.5 they decided to change the file name for java. Goggle has some help. If you need specifics the CentOS wiki stuff does work as indicated. HTH
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, Nov 21, 2010 at 12:34 PM, Rob Kampen rkampen@kampensonline.com wrote:
Java has always been a challenge. I run x86_64 workstations with CentOS current releases of firefox. I have had some luck with 64 bit firefox and various plugins but found adobe flash is pretty poor for 64 bit thus if flash is needed in your browser it lays to go 32 bit for firefox. Thus you need 32 bit plugins for java and flash etc. After firefox 3.5 they decided to change the file name for java. Goggle has some help. If you need specifics the CentOS wiki stuff does work as indicated. HTH
I've been devoting some time to JPackage, where the upstream RPM's tha RHEL uses get developed for Java components.
Integrating clean Java installations is a bloody nightmare, due to different package managers ideas of how to do things, and subtle workaround that each of them apply. JPackage's version 5 is pretty clean, but needs updates to get Sun/Oracle's JDK in place cleanly. (I've published some .spec files for just that.)
RHEL 6, and the JPackage 6 release, seems to be using OpenJDK instead. I welcome this, it's much more cleanly built and installable for RHEL based systems, but is fairly difficult to backport to RHEL 5. But with RHEL 6 out, and CentOS 6 on the horizon, I'm looking forward to much cleaner Java integration.
-
lhecking＠users.sourceforge.net -
Mike Fedyk -
Nico Kadel-Garcia -
Rob Kampen