Why isn't it as popular if it's so handy and useful?
>>108784401fuse2
Letting jeets have access to the internet turned out to be a bad idea.
>>108784401It needs external tools like Gear Lever to be usable (updates, and integration into the desktop environment); the Appimage team officially endorsed a community Appimage update tool project, but even that got overshadowed. Otherwise, it is a worse version of Flatpak.- Appimage being originally dependent on now deprecated libFuse2, which was already in maintenance mode (Appimage dev claimed the phasing out of Fuse2 was a corporate conspiracy). The transition to libFuse3 took years, and older Appimages still need libFuse2.- No sandboxing or infrastructure to restrict app access to your files (now standarized in Flatpak under the XDG portal system).- Appimage devs burning bridges and starting unnecessary beefs (like calling OBS studios devs corporate shills in their own GitHub for prioritizing Flatpaks releases over Appimage).
I use it when there's no native packages for something, it's better than flatpaks
>>108784401>just works>doesn't need 800MB for what would otherwise be a 20MB packageI really don't understand it.
>>108784401it didnt fail im literally running an appimage rn
>>108784401I use it regularly, I don't see any problems.
>>108784605Why don't they just do what the SDL devs did and create a compatibility wrapper library? Talking about something like this: https://github.com/libsdl-org/sdl2-compatCouldn't that work?
>>108784752>better than flatpaksyou forgot to say it's WAAAY better than flatpaks
>>108784401Dunno what you're talking about, it works fine as a portable executable format.
>>108784401>Why did AppImage fail?No, an amount of freeware does prefer AppImages over flatpak many reasons.Also the format is stagnant where things like this can happen. >>108784476
>>108784896the problem with fuse2 was mostly dynamic linking, it's fixed now since they static link that now for the newer runtimefuse3 cant possibly be used even with compatibility shims because it asks for root permissions which defeat the whole point of mounting a squashfs system with fuse for that use
>>108784605>Otherwise, it is a worse version of Flatpak.Not at all these two are architectially diffrent, Appimages kind of works like a selfextracting zip while Flatpaks are much more similar to docker and podman.>- Appimage being originally dependent on now deprecated libFuse2, which was already in maintenance mode (Appimage dev claimed the phasing out of Fuse2 was a corporate conspiracy). The transition to libFuse3 took years, and older Appimages still need libFuse2.The thing that's holding back Appimage is the Devs hands down.>- No sandboxing or infrastructure to restrict app access to your files (now standarized in Flatpak under the XDG portal system).Yet, flatpaks have horrible integration with the system and has a lot of bullshit with it, to the point were if you need a browser, IDE and many similar things you are better of not installing them as flatpaks.
>>108785186i want to add that what people fail to aknowledge that appimages are basically self extracting executablesthere's nothing wrong about that but is presents the same exact issues of program distributing as tar gz, some people fail to NOT bundle shit like stdc++ libgcc libgl, also there's several problem with namespaces regarding the linux linker, let's say you ship a dynamic library with the appimage and systemwide's mesa wants that same library with a slightly different version (mesa imports a fuckton of libraries at runtime btw), it doesn't necessarily need to be the same soname, well there you have symbol conflicts and you have probably to spend hours to fix that shit, granted you are lucky enough to manage to solve it.That's why people have come up with half solutions like flatpak, because flatpak says fuck it and ships its own runtimes (INCLUDING THE GRAPHICS DRIVER AND XLIB OR LIBWAYLAND WHICH IS A FUCKING ABHORRENCE), the problem is that runtimes have an expiration date so no decent forwards compatibility. My opinion is that linux application distribution won't improve until they decide to do something with the linker (ld. so) to address this, but the glibc guys don't really seem to give a shit
