Discuss your stance towards AppImage files.
Is the violation of UNIX principles and the general "bloatyness" a price you like to pay in exchange for cross distribution compatibility and an escape from dependency hell?
AppImage is a format for distributing portable software on Linux without needing superuser permissions to install the application.[1] It tries also to allow Linux distribution-agnostic binary software deployment for application developers, also called Upstream packaging. Released first in 2004 under the name klik, it was continuously developed since then, renamed in 2011 to PortableLinuxApps and 2013 to AppImage.
>>61103454
Is not entirely a violation of the Unix principle, unless misused (as it probably will).
Has more advantages in my opinion and it will replace any distro that is not directed to power users, so I expect a distro based on AppImages to come in the next year.
The problem is the fragmentation in package managers. Each one puts the libraries to different places and do not always provide same versions of the package.
The solution would be for distro developers to make some kind of agreement on library naming and placing in the system. It would also help if they all used same naming so if you do apt install x or emerge x you would get same stuff.
Now dumb retards are trying to fix this by static compiling and it will propably become popular because it just works instead of the huge shit is apt/rpm.
Can we ever have anything nice?
>>61103454
Flatpak is technically superior. Appimage doesn't have dependency checking and resolution. I've had an experience where appimage need some library, it show terminal error, but from gui noob friendly experience, you'll never know what's wrong
>>61105246
>Now dumb retards are trying to fix this by static compiling and it will propably become popular because it just works instead of the huge shit is apt/rpm.
You mean the suckless guys?
I'd rather use AppImage than Flatpak or Snaps, which have their slew of problems.
>>61105246
>>61105327
AppImage doesn't statically link.
Static linking and banning dlopen() is the only way to make truly portable binaries.
But then not distributing source code is retarded.
>>61105398
Exblain!
Other than "muh init system", flatpak and snap are better as distribution system.
As a portable application, Appimage is on it's own
>>61105444
My opinions on it might not be valid anymore, since I haven't kept up with their progress. Last I had checked, Flatpak relied on systemd, and Snaps needed a modified AppArmor to even work properly. They didn't look very promising at the time. AppImage on the other hand looked very appealing since you didn't need to install anything to get applications running.
>>61103454
is it really all that bloaty when paired with modern filesystems with dedup capabilities?
>>61105584
>systemd,
>AppArmor
Both still hold true, most likely will never change. But most people don't have any problem with that.
> didn't need to install anything to get applications running.
See >>61105251 and it need application developers to check it's functions on each and every version of distro. No developer want to do that.
>>61105584
This, Flatpak is technically inferior, why do they even bother?
>>61103454
No thanks. Don't want to make it easier to install proprietary garbage.
>>61103454
That's basically diverting from what made linux so great in the first place - package management. Why would someone want this?
>>61103454
finally after 22 years linux have catched up to windows
>>61106205
Because people like >>61106964 exist
>>61103454
Unless you want an old version of something or something that has an unmaintained package why not just use packages? I could see it as an alternative, not replacing packages entirely.
>>61107574
Is more likely winfags want a simple installation, see >>61107509 and >>61106964