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

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

[Anand Buddhdev]

Hello fellow list members,

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?

Regards, and thanks in advance.

Anand
-- 
gentoo-amd64@gentoo.org mailing list

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

[Mike Melanson]

Anand Buddhdev wrote:
> Hello fellow list members,
> 
> 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?

	For most of what I have to do, 64-bit Gentoo works famously. Yes, the 
multimedia codec thing is a problem which is very near and dear to my 
heart (see my email address). The community is working hard on reverse 
engineering major codecs in order to mitigate this problem.

-- 
	-Mike Melanson
-- 
gentoo-amd64@gentoo.org mailing list

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

[Bob Sanders]

> Hello fellow list members,
> 
> 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? 

You could go with the bins.  However, being lazy, I just switch to Opera
when I need to deal with Flash.  Realplayer...well, realplayer alwaays
found some way to break more than work for me.

Also, downloading the WinXX file and playing with Xine or GMplayer using
the win32codecs works in a lot of cases.  Not all.

> 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.
>

Don't count on SRPMS actually producing a working package on your system.
They compile great in the dedicated build environment, most times.  But
on the average system, something will go wrong.  A clean chroot environment
and a complete set of packages will be needed - essentially, a duplicate
of the typical build environment. 

> 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?
>

Just go with 64bit.  Sure you'll have some problems.  Most issues with
32-bit games remain.  Multimedia works well - haven't played with Realplayer
in awhile, but most quicktime seems to work, as does firewire and usb audio.
DVDs and SVCDs all play, firewire deck control and video capture work.
Ogg work fine.  No problems with audio - Alsa works.  OpenAL works
for Ut2004.

Bob 
-  
-- 
gentoo-amd64@gentoo.org mailing list

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

[Zac Medico]

Anand Buddhdev wrote:
> 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?
> 

http://www.gentoo.org/proj/en/base/amd64/technotes/index.xml?part=1&chap=4

Why not do both?  If IA32 Emulation is enabled in your kernel config the you can use both 32-bit and 64-bit userlands and chroot from one to the other when necessary.

Zac
-- 
gentoo-amd64@gentoo.org mailing list

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

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Anand Buddhdev <arb@anand.org> wrote:
> 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?

If you need to run DOSEMU, you need to go 32-bit, and it's going to
stay that way.  (The same is _not_ true for Wine, you can run that in
64-bit Gentoo.)  Otherwise IMO if you like playing with the OS then go
64, otherwise consider going 32.  If you don't like playing with the
OS, however, then why use Gentoo?  :) So that probably means you
should go 64.

I have a 32-bit chroot that is almost as complete as my 64-bit stuff.
Effectively this means I can often use a 32-bit program from within
the chroot in nearly the same fashion as if I were running it on a
separate 32-bit installation.  It means more system maintenance work,
however.

-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Barijo.SXVARCO@chemoelectric.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Duncan]

Anand Buddhdev posted <42D3A936.8060306@anand.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@gentoo.org mailing list

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

[Richard Freeman]

On Tue, July 12, 2005 7:27 am, Anand Buddhdev said:
> The main issues seem to be
> with firefox 32-bit plugins, and win32 codecs for use with mplayer.

I might also point out java, which nobody else has pointed out thus far. 
Simple applets and apps work fine with either blackdown or sun-jre/jdk. 
However, more complex apps can tend to break in 64-bit land due to bugs in
the VMs.  I've found some that work with blackdown only and some which run
with sun-1.5 only (which is a beta that breaks all kinds of other stuff).

I've gotten so frustrated with 1.5 issues that right now I don't have java
installed at all 64-bit.  I just run it in a 32-bit chroot.

If you are just running simple stuff I wouldn't worry about it, but if you
want to run anything complex I'd consider using a chroot...
-- 
gentoo-amd64@gentoo.org mailing list

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

[gh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8; format=flowed, Size: 1105 bytes --]

Anand Buddhdev a écrit :

> 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?

What follows will not answer your question, but might interest you. I 
installed both amd64 and x86 on my computer just to compare the performance 
of both. After a few test (consisting of creating a tar archive of about 
3-4 Go) I conclued that a 64-bit architecture is 10% faster than a 32-bit 
one on the same hardware.

Concerning, gentoo amd64, I never had a problem that could not be resolved. 
The next step for me is to add a TV card. I hope it will work like it ever 
has ...

gh

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com
-- 
gentoo-amd64@gentoo.org mailing list

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

[Kyle Liddell]

On Tue, 2005-07-12 at 08:37 -0700, Duncan wrote:
> 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. 

Well, I'm quite the opposite.  I have /home, /boot, and /.  However, if
you do use the lots of partitions method, you might look into using LVM.
I've got a junk-hardware-magnet fileserver, and in the process of
adding/swapping hard drives, switching to RAID, etc etc, I've discovered
it's quite a tiresome process when you want to play with partitions.  I
just switched the thing over to LVM though, and it is quite impressive.
It will save you huge amounts of time if you will be needing to do a lot
of partition shuffling.
If it is your first time to install gentoo, it will add some complexity,
but will help when you realize "oh no, I need another 500mb
for /var/tmp/portage"...

Kyle Liddell


-- 
gentoo-amd64@gentoo.org mailing list

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

[Richard Freeman]

On Tue, July 12, 2005 1:51 pm, Kyle Liddell said:
> but will help when you realize "oh no, I need another 500mb
> for /var/tmp/portage"...
>

On my system I have /tmp and /var/tmp mounted as tmpfs.  My philosophy is
that nothing important should be in there anyway, and if I'm buliding I
really don't care whether the files being compiled are ever committed to
disk.  The advantage of tmpfs is that if there is no need to free up RAM,
your build directory will never get written to disk at all - just the
final merged files.  Of course, you'll need a few GB of RAM/swap to
accomplish this, and when doing the rare openoffice-scale build I usually
need to resize the tmpfs or run off of disk.

