[gentoo-amd64] Re: 64-bit or 32-bit?

[Duncan]

Anand Buddhdev posted <42D3A936.8060306@×××××.org>, excerpted below,  on
Tue, 12 Jul 2005 13:27:50 +0200:

> I'm getting a new AMD64-based computer, and I'd like to run gentoo on it.
> I have been doing a bit of reading about running linux on AMD64, and it
> seems that in general, it's not a problem. The main issues seem to be with
> firefox 32-bit plugins, and win32 codecs for use with mplayer. My reading
> seems to suggest that if I stick to firefox-bin and mplayer32, then I
> should be fine. However, I'd like to hear from people who're already using
> gentoo on amd64, and what their experience is. Is it simple to get these
> apps to work? Or was there a lot of frustration involved. I've used linux
> and BSD systems for a long time, so I'm used to hacking, and I'm not
> afraid to mess around with scripts and compilers. But I've reached a point
> when I'd just like to be able to install a system, and have it work.
> Fedora Core almost allows that, except that I'm a bit fed up of the
> multiple repository problems, and no proper way of picking and choosing
> what exactly I want. I could recompile some of the packages from SRPMS,
> and specify my choices. But I reckoned that if recompiling was the way to
> go, then I'd give gentoo a try.
>
> One of the choices I'm facing is whether to install gentoo 64-bit, or
> 32-bit. Installing 32-bit on the AMD64 would make life easy, but kind of
> defeats the purpose of having a 64-bit processor. Hence my request for
> opinions. Should I go 64-bit, or stay in the 32-bit world for now?

Wow!  Where to start?  ... Keep in mind that the following describes more
the issues you might come across, than the good things, so it's going to
seem FAR worse than it actually is.

Going 32-bit is slightly easier, as you mention, altho 64-bit is getting
more mainstream every day.  100% 32-bit mode uses the generally larger
amd64 cache (normally 1M L3 cache, compared to perhaps half that on most
32-bit only processors), but doesn't make use of the other strengths of
the amd64 architecture, the biggest one of which is probably the expanded
number of hardware registers available in 64-bit mode.  x86 has
traditionally been a rather register-limited arch, and the amd64 CPUs in
32-bit mode remain so for compatibility reasons, so the additional
registers only come into play in 64-bit mode.  OTOH, for many things,
unless you have more than 4G memory, 32-bit is quite enough and conserves
resources a bit better.  For that reason, on archs less register bound
than x86(32), the switch to 64-bit mode often has more downside for many
uses, than it does upside.  x86_64, however, due to those extra registers
only available in 64-bit mode and because x86(32) has always been register
bound, with a fairly limited number of them, tends to swing the balance
rather further in favor of 64-bit mode than with other archs -- 64-bit
performance is often markedly better than 32-bit performance of the same
source code on the exact same CPU and hardware, the only difference being
whether it's compiled with -m32 or -m64, 32- or 64-bit.  So... yes, I'd
say that while possible, installing only 32-bit Linux on AMD64 is indeed
wasting resources, to some extent.

...

You've obviously been doing your research, and correctly found that the
main issues tend to be in cases of binary-only releases of various plugins
and codecs.  If it's available in source-code form, it's generally
available for use in 64-bit mode on amd64.  The quote I have chosen for my
sig pretty well gives my position on proprietary binary-only code in the
first place, so the availability or lack thereof of 64-bit binary-only
codecs and plugins is less of an issue for me than for many others, since
I'd prefer not to have binary-only stuff on my computer in the first
place.  If it's not available in standardized form, playable with an
open source product, there are other things I can be doing with my time
anyway, and I'll just skip the proprietary stuff.  Of course, I recognize
that not everybody has the same strong opinions on the subject as I do. 
For these folks, it's useful to keep in mind that the x86_64 arch, amd64
and the Intel version, is the clear mainline successor to x86.  Therefore,
32-bit-only binary-only codecs and plugins will be less and less of a
problem, as eventually all popular software products, freedomware or
proprietary, will have 64-bit versions as well.  Now that 64-bit MSWormOS
is out of beta (or soon to be, I no longer track MSWormOS close enough to
be sure), 64-bit versions of the various codecs and plugins should be
available fairly shortly, I'd guess.

Before moving from the subject of 32-bit binary packages, I should also
mention that OpenOffice.org has 64-bit issues, or at least the 1.x
versions do. 2.x is supposed to work on amd64.  However, note that due to
its size and complexity, OOo is one of the few apps that even many
hard-core Gentoo users prefer to merge the (32-bit) binary package of,
rather than compiling their own copy themselves.  Thus, as with firefox
and mplayer (and their various codecs), the 32-bit OOo can be merged, only
it's even MORE widely used and tested than the other bin-pkgs.  Of course,
you may or may not have reason to merge and use OOo anyway.  I've found no
need for the various Office suites, here, and if I did, since I use KDE on
my desktop anyway, I'd probably try KOffice first.

