Now, if they would just automatically move to a ~/apps folder, be executable and indeed, in the menu. My love for AppImage would grow orders of magnitude. Even more if they could self update.
Right now, snaps are the only universal packaging format that really gives me a smooth experience (install experience that is.)
I've never though about it but I guess it also makes them executable, since I've never had to do that myself.
It doesn't handle removing the AppImage, but you can always just delete the file from ~/apps.
https://github.com/TheAssassin/AppImageLauncher/releases
;)
i fail to see what problems we've solved. it seems to me we've just duplicated the problems of competing packaging standards across distros, except now they all take up more resources and disk space than before.
it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging.
Any of those can be installed on most big distros, so you only need to release one for your app. Though I would use only docker for services and only flatpak or appimage for apps. Snap is proprietary; only Canonical runs a server.
5-7 years ago, i could "apt upgrade" and upgrade, nearly, my entire box.
Now i have to manually upgrade DEBs, have separate systems or upgrade/management options for AppImages, Flatpaks, Snaps, docker images.
it's a mess and it makes keeping up with security patches an absolute nightmare.
Now, if you're lucky, apps do all their individual checking if an upgrade needs to be done and you do apps one at a time, piece meal, which requires a lot more time from end users.
I now spend more time managing my machine than using it.
so yay for devs saving some time on their end ,or something.
Speaking about AppImage only:
They've solved the problem of requiring third party middlemen to include our package in a repo, using updated versions on older "unmaintained" distros, using old versions on the latest distro, using two different versions at once, and being able to store applications on different media.
> it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging
Unfortunately this seems to be the best that can be done with the Linux Desktop community's extremely fragmentary and complexity-worshiping nature. There is no agreement on what constitutes the base "Linux Desktop" platform, and very little ABI back and forward compatibility.
how do you propose to have software depending on, say, Qt 5.15 for hidpi bugfixes and ffmpeg 4.3 for codec support, available for users stuck on ubuntu 16.04 or debian jessie ?
It asks whether an AppImage should be integrated (with .desktop files, etc.) upon launching one and does everything automatically, even on my system running Arch+i3 where I except little to work automatically.
There's a workaround for almost everything. Wherever there is a workaround, the problem becomes less severe. As a result, it is less likely to get fixed.
There is nothing preventing AppImages to work like app containers on Mac OS except lack of integration that comes out-of-the-box. Advocating for that integration becomes more difficult, when you can "just open the terminal and...".
I did use a terminal to install the AUR package on my system, however. ;)