The Steam Linux Beta Begins...

[christian_frank]

Serious Sam 3 purchased and working. Performance not fantastic--had to turn down to medium/medium/ultra for steady 30fps (AII 620 @ 3.3ghz, gtx 460). Nice looking game though compared to what else we currently have in the linux world. Can't wait for the source games to start going live.

Hi,

can you please post your system info ? I also tried ss3 but i have tons of graphical issues. I use nvidia 310.14 (its the same with 304.64) on an intel dual core (core2duo e8200) with f17 32bit. 4gb ram.

Best regards,
Christian

[Kano]

@psycho_driver

Did you install libpci3:i386 ?

[deanjo]

The default download for U....snip... of the amd64 architecture.

Still, pretty much every PC out there in the last 3 years has been shipping with a 64-bit os. As far as the flash/java stuff goes, that has been resolved as well and hasn't been a factor for fairly long time already. Sure there is still a lot of old hardware in use with linux. Part of the reason for that is there are also a lot of people that keep a huge gaming system running windows meanwhile keep an older box for their linux since there hasn't been much to push the hardware in linux for quite some time. This may change with Steam coming to linux. Sticking to 32-bit also means that you may lose taking advantage of items like newer instruction sets if the application does not have some type of runtime detection and even then it may be built to a lower common denominator to maintain a wide compatibility path across the various 32-bit cpu's.

[elanthis]

No freaking way the majority said they're running a 32 bit system.

The default download for Ubuntu when you visit their site is the 32-bit version. It could easily have detected that I'm running a 64-bit OS already from my browser user-agent string, but did not. Fedora is now defaulting to 64-bit (not sure if it's detecting my OS or just always defaults to 64-bit now), but I recall it always defaulting to 32-bit too not too long ago. Unsure about the other popular distros, but I imagine most are in a similar boat. Most users likely have whatever that default download is. If you're thinking that all Linux users are computer geeks who know or care about 32-bit vs 64-bit and know to select a non-default download, then you're making the case that Linux is a nerd-only OS, and that doesn't bode well for Steam or gaming on Linux being commercially successful.

There are plenty of people who install the 32-bit version intentionally for compatibility reasons. I recall Flash on Linux, among a few other proprietary programs, being a bitch to get working in 64-bit mode. It's better now I believe, but who knows. It wasn't too long ago that I was struggling with my 64-bit OS and reading tons of folks in forums loudly proclaiming that 64-bit was useless and nothing but a problem and that folks should just stick to 32-bit. Again, different now, but I don't doubt that many users have just stuck to 32-bit out of inertia.

There's also people who think that 32-bit is faster if you have 4GB or less of RAM, which is still very common for most PCs built before this year. It actually _is_ faster for some programs, hence the whole x86_32 architecture thing that Google was pushing (smaller pointers means data structures are smaller means more data fits in cache and can be retrieved with each memory access means better data throughput). These folks might intentionally be avoiding 32-bit still. Older hardware is popular with Linux users, and in general cutting-edge hardware is geared more towards gamers who are of course not generally Linux users on account of almost every major PC title still being Windows only. Older hardware with less RAM hence is a target market of Steam on Linux, and that includes all the folks who choose 32-bit for speed benefits (even if it's only an imaginary benefit).

Lastly, yes there are still a number of 32-bit-only Linux PCs around (older hardware being popular with Linux and such), and there are certainly people who are interested in gaming who have them. One of the big draws of Linux is its compatibility with older hardware (see all the endless bitching about GNOME 3's GL dependence for an example of such people). Older hardware is recycled, often sent to underprivileged homes and children, many of whom I'm sure would love to play some free or very low-cost Steam games. Steam has plenty of games that will run perfectly fine on older hardware, too, including a good number of the existing Linux games in the beta. Indie games in particular tend to have simpler engines with simpler content that doesn't stress the hardware much. Even every single one of the popular Valve games are older titles running on the aging Source engine, and they (in fact, every single AAA PC game) run perfectly fine on 32-bit. 64-bit binaries don't run on 32-bit-only CPUs, but the reverse is not true. There's no reason for the company to bar a ton of potential customers from purchasing titles just to satisfy technophiles' hatred of legacy. We will likely see some 64-bit only games in the near-ish future, but we're hardly at a point where you should expect a game to be ready to make ready use of increased memory space or to be optimized poorly enough to outright need the other performance advantages of the amd64 architecture.

[psycho_driver]

Serious Sam 3 purchased and working. Performance not fantastic--had to turn down to medium/medium/ultra for steady 30fps (AII 620 @ 3.3ghz, gtx 460). Nice looking game though compared to what else we currently have in the linux world. Can't wait for the source games to start going live.

[deanjo]

And those saying that 32-bit is dead, there's still plenty of 32-bit CPUs out there. Why don't you tell Intel it's dead:
http://ark.intel.com/products/70105

I think everyone is meaning it is dead on the desktop, not on a tablet (which is what that series of atom is for).

[Desti]

You've raised a very good point there with the community features/overlay. Just spelling it out again: If _any_ game sold through steam has a 32 bit version, and they want overlay support, steam would need to bring in a whole bunch of 32-bit libs that the overlay library links to so that it can be used. The same goes with 64 bit games ran from a 32-bit client. The only case where Valve won't need to deal with multilib systems is if they make it a requirement that all game devs provide 64-bit and 32-bit versions of their games, while valve provide both 64 bit and 32 bit steam clients.

And those saying that 32-bit is dead, there's still plenty of 32-bit CPUs out there. Why don't you tell Intel it's dead:
http://ark.intel.com/products/70105

The Atom Z is an embedded processor, you can not buy any desktops or notebooks with it. (and you don't want to have an atom for gaming at all)

[Kamikaze]

Maybe you did not read my post, you can certainly start 64 bit apps from a 32 bit client - therefore you do need to not change it, but you dont get the community features that steam provides. Maybe it could be done with a 64 bit overlay that the app itself preloads in that case. Install World of Goo and Amnesia and see yourself what i mean. I highly doubt that there is one game out here that runs faster when using 64 bit but some games have got sound issues. With direct pulse audio support this should be easy to fix however.

You've raised a very good point there with the community features/overlay. Just spelling it out again: If _any_ game sold through steam has a 32 bit version, and they want overlay support, steam would need to bring in a whole bunch of 32-bit libs that the overlay library links to so that it can be used. The same goes with 64 bit games ran from a 32-bit client. The only case where Valve won't need to deal with multilib systems is if they make it a requirement that all game devs provide 64-bit and 32-bit versions of their games, while valve provide both 64 bit and 32 bit steam clients.

And those saying that 32-bit is dead, there's still plenty of 32-bit CPUs out there. Why don't you tell Intel it's dead:
http://ark.intel.com/products/70105

[deanjo]

I'm leery of simple fixes and solutions because I often find them to be fundamentally flawed in some way. The thing about just re-running the compiler seems to fit into the "too easy" category. The "poor code" thing strikes me as boilerplate as well.

You should be leery. Besides some of the above mentioned hurdles in my previous post, if you are going to port to 64-bit you might as well add some 64-bit specific instructions and optimizations or else there is little reason to compile a 64-bit binary other then the fact of having to have 32-bit compatibility libs on the system.

[Larian]

it isn't easy in 2 cases:
you are
1. using assembler / JIT compiler / virtual machine
2. lame developer creating poor code

I'm leery of simple fixes and solutions because I often find them to be fundamentally flawed in some way. The thing about just re-running the compiler seems to fit into the "too easy" category. The "poor code" thing strikes me as boilerplate as well.