...

There's one other set of issues specific (in one sense, tho the general
issue affects others) to /Gentoo/ amd64 (as opposed to Fedora or Mandriva
or SuSE or whatever) that needs to be mentioned, the multilib thing, which
Gentoo /currently/ treats a bit differently than most of the other
distributions.

On a dual-32/64-bitness arch, there are often two copies of various
libraries needed, the 32-bit version and the 64-bit version.  The method
for how this is handled has come to be referred to as "multilib".  The
Linux Standard Base (LSB) / File Hierarchy Standard (FHS) standard
solution uses two separate dirs, lib64/ (thus, /lib64/, /usr/lib64/,
/usr/local/lib64/, etc) for the 64-bit libraries, reserving the
traditional lib/ dirs (thus /lib/, /usr/lib/, etc) for 32-bit shared
objects.  (Note that shared objects, *.so.*, are the "libraries" of Linux,
similar in function to the dynamic link libraries, *.dll, of MSWormOS, but
being around Linux for awhile, you already knew that, I'm sure.  This is
just for others that may be following along. =8^)

Gentoo similarly uses two separate dirs, but because Gentoo amd64
implemented them before the FHS standard defined the names for amd64,
Gentoo took the opposite approach, reasoning that lib/ should contain the
native bitness libraries, in this case the 64-bit libraries, with the
32-bit libraries in lib32/.  The FHS version makes more sense for
compatibility with existing 32-bit packages, particularly binary-only ones
that may simply assume lib/ is 32-bit, while Gentoo's approach makes more
sense (in the absolute, but see below) in an almost entirely 64-bit
system, and moving forward to a time when 64-bit is mainlined.

The problem for Gentoo is that when the LSB/FHS standard was defined, it
/did/ become the standard.  Packages now come from upstream with that
assumption, and it's a lot of work, and becomes ever more work as 64-bit
heads toward mainline, to continually patch everything to use the
non-standard Gentoo locations.  Individually, it's usually not much work
at all, just supplying the proper configure option, but the work adds up
over thousands of packages, and with the standard defined and amd64/x86_64
clearly going mainline, it's a lot of /unnecessary/ work, moving forward. 

Therefore, Gentoo amd64 is currently in the middle of a year or more
process to safely reverse direction, moving 64-bit libs from lib to lib64
(almost done), and eventually, 32-bit libs from lib32 to lib.  Currently,
lib is usually a symlink to lib64, so 64-bit packages that haven't been
fixed yet still work if they install to lib.  (32-bit packages are handled
a bit differently, as discussed below.)

Another aspect of what amounts to the same issue -- how to treat what
could be duplicate packages installed in both 32-bit and 64-bit mode -- is
dependency tracking.  Imagine what happens if the 32-bit and 64-bit
dependency databases aren't kept separate.  You go to emerge a 32-bit
package, and it sees the 64-bit libs it needs are already merged, so it
tries to merge, and fails because it's trying to link against 32-bit
libraries that aren't there to link against!  Even worse would be the
possibility of merging 32-bit libraries when doing an update, then erasing
the "old" 64-bit versions of the same libraries as unneeded!

