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