That, combined with improved Wine compatibility, means that a lot of Windows games already run great on Linux, though with the obligatory performance hit due to driver differences and such. Hopefully once Vulkan support matures on both platforms we'll start seeing parity, especially with games that have a native Linux port or were Linux-first.
[1]https://wiki.debian.org/Steam#A64-bit_systems_.28amd64.29
The only issue is that I can't get Hardware Accelerated Decoding to work in Steam Streaming. I believe that's because I don't have the 32bit libraries and associated dependencies for doing it installed and that's the whole point of me going the flatpak route!
Other than that, works beautifully. Didn't go flatpak for Spotify though.
> I always have problems just installing the client because of the 32bit architecture
This is trivial and completely not a problem on Windows. Why is it a problem on Linux? Because there's no thought given to compatibility, it is just assumed that the only software anyone cares about will be compiled from source against the hard-coded library names and paths of any specific distro.
Why do you think you can't ship your non-system-provided dependencies on Linux? This is the common complaint about Linux, that you have to bundle a bunch of dependencies if you want it to run everywhere. You can also ship a single directory containing your application that is runnable wherever you drop it.
> "how do I know which files belong to this application, since they're spread all over the file hierarchy and mixed in with everything else?"
Just an FYI, ldd <binary> will tell you the libraries you depend on, but if you're shipping all non-system-provided dependencies, there shouldn't be anything that points outside of your directory other than libc.
I don't think that. It's just that:
> but if you're shipping all non-system-provided dependencies, there shouldn't be anything that points outside of your directory other than libc
In other words you have to ship most of what other operating systems consider to be part of the base system, because Linux doesn't provide a standardized basesystem at all. Hell, even depending on libc can be a problem, NixOS even manages to break AppImage because of how ld.so works, and to top it all off glibc abhors static linking.
Windows on the other hand just lets you bundle everything with your application including libraries that might have vulnerabilities without any form of sandboxing and no formal mechanism under which they can be updated. On linux on the other hand you can rely on the distro to ship patched versions of system libraries while the application itself is much more limited in regards of permissions.
Windows is the only desktop OS where 32-bit is still commonly used. On Linux, you nowadays generally don't have any 32-bit applications installed. Many Linux distributions don't offer 32-bit support anymore at all, because you'll have a seriously hard time finding hardware that doesn't support 64-bit.
With Steam however at the moment still only being available as 32-bit, you need 32-bit versions of the libraries that Steam uses. Distributions not hosting 32-bit libraries anymore, means you need to get these libraries in a different way.
Many distributions now actually offer you to install a Steam installer, which then gets the necessary 32-bit libraries from elsewhere.
You can also install Steam through a new package format, called "Flatpak", which includes all the necessary libraries directly in the package.
But these are all new workarounds and may still have problems. Flatpak in fact has only turned 1.0 a few days ago.
Which are those distributions? It's true that most don't offer regular applications, but at least for my distro (Arch), there is still a 32-bit repo for 64-bit systems, with various system libraries and applications that are only available as 32-bit (besides Steam, this includes Wine and various emulators for old consoles): https://www.archlinux.org/packages/?repo=Multilib
In the openSUSE Leap 15.0 standard repos, there's 6554 packages named "lib..." and 1368 named "lib...32bit", so roughly 20% of libraries have a 32 bit version still, which obviously could well be enough to contain all the libraries needed for Steam. (In total, there's 36237 packages, of which 1804 are 32 bit.)
With Ubuntu, I'm not entirely sure, as I don't run it, I've just heard that Lubuntu is having problems, because they would still like to support 32-bit, but with other Ubuntu flavors not anymore being released with 32-bit support, they're having trouble keeping it up. Might just be proper testing of the 32-bit libraries, though.
Well, and then there is obviously more niche distributions, which never bothered with 32-bit. Chakra Linux, for example, is so niche, they don't even provide any GTK applications in their main repository, and I think no 32-bit packages either. They do have a community repository, which has more stuff in it, but even there, I can only find around 20 packages with 32-bit support.