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