On Fri, 2 Sep 2005 01:18:00 -0400
"Walter Dnes" <[EMAIL PROTECTED]> wrote:
> I did some RTFM, and it appears that emerging 32-bit apps requires a
> bit of a hassle. You basically have to install a 32-bit chroot
> environment, which you drop into to do the 32-bit emerges.
This is a hassle, but not a huge one. For a lot of things it isn't
actually necessary anyway.
> What apps
> would you want to emerge 32-bit, you ask? Here's a partial list, off
> the top of my head, of what you lose if you go 64-bit-only...
> - OpenOffice does not build in 64-bit mode.
openoffice-bin works very well.
> - 32-bit plugins for your web-browser of choice
<web browser of choice>-bin is again what you want. OK, you use some
flexibility in both of these, but the problem is only caused by closed
source 32 bit binaries anyway.
> - kiss "internet TV" goodbye, because...
> - RealPlayer is distributed as a 32-bit app
Which will work with multilib support. The plugin still requires the
32 bit precompiled browser though.
> - mplayer, itself, will compile in 64-bit mode. However, the
> "win32codecs" don't exist in a 64-bit equivalent.
There is now a mplayer-bin ebuild which supports win32codecs. It too
works very well.
> The "final straw" for me was that LILO is masked out for 64 bits,
> and GRUB is the only available bootloader. GRUB seems to have been
> afflicted by Microsoft-featureitis disease. It's got a whole lot of
> additional complexity, which allows it to display an image of Clippy
> (or Tux) at bootup. Come-on guys; people need a *BOOTLOADER*, not a
> singing/dancing penguin or paperclip, at bootup.
GRUB is just a boot loader. It's a very flexible one, but that's all.
If you don't want the graphics then you're under no obligation to use
them.
> What advantages does 64-bit mode offer? I don't have terabytes of
> RAM so that ability isn't required.
Well my Athlon64 can only use 40 bit address bus, that's 1TB of RAM. I
doubt I could fit it into the motherboard though.
address sizes : 40 bits physical, 48 bits virtual
> 64-bit mode is allegedly faster
> by default on other distros. This is probably true. The underlying
> reason for that is that in 64-bit mode, the gcc compiler defaults to
> include the flags "-mmmx -msse -msse2 -msse3
I hope not! My vintage of Athlon64 wouldn't like it at all.
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall
nx mmxext lm 3dnowext 3dnow
Notice there is no sse3 support.
> -m3dnow -mfpmath=sse"
> for the AMD64 cpu, which it doesn't do for 32-bit mode on the same
> chip. On a binary distro, you're stuck with what you're given. With
> Gentoo, we "Gentoo ricers" can set those flags in /etc/make.conf and
> get their benefit. So that advantage for 64-bit mode disappears in
> Gentoo.
The real underlying cause of better performance in 64 bit mode is that
it has twice as many CPU registers available. The x86 architecture
was always deficient in this respect and AMD64 had put this right at
long last. Personally I wouldn't have minded a few more, but that
probably isn't really necessary.
> > As for the ATI driver I set it up quickly today using the radeon
> > driver from xorg-x11.
>
> After reading your message, I tried Radeon, and it seems to work. I
> manually entered the frequencies for my monitor, and 1600 X 1200 works
> fine.
My NVIDIA works with the AMD64 Linux driver very well too. Of course
the OSS drivers in xorg-x11 also work well as long as you don't need 3D
support.
> Now I just need to get the sound chip working.
Which chip is it you have? My emu10k1 based Audigy 2 works well with
the in kernel driver. I'd expect most of the other OSS kernel
supported chips to work in 64 bit mode too.
--
Ian.
EOM
--
[email protected] mailing list
