[AnIdiotOnTheNet]

It's 2018 and Linux still has issues with this? It's a complete non-issue on Windows. One wonders if you can really blame Valve for the Linux desktop community not being able to accomplish such a simple thing as running 32-bit applications along side 64-bit ones.

[Sylos]

It's not 2018 and Linux still has issues with this, rather it's 2018 and Linux is starting to have real issues with this.

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.

[majewsky]

> 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.

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

[Sylos]

I was thinking of openSUSE and Ubuntu, but you're right that openSUSE still has 32-bit libraries around.

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.

[gpderetta]

What are the issues exactly? 32 bit libraries are not installed by deafult in most distros because the vast majority of the software has been ported to 64 bits decades ago.

[AnIdiotOnTheNet]

Don't look at me, it's parent who has an issue:

> 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.

[detaro]

Not sure Windows is a good example there. The "thought given to compatibility" under Windows is typically "each application ships all the runtime redistributables, DirectX packages, ... it could need, because there's no standard for which ones are available", which solves the problem, but isn't through superior flexibility over hard-coded dependencies.

[AnIdiotOnTheNet]

But there is quite a lot of thought given to keeping applications that ran on previous Windows versions running on newer ones, without recompilation. And bundling all the non-system-provided dependencies with the application actually is a ton more flexible. In many instances, you can put the application's folder on a thumb drive and run it from there on a different computer. Try that with Linux applications without jumping through a ton of hoops, the first of which is "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?".

[uep]

I don't know why you're trolling all over this thread, but this makes it sound like you don't know what you're talking about.

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.

[AnIdiotOnTheNet]

> Why do you think you can't ship your non-system-provided dependencies on Linux?

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.

[HeadsUpHigh]

It's not a problem on linux whatsoever. On traditional package managers it just required some thought from the maintainer. Newer ones like flatpak make it even simpler.

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.