Obviously, this will NOT work, so 32-bit and 64-bit package dependency
and current installation tracking must be kept separate.  Unfortunately,
current versions of portage, the Gentoo package management system, cannot
directly handle this requirement. Portage-CVS is slated to get this
ability (if it hasn't already been added) by the time it is released, but
current versions are stuck having to work around the issue.

There are a several different ways of managing things, depending on how
many 32-bit packages you plan on installing.  For certain core packages,
currently gcc, glibc, and portage itself, the normal 2005.0 profile (which
is multilib, not 64-bit only, tho that's a subprofile option) causes
/both/ the 32-bit and 64-bit versions to be installed, so portage can
continue to track just the single package.  The rest of the 32-bit "system
base" libraries are currently normally installed as 32-bit binary-only
compatibility packages (emul-linux-x86-*).

That's the base 32-bit compatibility installation.  If you are only going
to be installing binary-only 32-bit software such as games and the
various codecs and plugins, this, and bin-packages such as mplayer32 if
desired, are all one needs.

If, with such an all-binary 32-bit installation you do decide to compile
and install 32-bit stuff yourself, it's *HIGHLY* recommended that you do
NOT use portage/emerge for doing so.  Rather, procure the tarballs
directly, and install "manually", resolving any 32-bit dependencies and
installing them manually if necessary as well.  Obviously, this will
become a rather huge hassle rather quickly, however, if you have more than
a couple 32-bit packages you want to compile from source.

For those who have a large list of 32-bit packages they want to run,
there's another option, the 32-bit chroot.  The idea is to install a
minimal 32-bit Gentoo installation, without system services such as syslog
and cron and without a 32-bit kernel of course, but with all the usual
libraries and the like, and pointedly, with its own 32-bit portage
installation.  Because it's in a chroot, this 32-bit portage installation
will be entirely separate from the system-wide 64-bit portage, so the
dependency tracking systems won't conflict with each other, and any
arbitrary package in portage can be merged as 32-bit, without in any way
affecting the system-wide 64-bit dependencies.  Note that once this is
setup, it's possible to add the chroot's library and bin dirs to the
system-wide paths, and execute your 32-bit binaries system-wide, not just
within the chroot.  

Obviously, for someone only merging one or two 32-bit packages, the chroot
solution is a lot of unnecessary work, but not so much for someone doing
many such packages, where the work of manually tracking dependencies would
quickly become rather unmanageable.  Thus, the different choices for
different purposes.  There's more documentation on the chroot option in
the technotes and other locations, if you decide to go this route.

Again, let me stress that this current less-than-ideal situation is
temporary, and will be going away, once both the multilib and portage
multi-bitness issues are resolved.  In terms of timetable, that now looks
to be targeted at the 2006.0 release.  (It was hoped that it would be done
for 2005.1 coming up shortly, but that appears unlikely, now, particularly
for the portage multi-bitness dependency tracking stuff, as betas aren't
out for the next version yet, meaning it couldn't go stable in time for
the next release, 2005.1.)

Again, as I said at the top, the reality isn't quite as bad as all the
above surely makes it sound.  In reality, most things "just work", with
the caveat that you understand that 32-bit libraries won't work in 64-bit
applications, and the reverse, which you've obviously already figured out
from your own research, since you mentioned it.

...

Now, some more general Gentoo newbie hints...

Before you start your installation, READ THE GENTOO HANDBOOK!!  The first
section covers installation procedures and most folks read that as they
are installing, but it pays to read it thru (for your chosen arch) first,
getting an overview of what you will be doing, before you start.  As you
are doing so, figure out which stage install you plan to use.  A stage-3
starts from a mostly bootstrapped system is initially faster to get up
and running, but takes longer to get everything fully customized.  A
stage-1 install is initially slower and more complicated, but you end up
knowing far more about how a Linux system works behind the scenes, when
you are done.  Here, computing is my hobby, not a job, and learning a
primary purpose, so there was no question, I did a stage-1.  In fact, I
went even FURTHER than that, and took apart the bootstrap script and
executed it step by step, manually.  In doing so, I learned a LOT about
the system I was building than I knew about Linux before, but it DID take
me quite some time to do it.

Partitioning...  If you are like me and use lots of separate partitions (I
have about 20, all told), one thing you'll find is that your /usr/ needs
to be bigger than with other distributions, because that's where the
portage tree and all the sources are kept (unless you put the portage tree
on its own partition or locate it elsewhere than the default
/usr/portage/).  Similarly, you may want a larger /var/ or /var/tmp/ than
normal, since by default, that's where portage does all its compiling. 
For the portage tree and sources, you'll probably want 3G minimum, 5G
or more if you use FEATURES=buildpkg (discussed below).  As mentioned
above, OOo is the largest package in terms of compilation space needed in
portage, needing some 5G of scratch space to successfully compile.  Again,
you'll likely not be compiling it as even x86 folks often use the binary
package for it, but that gives you an idea of the sort of scratch space
normally required for /var/tmp/.  (Here, I've changed both those settings
from the default, keeping the portage tree in its own partition mounted in
a different location, and telling portage to use /tmp/ for its work,
rather than /var/tmp/, so it's possible to change both, but I'm giving you
the default locations, above.)

Another very useful hint for after the initial install, after you've
started customizing your config files (/etc/* and the like).  Do *NOT*
just tell etc-update to go ahead and auto-merge all the new config files
after an update (the negative options), without knowing EXACTLY what you
are doing.  FAR better to go thru each one individually, and see what it's
going to change, then let it make the changes or not as desired, than to
find out it killed your customizations on something critical like
/etc/fstab!  (With /etc/fstab itself, that's no longer a problem, as the
package now updates fstab.example instead, but the problem caught MANY an
unwary Gentoo newbie before they changed that behavior, and the issue
still exists with other files.)  Just exercise the usual caution you
should exercise anyway when running as root, think about what a command
will actually do before hitting that enter key, and you'll be fine.  Fail
to do so, and your failure will EVENTUALLY bite you!  Of course, if you've
been running BSDs and Linux for years, this idea won't be at all new to
you, only the specifics as applied to etc-update.

Before you do the install, however, as well as again afterward when you
are actually ready to start working on your new system, I'd suggest
reading the REST of the handbook as well.  The working with Gentoo and
working with Portage sections should be quite interesting to you coming
from other distributions, as they are all about what makes Gentoo
different from the others.  Learning about how Gentoo's boot process and
dependency ordering differs from the usual numbered init levels with
numbered start and stop symlinks pointing to the appropriate scripts, the
system most other distributions use, is both interesting and educational,
or I certainly found it so, anyway.  (Once you actually get a
system up and start investigating, you'll find that in practice,
the init levels are still there.  Gentoo just lets you deal with
them by name instead of number, if desired.  However, the way
Gentoo's boot scripts resolve boot-time dependencies is VERY
fascinating!)  Likewise with how portage works and the many ways to
customize it. It was fascinating seeing how much more flexible it made
things for the typical sysadmin, as compared to the typical rpm or deb
package management system, yet how even with all that flexibility, it
still managed to keep things simple and decently manageable, without
confusion.  By reading these things ahead of time, you'll understand far
more about what makes Gentoo, Gentoo, and parts of the install that might
otherwise seem entirely arbitrary will be instead entirely logical and
natural.  Reading it again as you actually start working with a running
Gentoo, you'll find things just seem to naturally work the way you'd
expect them to, where otherwise they'd seem just an arbitrary series of
commands that didn't make a lot of sense.

Of course, beyond the handbook, Gentoo has lots of additional
documentation -- one of its strengths as compared to other distros.  How
to configure printing, how to configure your sound system, how to manage
udev, all this and more the Gentoo documentation covers in
Gentoo specific step-by-steps that other distributions lack.

One other specific document I should mention:  the Gentoo amd64 technotes.
These explain most of the differences between x86 and amd64, both in what
you can expect from the hardware, and in software.  Last I looked, some of
the technotes were a bit dated (they still referred to gcc-3.3 in the
future, for instance), but it's still a very good overview, covering
things like the 32-bit chroot option mentioned earlier, and the thing
about OOo, as well as things like common hardware issues and what to do
about them.  I'll mention one important note specifically.  BEFORE YOU
INSTALL GENTOO AMD64, UPDATE YOUR BIOS from the manufacturer's web site. 
Even if the system is new, that doesn't mean it has the latest BIOS, and
MANY have found that the troubles they initially had "magically" went
away, when they installed the latest BIOS.  Likewise, continue checking
periodically for additional updates.  I had the latest when I installed
Gentoo, but additional BIOS updates since then have increased system
stability and performance, rather more than I would have expected, in fact.
The technotes can be a bit harder to find than the Gentoo Handbook and
other documentation, so here's a direct link:
http://www.gentoo.org/proj/en/base/amd64/technotes/index.xml (The
technotes are also linked from the main project page at
http://amd64.gentoo.org, which is easier to remember, and has some other
information as well, but the link from there is harder to find, so I
suggest bookmarking the direct link.)

Another useful hint, about portage, this time.  You'll understand the
significance of this a bit more after reading the portage features chapter
of the working with Gentoo section of the handbook, but setting
FEATURES=buildpkg in make.conf causes portage to routinely build binary
packages of everything it emerges.  This can be very useful for several
reasons. First, it's very helpful if you somehow break gcc, preventing
emerging gcc again to fix the issue. =8^(  If you have the binary package
already built, it's a simple matter to remerge the binary package and have
a working gcc again! =8^) If it was an upgrade that broke it, simply
emerge the previous version's binary package rather than the newest!  If
portage itself breaks, that means you can't emerge stuff, but since the
binary packages are simply tar.bz2 tarballs with a bit of additional
metadata tacked onto the end, you can simply extract the portage binpkg
tarball directly over your live filesystem, replacing the broken portage
files with good versions, and be back in business! =8^)

However, rescue functionality isn't the only thing binpkgs are good for. 
Additionally, it's easy to switch between versions to troubleshoot
something or other, if necessary -- FAR easier than having to recompile an
old version to see if that fixes whatever the problem is, then recompiling
the new one again to get it back.  Also, again, the binpkgs are simply
tbz2 files with a bit of extra metadata at the end, so it's easy enough to
go find a binpkg to see what a particular default config file looks like
in it, as compared to your customized installed version, or whether a file
that should exist but is missing, existed in the package as installed (and
therefore as archived in the binpkg), so it got deleted later, or if it
was missing in the installed version as well.  Of course, I'm running
~amd64 (the ~ indicating unstable or testing), and in fact sometimes
installing packages before they are even marked testing, testing them
early, so all this troubleshooting ability is more useful here than it
would be to an ordinary stable amd64 user, but it's always useful to have,
none-the-less.

So... hopefully that's all helpful and not too overwhelming...  If you
follow this list/group regularly (which I'd recommend, it's not so busy
as to prevent it and ypu'll find useful information on what's ahead from
time to time, even if the usual discussion isn't of interest to you),
you'll find that yes, my replies are /often/ this long and detailed. <g>

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list