On 4/4/07, Ira Abramov <[EMAIL PROTECTED]> wrote:
the flash player is statically compiled and runs outside the weasel process' context (which I'm pretty sure it's not, but I never checked)
There's something called nspluginwrapper[1], which allows moving plugins out of the browser process context. This allows you to keep running a 64-bit browser binary + 32-bit plugins. Alternatively, it's very likely that more user-friendly distros choose to ship browsers and other programs still dependent on 32-bit libraries as 32-bit binaries only. (Same goes for media players which might load Win32 codecs.) Even if not a default, Fedora is likely to still ship a i386 Firefox RPM on the x86-64 discs. And really, 32-bit or 64-bit, it really doesn't matter much. Myself, I'm only using 64-bit as an 'early adopter', cause I like making broken things work, submitting patches and learning new instruction sets. When I first got on Fedora Core x86-64 two years ago, many prominent programs weren't 64-bit clean: for example, I spent a few days going over NoMachine's NX and porting it. To this day I'm not sure what they did with my patch :/ Nowadays Sun has a 64-bit Java JIT and so does Mono, but Adobe's Flash is not yet there (rumor is they have a JIT for ActionScript and lots of hand-tuned asm code). Another reason for apps to break is not being aware of "multiarch" deployments, i.e. one that has /usr/lib and /usr/lib64. A final note on performance: not only are pointers longer, but you'll also end up having both 32-bit and 64-bit sets of libraries (think libc+glib+gtk+qt+..., twice) competing over your memory (if you'll end up having to run some 32-bit apps), so you might need some more RAM. [1] http://gwenole.beauchesne.info/projects/nspluginwrapper/