If you're swapping you might wonder what the advantage of using tmpfs over
a regular filesystem is.  After all, it is getting written to disk either
way, right?  Well, if you write to a regular filesystem the system will
hold the data in buffers/cache for no more than a few seconds - to
minimize the amount of data lost if power fails.  After all, if you write
to a filesystem you expect the data to be around after a reboot.  On the
other hand, with tmpfs the memory gets swapped like anything else based on
frequency of use and all that.  There is no long-term concern for
fragmented disk space, and a frequently accessed file will never get
swapped at all.  At the end of the emerge, the work directory is deleted
and rather than a mad rush to update inodes the memory is simply
unallocated (which requires no disk access).

Some day I should time a build using tmpfs vs a regular filesystem and see
how large the difference is.  Obviously it will be more pronounced for
those with more RAM - although even Duncan might have to resort to turning
on swap to actually take advantage of it.
-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

Bertrand Jacquin posted
<43872d370603280717w2b6ccbd9l9dae6e21a9a927d2@mail.gmail.com>, excerpted
below,  on Tue, 28 Mar 2006 17:17:27 +0200:

> How could you compile mplayer or firefox in your 64 bits environnement
> to generate 32 bits binary ? I have multilib activated and I can't
> build mplayer with CFLAGS="-m32".
> 
> It is needing something else ?
>
> I don't want too to have and maintain a 32 bit chroot.

There /are/ the 32-bit precompiled packages for those in the tree,
firefox-bin and mplayer-bin, if you want to merge them.  Note that these
use different executable names so you can even have both your regular
64-bit and the 32-bit-binary versions merged side by side.

As for why you can't seem to compile the 32-bit binaries, it's very
possibly because you are missing certain of the libraries and other
dependencies, or more likely, the 32-bit headers for them necessary for
compilation.  Naturally, you could track all this stuff manually, but
that's what portage is for -- only it can track only one bitness at a
time.  Thus, the idea of a 32-bit chroot, complete with its own instance
of portage, which can track all the 32-bit dependencies necessary to
compile in 32-bit what you really want, firefox and mplayer, in this case.
Sure, it's /possible/ to track all those dependencies manually, but it's
/far/ easier to run a chroot for the purpose and let portage do what
portage does well -- automate all that stuff for you so you don't have to
worry about it.

-- 
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@gentoo.org mailing list

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

[Duncan]

Marco Matthies posted <442A6C24.2090801@gmx.net>, excerpted below,  on
Wed, 29 Mar 2006 13:14:44 +0200:

> Bertrand Jacquin wrote:
>> The first exemple I wrote was in reality :
>> CFLAGS="-m32" emerge -avt mozilla-firefox
>> 
>> To be clear : I don't want a chroot, because it make be 2 gentoo to
>> maintain and a lot of things unecessary ATM.
>> I would like portage build for me a software in 32 bit mode.
>> If it's a lib, I would like portage to install it in /emul/linux/x86
>> if I tell him to do that
> 
> Sorry, i missed the part about you not wanting a chroot. As far as I 
> know, portage currently does not support installing 32-bit and 64-bit 
> versions of the same package, i.e. it does not know anything about the 
> bitness a package was compiled for and therefore doesn't use this 
> information for dependency resolution. In other words, it will not know 
> that the X11 libs it installed are 64-bit and that the firefox you want 
> to compile for 32-bits needs the 32-bit X11 libs.

That's correct.  You /will/ eventually trash your system trying to do
this, as portage will get hopelessly confused trying to merge stuff with
dependencies it /thinks/ you have already merged, only you don't, because
you merged them in the other bitness.

The easiest way to keep portage from getting confused is to run two
separate instances of it that don't know about each other.  The way you do
that is to run a 32-bit chroot.  Yes, it /does/ require a certain amount
of duplication, but if you use a stage-3 x86 install and the binary
packages CD, it's not /too/ bad.  You lose a bit of customization going
pre-built binaries, but it's a trade-off between that and the time to
compile all that stuff twice.  You can always remerge the specific
packages you want to.

At some point in the future, likely with the ongoing full rewrite
project rewrite that's very possibly a year or two away from release,
altho the feature may well be backported some time before then, it's
planned that portage will have a multi-bitness deps tracker and resolver. 
However, that's a /long/ way off.  Meanwhile, you can either go 32-bit
only, 64-bit only, or run a multilib system.  If you run a multilib
system, you can choose limited 32-bit support based on the 32-bit binary
compatibility libs, or full 32-bit support based on a chroot, with all the
time necessary to maintain it balanced against the better 32-bit support.

Personally, I don't like closed source slaveryware in any case, and
basically won't have it on my machine.  If I was content being someone's
slave because they don't respect me as a user enough to give me my rights,
I could have stayed on MSWormOS.  After all, I left a decade of knowledge
behind when I switched, and I /could/ have just stayed where I was.  I
found it worth my time to switch, and there's no way I'm going to consent
or allow myself to be tied down to unfreedomware now, or why did I switch
in the first place?  That makes the 32-bit/64-bit software issue much
easier, since the non-marginal freedomware was ported a long time ago and
has been available in 64-bit native for soome time.  It's only the
marginal stuff, and closed source slaveryware that I couldn't/wouldn't run
anyway, that's 32-bit only, now.

Of course, I'm mature enough to realize not everyone holds my values,
neither do I expect them to, so I recognize that those that choose to run
what I consider slaveryware can make that choice, just as I made mine. 
Just don't ask me to take part in it.

-- 
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@gentoo.org mailing list