Before you knock my scheme, please tell me how you would do the following without it: 1. Install 32-bit binaries of programs that don't work in 64-bit (you already said how to do this). However, attempted installation of Wine Rack on the 64-bit side complained an AWFUL lot, and could have hosed half my system RPMs. It installed without a wimper on the 32-bit side. 2. Make the machine look like a 32-bit system. Linux32 does this sort of. But it absolutely does not obsolete my suse32; suse32 doe as a lot more. Linux32 seems to change the environment globally, rather than just for one process. Linux32 also doesn't do anything about giving access to 32-bit files. 3. Compare a 32-bit and 64-bit version of the same program. 4. Compile 32-bit programs. Yes, there's the -m32 switch. But I've seen a LOT of people complain they couldn't get linking to work. And how much fiddling do you have to do with your configure script before you get it working? I can just say "suse32 konsole" and then, along with linux32, have a standard 32-bit system I know will work for generating 32-bit binaries without any cross compiler garbage. -- Bob
As for starting with 32bit personality we include the "linux32" program, obsoleting your posted suse32.c ;)
Which also has the advantage of not being setuid, and not requiring chroot magic, which creates headaches for instance with the /proc filesystem. And if your program.rpm really requires 32bit libs we don't provide already, you can install rpms for those too usually, or at least the shared lib files, which won't conflict because of being placed in */lib instead of */lib64 .