I wouldn't bother running Steam on a non-valve distro, it just doesn't seem practical given the options available (Win/OSX/SteamOS).
Full disclosure: I use Steam on OSX & inside a Windows VM. My biggest peeve is that Valve restricts the Steam client to a single runtime (meaning: I can't run steam on OSX & Windows at the same time "This account is logged in elsewhere"). So I'm always switching between the two, which causes a bit of user fatigue. Come on, just allow unlimited instances/logins from the same IP. I digress.
Steam on Windows isn't all that great either. It's 2014 now and Steam still ignores the "multi user" aspect of Windows.
Have Steam installed and want to logon automatically so you don't have to enter your password everytime? Great, just tick the appropriate checkbox.
Works great for me, but when my brother uses the PC with his own Windows account, you already know what happens when he tries to start Steam and wants to play using his Steam acount. Correct, he gets auto logged in into my Steam Account. Because as far as Valve is concerned, 1 PC == 1 Steam Install == 1 Steam User.
Granted, Windows wasn't always "multi user" but I think it has been for quite some time now ;)
Seeing this and looking into their Linux efforts and their SteamOS for the "Family" and "Living Room" I really see some problems for them unless they finally change this behavior. In a family and in a living room you are bound to have multiple users with Multiple Steam Accounts and especially on a TV, I bet many people would like to log in automatically instead of having to log in manually using a controller to type out the password.
Last time I tried, I solved this with just copying the Steam folder and each person starts Steam from their own Steam folder. A lot of wasted space since we got duplicates of all games, but it worked.
I really hate it when proprietary software developers list only dependency to be - "your system should be capable of running 32-bit apps." Why no just simply list the actual lib packages needed.
1) Missing libraries: Almost always 32-bit/64-bit problems.
2) Missing executable: this is usually fixed sooner or later.
3) Graphics problems: This shouldn't be a problem on NVIDIA systems, and the Intel Mesa drivers are pretty good these days, but it still can occur.