On 04/22/2011 04:16 AM, JD wrote:
Is nspluginwrapper needed for i686 platforms?
have a look at;
http://plugindoc.mozdev.org/linux-amd64.html
for a better understanding of what nspluginwrapper is about.
hth.
later.
On 04/22/11 01:55, g wrote:
On 04/22/2011 04:16 AM, JD wrote:
Is nspluginwrapper needed for i686 platforms?
have a look at;
http://plugindoc.mozdev.org/linux-amd64.html
for a better understanding of what nspluginwrapper is about.
hth.
later.
Right. The blub says:
nspluginwrapper allows you to use Netscape compatible (NPAPI) plugins on platforms that they were not built on - in this instance, using 32bit browser plugins with x86_64 browsers. This is beta software, and licensed under the GNU General Public License (GPL).
-----------------------
As I said, my OS is 32 bit, and all my rpms are 32 bit. I have no 64 bit anything. I was just wondering why I have nspluginwrapper installed, as I do not recall deliberately installing it.
On 04/22/2011 03:13 PM, JD wrote: <>
As I said, my OS is 32 bit, and all my rpms are 32 bit. I have no 64 bit anything.
actually, you stated "Is nspluginwrapper needed for i686 platforms?", which infers 32 bit. [just kidding with you. no offense intended]
I was just wondering why I have nspluginwrapper installed, as I do not recall deliberately installing it.
if you check back on mozdev page, you will see what all nspluginwrapper is used with/for.
therefore, it may well be that if you have any of them installed, nspluginwrapper would be a dependency and yum/rpm does not check to see if you are running 32 or 64 bit.
further, if you tried an uninstall of the packages that use nspluginwrapper, you would see nspluginwrapper listed in what is to be removed.
this is my reasoning. not a cold hard fact from reading or trying.
also, i am running 32 bit and nspluginwrapper is installed.
hth.
On 04/22/11 09:05, g wrote:
On 04/22/2011 03:13 PM, JD wrote: <>
As I said, my OS is 32 bit, and all my rpms are 32 bit. I have no 64 bit anything.
actually, you stated "Is nspluginwrapper needed for i686 platforms?", which infers 32 bit. [just kidding with you. no offense intended]
I was just wondering why I have nspluginwrapper installed, as I do not recall deliberately installing it.
if you check back on mozdev page, you will see what all nspluginwrapper is used with/for.
therefore, it may well be that if you have any of them installed, nspluginwrapper would be a dependency and yum/rpm does not check to see if you are running 32 or 64 bit.
further, if you tried an uninstall of the packages that use nspluginwrapper, you would see nspluginwrapper listed in what is to be removed.
this is my reasoning. not a cold hard fact from reading or trying.
also, i am running 32 bit and nspluginwrapper is installed.
hth.
I uninstalled it and there was no complaint of any dependency. It must have been a remnant from F13 when performed the upgrade to F14, and the next yum update simply installed updated the F13 version to F14.
Thanx.
JD
JD wrote:
I uninstalled it and there was no complaint of any dependency. It must have been a remnant from F13 when performed the upgrade to F14, and the next yum update simply installed updated the F13 version to F14.
Without nspluginwrapper, Firefox plugins run in the same process as Firefox itself. This means that if a Firefox plugin crashes, it takes down the entire browser.
With nspluginwrapper, Firefox plugins run in separate processes. This should mean that a plugin crash only takes down the plugin, which can be restarted (for example, by reloading the page).
Presumably, this also means that the plugins can run on separate hardware threads¹: whether this makes any difference to browser responsiveness is something I have neither investigated nor seen anyone else investigate.
Hope this helps,
James.
¹ by which I include separate cores
On 04/22/2011 06:17 PM, James Wilkinson wrote: <>
Without nspluginwrapper, Firefox plugins run in the same process as
<>
With nspluginwrapper, Firefox plugins run in separate processes.
<>
ahhh. yes. you refreshed the brain cells. [should stick this time] this was discussed in a 'support-firefox@lists.mozilla.org' thread last year.
Presumably, this also means that the plugins can run on separate hardware threads¹: whether this makes any difference to browser responsiveness is something I have neither investigated nor seen anyone else investigate.
one would think so. this ability was not discussed.
On 04/22/11 11:17, James Wilkinson wrote:
JD wrote:
I uninstalled it and there was no complaint of any dependency. It must have been a remnant from F13 when performed the upgrade to F14, and the next yum update simply installed updated the F13 version to F14.
Without nspluginwrapper, Firefox plugins run in the same process as Firefox itself. This means that if a Firefox plugin crashes, it takes down the entire browser.
With nspluginwrapper, Firefox plugins run in separate processes. This should mean that a plugin crash only takes down the plugin, which can be restarted (for example, by reloading the page).
Presumably, this also means that the plugins can run on separate hardware threads¹: whether this makes any difference to browser responsiveness is something I have neither investigated nor seen anyone else investigate.
Hope this helps,
James.
¹ by which I include separate cores
That is interesting info. I will experiment without it, and if the crash of, say flash plugin crashes FF, then I will re-install it.
Cheers,
JD
On 04/22/2011 07:31 PM, JD wrote: <>
if the crash of, say flash plugin crashes FF, then I will re-install it.
latest flash is 10.2.159.1.
anything prior has security and crash problems.
On 04/22/11 13:29, g wrote:
On 04/22/2011 07:31 PM, JD wrote: <>
if the crash of, say flash plugin crashes FF, then I will re-install it.
latest flash is 10.2.159.1.
anything prior has security and crash problems.
Yup! That's what I have. Let's hope Adobe keeps it free of security holes.
On Fri, 2011-04-22 at 20:29 +0000, g wrote:
On 04/22/2011 07:31 PM, JD wrote: <>
if the crash of, say flash plugin crashes FF, then I will re-install it.
latest flash is 10.2.159.1.
anything prior has security and crash problems.
---- the implication being that the specific version mentioned doesn't have known security and crash problems which I think both have been found to be incorrect implications.
Craig
On 04/22/11 14:04, Craig White wrote:
On Fri, 2011-04-22 at 20:29 +0000, g wrote:
On 04/22/2011 07:31 PM, JD wrote: <>
if the crash of, say flash plugin crashes FF, then I will re-install it.
latest flash is 10.2.159.1.
anything prior has security and crash problems.
the implication being that the specific version mentioned doesn't have known security and crash problems which I think both have been found to be incorrect implications.
Craig
Well, have any security exploits been detected or publicized in latest version?
On 04/22/2011 09:04 PM, Craig White wrote: <>
the implication being that the specific version mentioned doesn't have known security and crash problems which I think both have been found to be incorrect implications.
i do not know what 'implications' you are implying, but i believe this will show what is correct:
+++
====== Red Hat Security Advisory
Synopsis: Critical: flash-plugin security update Advisory ID: RHSA-2011:0451-01 Product: Red Hat Enterprise Linux Extras Advisory URL: https://rhn.redhat.com/errata/RHSA-2011-0451.html Issue date: 2011-04-18 CVE Names: CVE-2011-0611 ======
1. Summary:
An updated Adobe Flash Player package that fixes one security issue is now available for Red Hat Enterprise Linux 5 and 6 Supplementary.
The Red Hat Security Response Team has rated this update as having critical security impact. A Common Vulnerability Scoring System (CVSS) base score, <snip>
3. Description:
The flash-plugin package contains a Mozilla Firefox compatible Adobe Flash Player web browser plug-in.
This update fixes one vulnerability in Adobe Flash Player. This vulnerability is detailed on the Adobe security page APSB11-07, listed in the References section. Specially-crafted SWF content could cause flash-plugin to crash or, potentially, execute arbitrary code. (CVE-2011-0611)
All users of Adobe Flash Player should install this updated package, which upgrades Flash Player to version 10.2.159.1.
4. Solution:
Before applying this update, make sure all previously-released errata relevant to your system have been applied.
<snip>
7. References:
https://www.redhat.com/security/data/cve/CVE-2011-0611.html https://access.redhat.com/security/updates/classification/#critical http://www.adobe.com/support/security/bulletins/apsb11-07.html
+++
are do you know something red hat does not?
g wrote:
latest flash is 10.2.159.1.
anything prior has security and crash problems.
Craig White objected:
the implication being that the specific version mentioned doesn't have known security and crash problems which I think both have been found to be incorrect implications.
JD asked:
Well, have any security exploits been detected or publicized in latest version?
It is a truism that every non-trivial program has bugs in it. Adobe Flash player merely seems to have way more than its fair share.
Since it is intended to run programs from non-trusted sources, it is inevitable that many of these bugs will have security implications.
After too many security vulnerabilities, too many fixes, and too many zero-day exploits going unfixed for too long, running Flash makes it way too likely that you are vulnerable to exploits that various criminals know about and you don’t.
At one recent security conference: Paul Baccus, a senior threat researcher at Sophos, asked if anyone from Adobe was in the session. After a pause a voice at the back shouted “Of course not, it’s a security conference.” – Graham Cluley, senior technology consultant at Sophos, quoted in http://theinquirer.net/inquirer/news/1736408/insecurity-experts-banish-pdf
James.
On 04/23/11 06:21, James Wilkinson wrote:
g wrote:
latest flash is 10.2.159.1.
anything prior has security and crash problems.
Craig White objected:
the implication being that the specific version mentioned doesn't have known security and crash problems which I think both have been found to be incorrect implications.
JD asked:
Well, have any security exploits been detected or publicized in latest version?
It is a truism that every non-trivial program has bugs in it. Adobe Flash player merely seems to have way more than its fair share.
Since it is intended to run programs from non-trusted sources, it is inevitable that many of these bugs will have security implications.
After too many security vulnerabilities, too many fixes, and too many zero-day exploits going unfixed for too long, running Flash makes it way too likely that you are vulnerable to exploits that various criminals know about and you don’t.
At one recent security conference: Paul Baccus, a senior threat researcher at Sophos, asked if anyone from Adobe was in the session. After a pause a voice at the back shouted “Of course not, it’s a security conference.” – Graham Cluley, senior technology consultant at Sophos, quoted in http://theinquirer.net/inquirer/news/1736408/insecurity-experts-banish-pdf
James.
James, you make a good case of security vulnerability for a large class of software, not just adobe. I am just very surprised that there is no well working open source replacement that does not also hog the cpu. I had tried the gnu flash, and it was not up for the task.