4 ms·

I know this isn't the point of your comment but: AppImage works everywhere, including Ubuntu. It a file called TheProgram.AppImage and runs like any other binar

I know this isn't the point of your comment but: AppImage works everywhere, including Ubuntu. It a file called TheProgram.AppImage and runs like any other binary would. Snap works primarily on Ubuntu and is pre-installed. `sudo snap install [package]` works just like `sudo apt install [package]` does. Flatpak technically works on ubuntu though it's not pre-installed: it's an `sudo apt install flatpak` away. AppImage is a great option: it's the equivalent of statically linking everything. Users only need to have the binary and they can run it. Developers bundle everything into that binary.

fnord123 5y ago
To chime in: I'm super impressed by flatpak. There is a small learning curve as with any tool, but once you get through it it works very well. Snap uses a compressed image format that makes startup horrid. And snaps don't seem to work well with hidpi resolutions when scaling is enabled (snap doesnt know about the scaling so it draws everything super small). I haven't used AppImage but between apt, snap, and flatpak, I really see flatpak as the winner for how games should be installed.
sdwolfz 5y ago
I played with Appimages a while ago, trying to create one from scratch with a Ruby interactive shell inside. It worked well until I tried it on an older Ubuntu, it gave me glibc errors. To make it work I had to find a docker image with an old enough glibc to use as my "compiler", then copy over everything to the Appimage. I also tried compiling an older glibc from scratch inside the Appimage, that solved nothing, as well as needing to install all the binutils that I wanted to embed in the Appimage and make sure the PATH does not contain any host os paths. It was a nice learning experience, but far from the "Easy to make, runs everywhere" marketing Appimages have. Does using muls libc and statically linking everything actually work out in practice? I read somewhere (HN comment, don't have reference) that it still might not be enough and your programs still need to the OS libc.
- rubicks 5y ago
  Changing out glibc for musl can be done if you control the linker invocations on the object files. This would be extremely difficult (but not impossible) for those like myself that use closed-source third-party shared objects linked against glibc.
- jcelerier 5y ago
  > To make it work I had to find a docker image with an old enough glibc to use as my "compiler", it's not like it is esoteric knowledge though: https://docs.appimage.org/reference/best-practices.html#binaries-compiled-on-old-enough-base-system https://docs.appimage.org/reference/best-practices.html#bina...
AnIdiotOnTheNet 5y ago
I really like AppImage and its one file = one application philosophy, but the unfortunate reality is that the distro landscape is so messed up that AppImage doesn't reliably work everywhere unless you take similar pains in building your application (old glibc, etc). Above the kernel, the Linux ecosystem just isn't designed to support the concept of binary application distribution, unless you want to maintain a separate package for every distribution you want to target and keep it up to date.

fnord123 5y ago

To chime in: I'm super impressed by flatpak. There is a small learning curve as with any tool, but once you get through it it works very well. Snap uses a compressed image format that makes startup horrid. And snaps don't seem to work well with hidpi resolutions when scaling is enabled (snap doesnt know about the scaling so it draws everything super small). I haven't used AppImage but between apt, snap, and flatpak, I really see flatpak as the winner for how games should be installed.

sdwolfz 5y ago

I played with Appimages a while ago, trying to create one from scratch with a Ruby interactive shell inside. It worked well until I tried it on an older Ubuntu, it gave me glibc errors. To make it work I had to find a docker image with an old enough glibc to use as my "compiler", then copy over everything to the Appimage. I also tried compiling an older glibc from scratch inside the Appimage, that solved nothing, as well as needing to install all the binutils that I wanted to embed in the Appimage and make sure the PATH does not contain any host os paths. It was a nice learning experience, but far from the "Easy to make, runs everywhere" marketing Appimages have. Does using muls libc and statically linking everything actually work out in practice? I read somewhere (HN comment, don't have reference) that it still might not be enough and your programs still need to the OS libc.

rubicks 5y ago
Changing out glibc for musl can be done if you control the linker invocations on the object files. This would be extremely difficult (but not impossible) for those like myself that use closed-source third-party shared objects linked against glibc.
jcelerier 5y ago
> To make it work I had to find a docker image with an old enough glibc to use as my "compiler", it's not like it is esoteric knowledge though: https://docs.appimage.org/reference/best-practices.html#binaries-compiled-on-old-enough-base-system https://docs.appimage.org/reference/best-practices.html#bina...

AnIdiotOnTheNet 5y ago

I really like AppImage and its one file = one application philosophy, but the unfortunate reality is that the distro landscape is so messed up that AppImage doesn't reliably work everywhere unless you take similar pains in building your application (old glibc, etc). Above the kernel, the Linux ecosystem just isn't designed to support the concept of binary application distribution, unless you want to maintain a separate package for every distribution you want to target and keep it up to date.