Tonko Mulder <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 21 Nov 2008 07:00:24 +0100:
> I was wondering since flash has been released for x86_64 and simply > can't find a program on my laptop which uses emul-linux-x86-* If I could > just move to a no-multilib profile. > > As I've read, life get's easier with the no-multilib profile. :) The big question is whether you need anything 32-bit only, which is pretty much proprietary stuff. I'm on the no-multilib profile, but the question was easy for me since I don't do proprietaryware. In addition to flash, which should now cease to be a 32/64-bit issue, there's also various codecs, etc. While there's 64-bit options for many codecs (I've personally had better luck with xine-lib and its many USE flags than mplayer, YMMV) including normal wmv, DRMed formats (including DRMed wmv) and real can be problems. Specifically for xine-lib, the real, vidix and win32codecs USE flags are profile-masked because they are 32-bit only. IIRC there's a win64codecs package but I'm not sure of its status The other big problem would be proprietary games. If you prioritize being able to play them very highly, you'll almost certainly want to stay multilib. HOWEVER, it's worth noting that there *IS* an alternative 32-bit solution to multilib. It's more work, but in some ways it's truer to Gentoo's roots. This is the 32-bit chroot solution sometimes mentioned. With multilib, glibc and gcc (the big ones, also sandbox and binutils) are compiled for both 64-bit and 32-bit support, but pretty much everything else is installed from precompiled binaries. This includes all the emul- linux-x86-* libraries and the various *-bin executables (mozilla-firefox- bin, mplayer-bin, etc) packages. With a 32-bit chroot solution (for which there's Gentoo documentation if interested), you start from a standard x86 (32-bit) stage tarball and do much of a 32-bit installation as if from scratch, so after you're done you have almost an entire 32-bit installation paralleling your 64-bit installation (but missing system services like syslog, etc, since the 64-bit main system side provides those services, all compiled from sources, and you maintain them both as you normally would. As I said, rather more work, but it's certainly a valid option, and really, truer to the Gentoo norm of the user controlling as much as possible (while still automated) of the installed software, including the CFLAGS used to compile it and the dependencies (USE flags) it builds against. Multilib, while much less work, is both more complex to implement and much less under installed system sysadmin control. The main point in bringing up the 32-bit chroot option here, however, is to note that rejecting multilib doesn't /necessarily/ mean rejecting 32- bit on the system. Rather, multilib is the middle ground between no 32-bit support (no-multilib profile without the 32-bit chroot) and the full 32-bit chroot option with all the trimmings. Meanwhile, no-multilib has some serious benefits, regardless of whether you do the 32-bit chroot or not. Multilib being as it is, a mainly 64- bit system with 32-bit add-ons arranged to allow 32-bit to work as well as possible under the circumstances, it involves a number of compromises and is quite complex, complicating the system considerably. Regardless of whether one is keeping the 32-bit and 64-bit sides more cleanly separated by choosing a full 32-bit chroot on the one hand, or has decided they can do without 32-bit in general on the other, the result of choosing the no-multilib profile is a much cleaner layout, because the 64- bit side doesn't have to worry about 32-bit at all (with the single exception of the kernel's 32-bit emulation option). No double-compiling both the 32-bit and 64-bit parts of gcc or glibc in the same package means broken 32-bit can't block the successful completion and installation of the 64-bit package. From my experience, that alone is the biggest problem people have with those packages on multilib profiles, and a gcc or glibc that can't be upgraded is a HUGE problem that can be a lot of hassle to solve, so eliminating the single biggest cause of that is a BIG deal! No ld having both 32-bit and 64-bit library search paths to worry about and maintain, etc. Less complexity and removing the single biggest cause of broken gccs translates directly to less hassle maintaining your installation. =:^) As always, it's your system, so the decision is ultimately yours. There's serious tradeoffs, benefits and drawbacks to either multilib or nomultilib, 32-bit chroot or not, and no single solution is going to be best for everybody, but given a reasonable understanding of the benefits and drawbacks of each, most Gentoo/amd64 users should have little problem deciding what's best for their particular situation, based on just how much 32-bit they use and whether they prefer the less complex but more powerful 32-bit chroot or the less hassle multilib, should they decide they need to keep 32-bit support. Most but not all 32-bit-only programs are available only as binary-only proprietaryware, so how much of that you may use plays the biggest part in whether you need 32-bit or not, but there's still the occasional open source program that hasn't been ported yet, and of course for some usage, in-house-only apps that may not have been ported, and these may play some albeit increasingly small part in the consideration as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
