Well said :)
Originally Posted by nightmarex
AFAIK the Boost library packages haven't implemented multiarch yet, but once somebody does that, it should be possible to install i386/amd64/armhf/etc. packages in parallel... (I'd expect more work on multiarch after Debian 7 gets released.)
Originally Posted by ChrisXY
Even on netbooks that have a 64-bit CPU you probably don't want a 64-bit OS, as they usually only have 1 GiB of RAM (and part of that is unavailable because it's used by the GPU).
Originally Posted by FLHerne
The common overhead of 64bit is quoted as 10% more RAM/binary size. If 10% pushes your browser over to swap, that just means you need to switch to a 10% more efficient browser ;)
Originally Posted by Kivada
(Number could be higher for browsers, if you have links please share.)
On PAE, each application can use only 4 GiB of virtual memory (the system can use more). There can be speed advantages in some cases (more & larger registers, larger vectors). There are also some security features that are only available on 64-bit x86.
Originally Posted by DDF420
I'd expect browsers (or more specifically: web rendering engines) to be hit by that significantly, considering the huge object trees they have to manipulate.
Originally Posted by curaga
You forget that 64-bit pointers need twice as much RAM/cache size as 32-bit pointers, and because of that there are also differences in instruction size. It's very well possible that a tight loop fits in cache on a 32-bit OS, but not on a 64-bit OS, in which case the cache misses will make the 64-bit version a lot slower (despite having more & larger registers). x32 might be a good (but not well-tested yet?) compromise, I don't know it well enough to judge.
Originally Posted by curaga
For encoding/decoding (using SSE instructions and similar) it might be beneficial to use 64-bit code for example, but for a significant amount of real world desktop software, the advantage might not be so clear...
I think you could show the difference in benchmarks but I doubt very much it would make a difference in real applications.
Originally Posted by JanC
In my case, I have a 64 bit capable cpu after a hardware upgrade, but I've been doing in-place upgrades of my OS from back in my 32 bit era. The old home partition is quite a) enormous and b) on the same partition as the OS install because nobody told me I could put it on a secondary partition all those years ago. I *could* bite the bullet and spend a massive amount of time, effort, and headache to refactor my entire filesystem and then fight the million and one bugs that incompatibility issues would spawn, but I'm not up for it today.
Originally Posted by duby229
While I have a secondary Mint install (64 bit), I find myself staying in Ubuntu in 32-bit land because it's more comfortable. I still get headaches remembering how I had to do the WINE setup under Mint so it would compile and run 32 bit apps. Again, I could probably fix it, but ... not up for it today.
I guess my point can be summed by saying that what I've got right now works. For me, going 64 bit will break a perfectly working system without justifiable cause. Maybe one day, ... but I'm not up for it today.
I do not agree Valve only supports ubuntu.
I had a topic on the github, because I had a problem with openSUSE.
They did help me, and solved it.
From the commandline:
Running Steam on opensuse 12.3 64-bit
STEAM_RUNTIME is enabled automatically
1 Native Steam on Linux
1.2 Arch Linux
1.5 openSUSE / SUSE
Edit: I had some problems finding it, but here it is
Something about the tray icon not displayed right. (only issue remaining)