I have been using a couple of 64 bit Linux distributions (Red Hat and Novell) on an X86-64 box recently as my main desktop machine and have found a fairly severe usability flaw in these distributions especially with regard to generic desktop software development use.

The issue is that they do not offer very good 32 bit compatibility support.

Sure, they will run a 32 bit hello world binary just fine, but when it comes to more complex application support, they aren't set up right.

This issue is most easily apparent in a web browser. Since they use use a plugin architecture, and most plugins available for Linux are 32 bit plugins, running a 64 bit browser causes lots of problems. The problem also exists for other applications that use plugins - the ones I run into most frequently are scripting languages (i.e. Perl, Python etc.) using SWIG or other dynamically loaded extension libraries.

It seems to me that there are 3 potential solutions to this issue:

32 bit user layer on 64 bit low level stuff
This is the approach that Sun and HP took. They offer 64 bit support only where it is needed. Run file /bin/ls on a 64 bit sun box, and you will find that it is a 32 bit binary. The advantage to this is that any application that used to run on the Sun 32 bit box, still installs and runs on a 64 bit box no questions asked. 64 bit apps run if they can find the right supporting libraries installed, but since the real 64 bit applications are not so common, these dependencies are fairly easy to manage. Another advantage is that the 32 vs. 64 problem is very well bounded (you just need kernel and some low level library support to have a fully functioning 64 bit workstation). I can't think of any disadvantages to this solution except that when you run 32 bit xclock, you have to worry about the wasted bits that you paid for that just aren't getting used. For something like xclock, that runs all the time, a lot of bits are wasted with every tick of the clock! Worrying about all these wasted bits seems very important to people for some reason.

Incremental 32 bit support
If there were an easy way to install 32 bit browsers and 32 bit scripting languages on 64 bit OS distributions, the above problems would be solved as well. Other problems would not be solved: i.e. you still have to make sure that you are getting the 32 bit perl when you want to use a 32 bit plugin and you have to get the 64 bit perl when you want to use a 64 bit plugin. This seems to be an open ended solution that will take quite a while to get through, but seems like the direction things are headed for libraries. No one seems to understand that the issue extends to executables when those executables support plugins. If that is the direction we have to take, it would be nice to see well supported 32 bit compat packages using the standard install formats for Firefox, Mozilla and all of the popular scripting languages (Perl, Python, TCL, Ruby). (i.e. 32 bit compatibility rpms that are easy to load on a 64 bit system and don't whine about missing dependencies that are only missing because of the 32/64 issue.)

Wait for the plugins - Save the Bits!
If you really worry a lot about wasted bits, then this is your preferred solution. No wasted bits because everything is 64 bit compatible. This approach applies more pressure to get Flash and other plugins ported to 64 bits. After all - those unused bits could start collecting somewhere inside the machine and really gunk things up!

Personally, I think approach 1 is the way to go, but the train has already left the station, and it didn't happen. If you do a distribution and haven't done a 64 bit version yet, think about this approach.

Approach 2 is within our grasp if the distributions will just start releasing some 32 bit executables - say anything that uses dlopen. Start off with Firefox, Mozilla, Perl, Python, Ruby, tclsh. Does anyone know of any pre-built RPMs that will do this? You can't just use the RPMs off from the 32 bit distributions because they will screw up your 64 bit stuff (yes, I have tried this; as I expected, it was a disaster). If you do a 64 bit distribution where everything is 64 bits, please add these 32 bit compat packages and post them somewhere.

Approach 3 will take a long time and I don't want to wait that long. There does seem to be very strong support for #3 however. Perhaps these folks will form a charitable society for prevention of bit cruelty and try to block approaches 2 and 3. I am hoping that practicality and usability win out, however.

It's not a problem with the 64-bit distributions, but rather a limitation of the application builds. They don't do mixed 64/32-bit.

If you want to use 32-bit plugins, simply install the 32-bit application. To do this, all you need to do is add the i386 repository to your yum configuration.

/etc/yum.repos.d/fedora-updates-i386.repo

[updates-i386-released]
name=Fedora Core $releasever - i386 - Released Updates
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/i386/
#mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc$releasever
enabled=0
gpgcheck=1


Then, for example:

yum remove firefox
yum --enablerepo=updates-i386-released install firefox.i386

You can now use any i386 plugins (like flash).

Thanks for the reply.

I have been using Red Hat 3 and Suse 9, they are not capable of making the type of installation you suggest using Fedora as an example. On Firefox, for example, they typically get tangled up with the version of Gnome that is available - trying to install the 32 bit gnome libraries in turn breaks lots of config file stuff.

Have more of the issues been worked out with respect to this issue on Red Hat 4? I can give what you suggest a try there. What Fedora Core are you using?

I'm using Fedora Core 3 on an Athon64 3200+, and the method worked on that distribution. It doesn't make a lot of sense to tie the web browser to the window manager (unless you're Microsoft, of course ).

Of course gnome isn't part of the window manager...

Any idea if similar antics can be tried on Python, Perl, etc? It makes more sense for those to have both sitting there side by side.

Sorry, desktop environment.

I haven't had a problem with those packages - the 64-bit versions haven't caused any incompatibilities, probably because they are interpreted.

As long as you stay with interpreted stuff, you will be fine. The problem comes when you use tools that dynamically load stuff.

I tried removing the 64 bit Firefox and installing 32 bit Firefox on RedHat 4 and it worked - so perhaps the distributions are getting this worked out. The scripting languages will not be as simple since I will really need both 32 and 64 bit versions I imagine. Perhaps a forced install and mv of conflicting elements, or are these packages designed to coexist?

For scripting languages (which are interpreted), there's no need. The 64-bit version shouldn't cause any compatibility uses. If you encounter any, let us know.

The scripting languages will cause problems when you use shared libraries. I was trying to try out something (Bram Moolenaar's Agide - www.a-a-p.org) that needed WxPython and I couldn't get a 64 bit version of WxPython to go with my 64 bit Python and couldn't install a 32 bit Python on RedHat 3 and so gave up on it. Lots of other stuff uses dynamically loaded libraries (a la dlopen) inside the scripting languages. When you do that, you aren't working inside the bounds of 'interpreted'.