4 ms·

Consider that FlatPak is popular for this case and distributing the way you describe isn't for a good reason: having to deal with all the many and varied depend

Consider that FlatPak is popular for this case and distributing the way you describe isn't for a good reason: having to deal with all the many and varied dependencies and configurations on any given distro is a giant pain in the ass. People have been screaming this at Linux Desktop evangelists for 20 years about this and mostly fallen on deaf ears, so it is no wonder Linux Desktop is still in a distant 3rd place in the desktop market.

dTal 4y ago
Distributing binaries (that run on any distribution) is not unpopular. Off the top of my head, Firefox, Blender, VSCode, and Arduino IDE are all distributed as simple tarballs with binaries + libraries inside. Many more applications are distributed as AppImages, which are not much more than self-extracting versions of those same tarballs. It's very simple: build against a mature version of GlibC, and bundle everything else. You know, exactly like you'd do on Windows.
- AnIdiotOnTheNet 4y ago
  This is a very recent trend that I am quite happy for, but it has not been the trend for the vast majority of Linux Desktop's existence and hardly encompasses even the majority of desktop software. > It's very simple: build against a mature version of GlibC, and bundle everything else. You know, exactly like you'd do on Windows. Windows has backwards and forwards compatibility guarantees that Linux userland simply does not have, and Windows doesn't have anywhere near the fragmentation that Linux has either. This is not nearly as simple as you claim it is or FlatPak wouldn't have been invented in the first place. I like AppImage a lot, conceptually, because of its simplicity. But that same simplicity, combined with the ludicrously fragmentary nature of Linux Desktop, has meant that I've had a lot more problems getting AppImages that work than I have getting FlatPaks that work.
  - account42 4y ago
    > Windows has backwards and forwards compatibility guarantees that Linux userland simply does not have, Not really. Linux base system libraries are quite good about compatibility. And it's not like Windows is 100% perfect here either. The main thing making this better on Windows is having an official SDK that allows targeting older versions from current compilers (within limits, rip XP support) while for Linux you get to put that together yourself. > But that same simplicity, combined with the ludicrously fragmentary nature of Linux Desktop, has meant that I've had a lot more problems getting AppImages that work than I have getting FlatPaks that work. The problem here is not the fragmentation (which mostly boils down to not everyone being on the same library versions rather than distros having completely different solutions) but rather broken AppImages or non-portable binaries that don't include things that they should or were compiled against a newer glibc etc. The source of that is again that there is no readily available SDK to create non-broken AppImages or portable binaries for Linux so not all developers will get it right. But instead of working on such an SDK, the big players focus on the overkill solution of shipping essentially an entire userland (except when they can't like with those pesky graphics drivers).

dTal 4y ago

Distributing binaries (that run on any distribution) is not unpopular. Off the top of my head, Firefox, Blender, VSCode, and Arduino IDE are all distributed as simple tarballs with binaries + libraries inside. Many more applications are distributed as AppImages, which are not much more than self-extracting versions of those same tarballs. It's very simple: build against a mature version of GlibC, and bundle everything else. You know, exactly like you'd do on Windows.

AnIdiotOnTheNet 4y ago
This is a very recent trend that I am quite happy for, but it has not been the trend for the vast majority of Linux Desktop's existence and hardly encompasses even the majority of desktop software. > It's very simple: build against a mature version of GlibC, and bundle everything else. You know, exactly like you'd do on Windows. Windows has backwards and forwards compatibility guarantees that Linux userland simply does not have, and Windows doesn't have anywhere near the fragmentation that Linux has either. This is not nearly as simple as you claim it is or FlatPak wouldn't have been invented in the first place. I like AppImage a lot, conceptually, because of its simplicity. But that same simplicity, combined with the ludicrously fragmentary nature of Linux Desktop, has meant that I've had a lot more problems getting AppImages that work than I have getting FlatPaks that work.
- account42 4y ago
  > Windows has backwards and forwards compatibility guarantees that Linux userland simply does not have, Not really. Linux base system libraries are quite good about compatibility. And it's not like Windows is 100% perfect here either. The main thing making this better on Windows is having an official SDK that allows targeting older versions from current compilers (within limits, rip XP support) while for Linux you get to put that together yourself. > But that same simplicity, combined with the ludicrously fragmentary nature of Linux Desktop, has meant that I've had a lot more problems getting AppImages that work than I have getting FlatPaks that work. The problem here is not the fragmentation (which mostly boils down to not everyone being on the same library versions rather than distros having completely different solutions) but rather broken AppImages or non-portable binaries that don't include things that they should or were compiled against a newer glibc etc. The source of that is again that there is no readily available SDK to create non-broken AppImages or portable binaries for Linux so not all developers will get it right. But instead of working on such an SDK, the big players focus on the overkill solution of shipping essentially an entire userland (except when they can't like with those pesky graphics drivers).