Announcement

Collapse
No announcement yet.

Valve Reveals More Steam Linux Distribution Details

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Valve Reveals More Steam Linux Distribution Details

    Valve Reveals More Steam Linux Distribution Details

    Phoronix: Valve Reveals More Steam Linux Distribution Details

    Valve's hardware/software survey for Steam that shows details about their user-base, is now showing a lot more Linux distribution details...

    http://www.phoronix.com/vr.php?view=MTMyOTc

  • PeterKraus
    replied
    Originally posted by Kirurgs View Post
    In true Phoronix formums style, what could I expect more.
    Still, HOW do you notice, on an average laptop for an average Joe, that video is playing 1% faster, or openarena is 1% faster and mp3 encoding is 2 secs faster, huh?
    NO, normal user can't notice that and I'm not talking about benchmarks here or specific users with specific needs.
    I do use 64bits and only thing that in real life everyday situation was faster and I NOTICED it was opening encrypted partition of my HDD.

    Please do not become rude before You actually read/understand the context.
    Proven wrong? Better resort to "I'm a special flower, please don't offend me!". Come on.

    Leave a comment:


  • Kivada
    replied
    Originally posted by duby229 View Post
    EDIT: Check out ebay DDR2 is dirt cheap. At least one guy on there has a pretty big stock of G-skill DDR2-800. I know you can find at least 1GB modules, so if you have 4 slots than it could be possible to get 4GB total.
    Nah, I need DDR1 for that board. Which is rare in 1Gb dimms at a price I'm willing to pay for them.

    Either way, next box is getting 32Gb+ of ram, just because it's under $150 for it. Can you spell ramdisk?

    Leave a comment:


  • IanS
    replied
    I tend to really abuse Firefox tabs; before I found a tab unloader addon (UnloadTab) for it I would pretty regularly cause it to take up more than 4GB of RAM, which would be a real issue for 32bit. Also I do a lot of 3D design work in Blender and that has really been performing much better on 64bit distros, particularly when I get into realy large files and doing high res sculpting with it. Blender is another program I can often run up to several GB of RAM usage. I've also noticed a difference in performance with virtual world viewers for games like Second Life or InWorldz. When I have high settings on with 32bit viewers I notice every second or so when most of the updates fire that there is a fraction of a second pause while walking around, on the 64bit versions things stay nice and fluid while moving around except in the really poorly designed sims.

    So for me at least, moving to 64bit distros offered some real advantages to my daily use cases. On the other hand I have a friend who has a 64bit capable computer that can't seem to run 32bit programs when running a 64bit distro, he is a long time Linux power user, so he knows enough about how to find and install the multiarch libs and to make sure things are set up properly. I am thinking it could be a kernel bug in the 64bit version that is affecting some piece of hardware in his system as we have explored pretty much everything else at this point. So for him, it has just been easier to stick to 32bit distros for now.

    Leave a comment:


  • Kirurgs
    replied
    Originally posted by PeterKraus View Post
    In true Phoronix formums style, what could I expect more.
    Still, HOW do you notice, on an average laptop for an average Joe, that video is playing 1% faster, or openarena is 1% faster and mp3 encoding is 2 secs faster, huh?
    NO, normal user can't notice that and I'm not talking about benchmarks here or specific users with specific needs.
    I do use 64bits and only thing that in real life everyday situation was faster and I NOTICED it was opening encrypted partition of my HDD.

    Please do not become rude before You actually read/understand the context.

    Leave a comment:


  • Gps4l
    replied
    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)
    Last edited by Gps4l; 03-19-2013, 07:04 PM.

    Leave a comment:


  • Larian
    replied
    Originally posted by duby229 View Post
    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.

    Leave a comment:


  • duby229
    replied
    Originally posted by JanC View Post
    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.

    Leave a comment:


  • JanC
    replied
    Originally posted by curaga View Post
    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...

    Leave a comment:


  • JanC
    replied
    Originally posted by curaga View Post
    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.

    Leave a comment:

Working...
X