[Foresight-devel] Re: x86 or x86_64 firefox...

[Justin M. Forbes]

On Fri, 2008-02-01 at 15:53 -0500, Ken VanDine wrote:
> We need to discuss the importance of shipping x86_64 firefox.  It seems
> to be just to complicated, and I worry long term it will be a problem.
> Doing my own comparisions, x86_64 firefox uses allot more memory that
> x86 and the plugins do not work natively.  Is it really worth it?
> 
> Thoughts?

I figured I would chime in here, as I have been running 64bit desktops
for several years now, and am generally a big proponent of keeping as
much 64bit as possible.  Let's face it, 64bit is generally nice, and
there are many reasons that you want a 64bit userspace on x86_64 (as
opposed to ppc/sparc/etc where you want as much 32bit as possible).
That said, multilib support works great in conary, and thunking layers
are historically a nightmare.  I have to say that nspluginwrapper is no
exception.  
While the first thing I did on my desktop was to replace firefox with
the 32bit version, I did actually give things a go on both my laptop and
my wife's laptop with 64bit firefix + nspluginwrapper.  The first thing
I noticed was that the already resource hungry flashplayer plugin was
much worse under nswrapper.  This is particularly bad when flash is a
mediaplayer first and foremost.  Over time I started to notice that some
websites would work perfectly on my desktop, but not on my wife's
laptop.  Eventially I replaced her browser with the 32bit version as
well.
Now updating firefox from x86_64 to x86 is fairly simple in conary.
Most if not all of the 32bit deps are already installed in foresight 2,
but things still didn't work as they should on my wife's laptop.  It
seemed that even the 32bit browser was loading a 32bit nspluginwrapper
plugin and using the wrapped version of 32bit plugins on a 32bit system.
The way around that was to uninstall nspluginwrapper and manually remove
%(libdir)s/xulrunner/plugins-wrapped/.  And of course anytime foresight
updates firefox, users who have removed the 64bit version and updated
the 32bit version will have some issues (may be a conary bug).
All of this demonstrates a couple of things:

a) nspluginwrapper is not as efficient as running the plugins
natively... by a long shot.
b) users migrating from 64bit firefox to 32bit firefox on their own may
still have issues if they have run the 64bit browser much. We shouldn't
ask them to debug what we should have gotten right in the first place.
c) nspluginwrapper probably shouldn't have a 32bit version installed on
any system.

I strongly recommend that we ship a 32bit firefox on the x86_64
foresight, with native 32bit mplayerplug-in, flashplayer, etc.  Shipping
a 32bit epiphany is more difficult because of deps, I will leave that up
to people who use epiphany.  It should be noted that the 32bit
mplayerplug-in works fine with a 64bit mplayer in a 32bit browser, since
all it really does it exec mplayer, there is no soname link there.
If we ever get to the time where flashplayer actually releases their
64bit native version (it has been in the pipeline for a long time now),
and find a native 64bit java plugin, perhaps it would be a good time to
readdress this, but for Foresight 2, I think 32bit is the way to go.

Justin