Ok, you know about 32 bits or not, but you are going to install 64 bits mandriva.
So what should you know?

This is what I have collated to date, maybe some error
feel free to contribute. I DO NOT have a 64 bits yet, doing "homework" on the question.

If you are a newbie, the advice seems to be to install a 32 bits linux onto your 64 bits processor.
This is possible, and simpler in the short and long term.
The loss of performance is small.

Updating a 32 bits mandriva to a 64 (instead of doing a full install). Forget about it! bad idea.
Read that not advised to share /home between two Mandy OS (one 32 and one 64, multiboot)
no known rational for that apart that well it is risky. No feedback/experience known

Mixing 32 and 64 libraries is risky
However, setting 32 bits and 64 repositories for uprmi, is feasible
(Order is important to calculate the dependencies)

Flash (well maybe we should not use flash at all...) Anyway, solutions/options are
You may have seen this
[root@localhost install_flash_player_7_linux]# ./flashplayer-installer
ERROR: Your architecture, \'x86_64\', is not supported by the
Macromedia Flash Player installer.
Solutions are
- Flashplayer within Konqueror
- Use opera
- Use nspluginwrapper to "translate/bridge" 32 bits macromedia flash libraries/pluggin into firefox 64 bits nspluginwrapper-i386
- Avoid any flash (I do)
- Chroot a 32 bit firefox (with all the problems/duplication that creates)

Firefox:
There is a 64 bits version, but pluggins/extension will lag behind for a while
Consider nspluginwrapper (Does 64 bits work with it?)

Java
Alledegly there is a 64 bit JRE. To be confirmed
Azureus (java) Reported to work, depending on versions

Realplayer / Helix player (Why do you want realplayer... well I ilke trplayer)
lastfm: some report of it not working, and the contrary as well

wine: well this is 32 bits by definition
Allegedly seen one post saying compilation flags are automatically set to 32 bits and it
compiles beautifully from source on a 64 bits

Skype (well closed source):
Try openwengo; wait for reversed engineered skype clones
Chroot it

for oppenofice, 32 bits, and in general
Quote (Translated from Fr)
There is I think a 64, but basically it is a tweaked 32, going to 64 is a lot and lot of recoding allegedly
2) add 5 repositories: main64, contrib64, main32, contrib32, club32.
3) deactivate main64, contrib64 BEFORE installing any 32 bits application. This avoid dependency hell for the 64 bits,
which risk disappearing
4) install firefox, flash, ooffice, java etc.
5) deactivate 32 bits mirrors, reactivate 64 mirrors

Good to know
urpmi.update -a && urpmi --auto-select --keep --strict-arch
where --keep so that packages that would uninstall other packages are not used and
--strict-arch to avoid a 32 bits application to be replaced by a 64 and conversely

mplayer and to have all the win32 codecs (32 by definition), allegedlly
[quote]
http://www.mplayerhq.hu/design7/news.html:
svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
./configure --enable-gui
make
as root make install
Othewise chroot the damn thing from URPMI

Seen something about install32 prefix, lost from sight
A good chroot tutorial or bash script for mandriva to create a chroot environment
(I have not find one yet)

