Canonical To Focus On A New, More Modular Snapcraft - Current Codebase Goes Legacy

[arun54321]

What are you talking about?

If every app comes with their own dependencies and don't share runtimes, then the total app sizes will get bigger.

[Mani]

It doesn't happen on other platforms.
I gave an example earlier about app size:
Windows: 27 MBs
macOS: 14 MBs
appimage: 72 MBs

To be honest, I have about a hundred flatpaks installed and together they have a size of less than 10 GB, the runtimes as well as the applications are deduplicated on the file level and the overall system grows in O(ln(n)), where n is the number of applications.
On the other and windows is itself a base runtime of more than 20 GB, without a single app installed. Additionally the installation size growes with O(n) which is a lot faster if you install a crapload of applications.

[iskra32]

Does anyone notice that Appimages are a bit more underrated compared to Snaps and Flatpaks? I actually had the best experience with them probably because they are not sandboxed, so they don't have all the issues that are caused by sandboxing, from which both Snaps and Flatpaks suffer. They also usually take less disk space. But I guess that the fact that they aren't sandboxed is precisely the reason there is less attention to Appimages.

Linux users will complain that windows requires you to download random binaries from the internet, doesn't sandbox proprietary programs, has apps bundle their own libs(rather than have runtimes like Flatpak), and then will proceed to recommend appimages

[user1]

Linux users will complain that windows requires you to download random binaries from the internet, doesn't sandbox proprietary programs, has apps bundle their own libs(rather than have runtimes like Flatpak), and then will proceed to recommend appimages

Well then I'm not one of such users. Personally, I don't even like sandboxed software even if it's proprietary because I'm against hindering usability in the name of security. I also don't have problem downloading random binaries from the internet because I trust all the software I use.

[Siuoq]

My personal experience with AppImages was the opposite. Some tended to SEGFAULT on launch, with no apparent way to debug the issues. No centralized way to manage updates, so some apps auto updated on launch while others required manual checking and re-downloading.. And updating meant redownloading the entire bundle as opposed to incremental updates in Flatpak or modular updates in distro-provided packages. Plus they felt alien, residing in some random directory (eg. ~/Downloads) as opposed to an out-of-sight system directory. In my personal experience, AppImages are an example of software packaging done wrong.

I think a standard over tar.gz can be useful. Less distro dependent than rpm/deb, and still manageable with a package manager. Ofc rpm/deb, tar.gz, flatpak/snap still will be needed, but in some cases, on an exotic but not too exotic distro, AppImage (or an interface over tar.gz) can have advantage over anything else (mostly over tar.gz)

[VanCoding]

Can't we all just agree that Nix is the best package manager?

[tildearrow]

Does anyone notice that Appimages are a bit more underrated compared to Snaps and Flatpaks? I actually had the best experience with them probably because they are not sandboxed, so they don't have all the issues that are caused by sandboxing, from which both Snaps and Flatpaks suffer. They also usually take less disk space. But I guess that the fact that they aren't sandboxed is precisely the reason there is less attention to Appimages.

Exactly this. AppImage is a very simple format that works like macOS Bundles, and is easy to use like the latter.

I wish I could propose OptApp already, AKA extracted AppImages in /opt, and /opt having 777 permissions or at least 775 with group set to admin or something.

[Vorpal]

Can't we all just agree that Nix is the best package manager?

Conceptually I agree. It is a really interesting approach. However I tried NixOS (several years ago and not for very long) and found it awkward to use. Maybe it is better now, maybe I could get used to it.

As I remeber it the issues where

1. Not a good coverage of available packages for a desktop
2. Source based distro, or at least some things had to be compiled.
3. If the thing you want to change was not available in the declarative system configuration you were essentially out of luck and "please send a patch".
4. Poor documentation (not for Nix, but NixOS).

Maybe some or all of these have been fixed, but it put me off it back then.

[Vorpal]

Exactly this. AppImage is a very simple format that works like macOS Bundles, and is easy to use like the latter.

I wish I could propose OptApp already, AKA extracted AppImages in /opt, and /opt having 777 permissions or at least 775 with group set to admin or something.

That has an advantage over compressed AppImages in that it would allow deduplication when using btrfs or zfs. Though that may be a moot point if two AppImages use diffrent builds of the same version of a library.

[szymon_g]

Thats too late too little.
No Distro, desktop, project beside Canonical and a few companies support Snap.

plenty of decent closed source software is in the snaps ("plenty" by the linux).