Valve Reveals More Steam Linux Distribution Details

[Bucic]

blah fuckity blah blah...

Well said

[JanC]

Try installing 32 bit boost libs in a 64 bit ubuntu. That's their multi arch support. (On archlinux it simply goes in /usr/lib32 and it works.)

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

[JanC]

Netbooks...
Almost all up until quite recently, and even now a significant proportion of the damn things.
Admittedly a lot have PowerVR graphics and are a nuisance to use Linux on anyway, but there are still a lot of potential and actual users there.

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

[curaga]

Have you tried running any common desktop apps on that configuration? You can't even have a decent browsing experience on that since you'll negate any gains on the CPU side with the massive amount of paging out to the HDD.

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

(Number could be higher for browsers, if you have links please share.)

[JanC]

What benefits does a 64bit OS have over a 32bit PAE enabled kernel ???

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.

[JanC]

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

(Number could be higher for browsers, if you have links please share.)

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.

[JanC]

Even if you had 512mb of RAM, running 64bit would make sense for the performance (extra registers).

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.

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

[duby229]

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.

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.

[Larian]

Well obviously. If your cpu isnt capable of 64bit then you need to use 32bit. But there is no chance that these high of numbers represent only 32bit cpus. I'd be willing to bet that the majority of these 32bit installs are on 64bit capable cpus.

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.

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.

[Gps4l]

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.

https://github.com/ValveSoftware/Sou...ames/issues/26

second:
From the commandline:

guus@linux-4d9r:~> steam
Running Steam on opensuse 12.3 64-bit
STEAM_RUNTIME is enabled automatically


Third:
https://developer.valvesoftware.com/...am_under_Linux
1 Native Steam on Linux

1.1 Unpackaged
1.2 Arch Linux
1.3 Fedora
1.4 Gentoo
1.5 openSUSE / SUSE
1.6 Ubuntu

Edit: I had some problems finding it, but here it is
https://github.com/ValveSoftware/ste...nux/issues/158
Still open....
Something about the tray icon not displayed right. (only issue remaining)