4 ms·

Why would they not accept it when it's functionally the same as "downloading an exe and double clicking" which people seem to like about windows? If they don't

Why would they not accept it when it's functionally the same as "downloading an exe and double clicking" which people seem to like about windows? If they don't want the container, they can typically compile the source too.

Dalewyn 4y ago
Windows executables are not containers, both in the technical and laymen sense.
jeroenhd 4y ago
Because that exe is a gigabyte in size, needs a special globally installed runtime for some reason and conflicts with my firewall rules. Even AppImages somehow manage to extract themselves to locations that conflict with other tools or earlier versions of the same tool. I have one server with a complex firewall configuration that simply won't work well when I install Docker on it. I end up finding a lot of alternatives for what would otherwise be obvious solutions because projects stopped shipping binaries and replaced them with Docker containers. I'll gladly make use of the compilation approach thanks to software available in the AUR. The whole "let's ship a copy of Debian to make my 400kB binary run" approach is as tiresome as "let's ship a copy of Chromium so I don't need to learnddesktop UI". I know how terrible the dependency management situation on Linux is (I myself have had to resort to building software in chroots because of glibc being outdated) but the "modern" approach seems to add more trouble than it solves when I try to run programs like this. On many distros these problems have luckily already been solved. On Ubuntu that means I'll often be using an outdated version of the program that works just as well and on Arch (based distros) that means waiting for a compile every other update, but I've given up on tools that come with an entire ecosystem.
badsectoracula 4y ago
That isn't the experience with flatpak though, flatpak is the same as using apt-get or any other package manager except instead of getting stuff from your distro's repositories you get them from some flatpak repository you have to configure (some distros that provide flatpak might have flathub preconfigured, though not all of them do that). AppImage does provide that "download an exe and double click" experience but it assumes you have made said portable Linux binaries (and they still have the drawback of dragging in a bunch of libraries you most likely already have in your distro).
smoldesu 4y ago
> If they don't want the container, they can typically compile the source too. Why not do it in reverse? Offer binaries for the people running regular systems, and then let people with irregular configurations compile or containerize the program themselves. Seems like you'd save on a lot of redundant packaging and wasted data that way.

Dalewyn 4y ago

Windows executables are not containers, both in the technical and laymen sense.

jeroenhd 4y ago

Because that exe is a gigabyte in size, needs a special globally installed runtime for some reason and conflicts with my firewall rules. Even AppImages somehow manage to extract themselves to locations that conflict with other tools or earlier versions of the same tool. I have one server with a complex firewall configuration that simply won't work well when I install Docker on it. I end up finding a lot of alternatives for what would otherwise be obvious solutions because projects stopped shipping binaries and replaced them with Docker containers. I'll gladly make use of the compilation approach thanks to software available in the AUR. The whole "let's ship a copy of Debian to make my 400kB binary run" approach is as tiresome as "let's ship a copy of Chromium so I don't need to learnddesktop UI". I know how terrible the dependency management situation on Linux is (I myself have had to resort to building software in chroots because of glibc being outdated) but the "modern" approach seems to add more trouble than it solves when I try to run programs like this. On many distros these problems have luckily already been solved. On Ubuntu that means I'll often be using an outdated version of the program that works just as well and on Arch (based distros) that means waiting for a compile every other update, but I've given up on tools that come with an entire ecosystem.

badsectoracula 4y ago

That isn't the experience with flatpak though, flatpak is the same as using apt-get or any other package manager except instead of getting stuff from your distro's repositories you get them from some flatpak repository you have to configure (some distros that provide flatpak might have flathub preconfigured, though not all of them do that). AppImage does provide that "download an exe and double click" experience but it assumes you have made said portable Linux binaries (and they still have the drawback of dragging in a bunch of libraries you most likely already have in your distro).

smoldesu 4y ago

> If they don't want the container, they can typically compile the source too. Why not do it in reverse? Offer binaries for the people running regular systems, and then let people with irregular configurations compile or containerize the program themselves. Seems like you'd save on a lot of redundant packaging and wasted data that way.