What you should (and shouldn't) expect from 64-bit Linux
http://www.linux.com/article.pl?sid=06/09/07/1632253

Installing apps in a 32-bit chroot in AMD64 Debian system
http://www.debian-administration.org/articles/356

32-bit browsing in a 64-bit system
http://internet.newsforge.com/article.pl?s...0216&tid=13

[moved from Installing Mandriva by spinynorman]

Unless you have a multiprocessor system with a lot of RAM ( more than 4GB) and want to perform specialized compilation tasks, then the only thing a 64-bit system has to offer on top of a 32-bit one is TROUBLE.
End of story.

I do not disagree from what I started to read.
Considering your number of posts you may want to elaborate about the risks, lack of extra perfomance etc. that would be appreciated. I am sure your experience is valuable. I have started the thread because of the lack of information on this topic 32vs64. If it is a warning to some fine...

I've been using a Mandriva 2006 64 bit install as my main system for about a year now. There are still a few things you can't find on the 64 bit version (eg. codecs) that would be nice but you can run 32 bit programs as well (or so they say). The installer does get confused sometimes and tries to fill dependencies for x86_64 programs with i586 packages, even though 64 bit ones exist. The linker and makefile system also get confused if your compiling source code and they try to link in 32 bit libraries instead of the 64 bit versions if both exist on the same system. This is especially problematic with a site such as PLF.

When installing packages, if such a conflict occurs, you can first install the 64 bit versions of any problem packages and then try again to install the package you originally wanted.

As for crashes and things of that nature, I have had no problems. The Nvidia drivers work great.

I'm hoping that 2007 will fix some of these issues.

Glitz.

Currently, unless you need the extra address space of a 64 bit system, and you have sufficient ram, there's little reason to really run a linux 64 bit desktop.

There are things that the linux 64 bit userspace lacks, such as some codecs, simple flashplayer support, and simple support for other closed source apps. There's no performance difference either, so I really question why anyone would bother using a 64 bit linux on an common desktop.

Just to back myself, here's some benchmarks:
http://www.phoronix.com/scan.php?page=arti...m=616&num=1
The difference is negligable, and in most cases actually swings to 32 bit, although the difference is generally so small it could simply be other variables in the system causing htem.


James

iphitus, that is a great link and benchmark. Thanks.
Lame was tested, but it would be great to find maybe
- a batch picture conversion (like a mogrify operation)
- a video encoding/decoding benchmark 32 vs 64 bits.
Just out of curiosity

But clearly 32/64 is more about what one wants to learn and try than raw power

(Maybe on giant databases 32 vs 64 bits show some difference, bearing in mind that the limiting factor is often the HD anyway)

Personally, I've always believed that backward-compatibility is something that has to be thrown out the window from time to time when it's simply not feasible. 64-bit to 32-bit compatibility was tackled by Apple/Macintosh when they went from 68040 to PowerPC back in the 90's. I'm flabbergasted that when PC went from 32 to x86_64 that no one actually began to seriously run 64-bit OS as the norm. Yes, servers are running 64-bit but the desktop OS is still 32-bit I'd estimate 99% or higher.

Someday I hope everyone goes to 64-bit OS and something like Parallels running 32-bit environment for those must-have applications that didn't port.

I just switched to a 64-bit system and decided to go for all the marbles with the x86_64 mandriva 2007 build. I had a few hardware issues that would most likely be present regardless of the OS build (nvidia chipset, need I say more), but otherwise, I'm very happy with the performance, and the few other issues have been taken care of. The only things that were really hanging me up were the browser plugins, and nspluginwrapper solved most of that for me, as well as the blackdown jre build which contains an amd64 java plugin. Benchmarking aside, I'm of the philosophy that if you're running a 64-bit system, you may as well go with the 64-bit OS. Unless you have some very specific needs, chances are that someone will have a solution to any problem you may run into. It really wasn't much more trouble than getting things set up with a 32-bit build, and I suspect that down the road I'll be happy that I went ahead with it now. Just my 2 cents.

Is this the best script for a safe and efficient update of the system?

I ususally do urpmi.update -a && urpmi--auto-select but maybe that's not enough?

Advice welcome...

Stef

urpmi.update -a && urpmi --auto-select can be replaced by urpmi --auto-update now.

Installing windows games through Crossover Games is troublesome on 64-bit


Installing windows games on 64- bit 2008.1 Mandriva powerpack (PWP) through Crossover Games or similar provide mixed results. I've tried installing World of Warcraft on three separate linux installations on the same PC, using essentially the same procedure, and succeeded in only one. The two bad installs halted after the intro movie, indicating a problem with the video card (8800GT). I used the commercial driver from nVIDIA provided in PWP in all cases, and upgrading to the very latest from nVIDIA did not seem help. I succeeded installing Half-Life 2 episode 2 through Steam, but the framerate was much worse than expected. On the other hand, I did not succeed in installing Call of Duty 2 through steam. These problems could be due to wine, or it could of course be the driver for my video card. I'll try to install a separate 32-bit linux system to find out more.

Hallvard, Oslo


P.S. I'm really glad for this topic, as I've decided to use only 64-bit operating systems on my 4G RAM/Quad core PC. The 32bit/64-bit question is bit like the hen and egg-question: if nobody starts using 64-bit on personal systems, there will be little development and bug fixes for this platform. Soon there will be killer personal apps that demand more than 4G RAM (e.g. speech recognition and system-wide semantic interpretation, perhaps?), and the more mature the 64-bit platform gets, the better.

@ HallvardL: This is a really old topic, but anyway...
wine emulation has improved for 64-bit systems (AFAIK there's currently a 64-bit version for Crossover Office 7.02), but things aren't smooth-yet.
IMHO the problem is not so much the OS (spaeking about Linux)- the 64-bit Linux versions perform pretty decently on what their authority is. Same applies for the right windows 64-bit versions (2003 server, 2008 server, Vista 64-bit), but there are exheptions- namely XP 64-bit, which is just a fat joke: loads of problems, and no advantages over the 32-bit version.
The REAL problem is the hardware, which does have to be designed for 64-bit code to unleash the OS potential. So far, the genuine 64-bit mobos/parts are both expensive and rather lacking in support.
I won't argue that 64 bit is the future, and in 48 months nobody will bother about 32-bit (unless he's using a really old rig). But we are not there, yet, and we will probably not come close, until mid-2009.
Just my $ .02.

Seeing as I need to do stuff for Arch in 64bit, my desktop has been running Arch64 for a few months.

It's been pretty straightforward really. Everything works natively except...

Flash
- Easily fixed by installing some 32bit library packages and setting up nspluginwrapper. All available in repositories/AUR, and easy to follow docs on wiki.
X-Plane
- Runs fine after installing 32bit library packages, all available in the Arch repositories/AUR.