Steam's Linux Marketshare Ended Slightly Lower For 2016

[Creak]

Will the menus come faster in their UI with a 64 bit app?

No, but considering that 99.9% of the Linux users are on 64-bits OS (and it's also a huge majority on Windows), it's weird they stick with 32-bits binaries. Having 64-bits binaries would help sharing libs with the ones provided by the OS.

[Passso]

No, but considering that 99.9% of the Linux users are on 64-bits OS (and it's also a huge majority on Windows), it's weird they stick with 32-bits binaries. Having 64-bits binaries would help sharing libs with the ones provided by the OS.

If it fix all their horrible 32 binaries and libs to remove/link/copy manually after fresh install then I have to agree...

[lejeczek]

I have two machines under Fedora 25 and I'm running Steam on them, since Fedora 24, without any problem (zero conflicts). The simplest way to install it, and more generally to customize Fedora, seems to be using Fedy: http://folkswithhats.org/

we all agree I guess - there should be no need for further tampering. I mean, this is really simple - if Valve cared (and I follow https://developer.valvesoftware.com/...r_Linux#Fedora) they would have set up (and for every other popular distro) their own dnf/rpm repos a long!! time ago.
Is it that they bare some animosities towards Redhat?? Even if so, Fedora (which is probably second most popular distro, if not the first) is not just Redhat, right?
It it just beyond me - skipping Fedora in Linux realm is like skipping Android in "gaming" realm - one can do it if one does not give a toss, but it's silly.

[Creak]

we all agree I guess - there should be no need for further tampering. I mean, this is really simple - if Valve cared (and I follow https://developer.valvesoftware.com/...r_Linux#Fedora) they would have set up (and for every other popular distro) their own dnf/rpm repos a long!! time ago.
Is it that they bare some animosities towards Redhat?? Even if so, Fedora (which is probably second most popular distro, if not the first) is not just Redhat, right?
It it just beyond me - skipping Fedora in Linux realm is like skipping Android in "gaming" realm - one can do it if one does not give a toss, but it's silly.

Why should they make their own repo? (honest question)
My opinion is that since it's already in RPMFusion and that this repo is like the first thing you add on a fresh Fedora installation (and that's actually what Fedy does under the hood when you ask for stuff like Steam or proprietary codecs). So Valve already have guys maintaining a Steam package for them and it's inside one of the biggest 3rd party repo for Fedora. Having their own Valve repo won't improve anything to the users, it would even be less practical because we would have to trust yet another repo.

Valve could probably do a Flatpak, but I'm not sure it's better than a package in RPMFusion. I would trust more a package made from Fedora aficionados than a Flatpak made from a company that doesn't really care about the specificities of each distros. And, to be honest, I completely understand that they don't care: distro packaging system have always been thought only for their own distro. It's based on the fact that their will always be nice guys packaging all the possible binaries for their distro. It works for open source apps, but this model doesn't work for proprietary apps like Steam. You can't ask a company to create a repo for each and every Linux distros, having to make a package for each packaging system on your own is a pure waste of time.

The perfect solution (that will probably never happen) would be that all the distros accept to use the same packaging API so that a package could be installed on any distribution. I don't think it would be very hard to do, it could even be an making-API, so that one single configuration file could generate packages for each distribution (a la autoconf/automake that generates makefiles).

[sarmad]

Nothing sells without marketing, and with Linux there was no marketing at all. Even Steam Machines themselves were not marketed at all. So, I would say 0.87% is a very good number for a platform that depends 100% on geeks and tech enthusiasts.

[lejeczek]

Creak - I do not see steam.x86_64 in rpmfusion (which was my original point if you read carefully, and "..without further tampering").
Of course you do your own repo, how you do it - whether you contract it outside, do it internally, all technicalities, etc. does not matter. When you've done it (properly officially) it wins you back that ever important credibility - people say: yes, it is! serious, someone actually cares. (don't mention much larger customer base right from the start, etc, *what are we even taking about?)
Yet another repo? What is it? You have dozens of them?
Roughly citing myself - every popular distro - and they did what? Not even rpm, which would have been the second package? if I'm correct, again... *

All the distros one packaging system? - is another dream and a shame at the same time, for... the greatest community on this planet is for decades unable to spread and share this simple idea.

[Creak]

Creak - I do not see steam.x86_64 in rpmfusion (which was my original point if you read carefully, and "..without further tampering").

Indeed you mentioned that you "don't like messing cross-arch libs". But I responded to your other statement: "on Fedora I see rpm conflicts", and said that, by my experience, I haven't seen any conflict when installing Steam, and I didn't have to tamper anything afterwards, it "just works"™.

About the x86_64 package of Steam, it's normal that there is non of it since Steam is a 32-bit app only (and that's a shame not only for Linux, but for the other OSes as well). It makes quite some time now that applications are all proposing a 64-bit version, some are even only proposing this version. Valve is clearly late on this topic.

[Creak]

What would we gain is Steam was recompiled into a 64-bit app?

Less mixes between 32-bit and 64-bit libs in our OS. Which means less disk space footprint since probably most of the libs will already be installed by default. Maybe a very small performance boost (now that compilers are optimized for 64-bit app), but I wouldn't really count on that. Also, more 64-bit apps in the devs' environment would give more incentive to create 64-bit apps themselves.

I agree that it's far from a killer feature, but it would be a nice-to-have.

Edit:
And gathered here: http://serverfault.com/a/37364/377635

x86_64 cpus do have the no-execute bit in their page tables. I.e. this can prevent security exploits caused by buffer overruns. 32-bit x86 cpus do only support this feature in the PAE mode.