appImage vs snap vs flatpak

[dos2unix]

Flatpak, Snap, and AppImage to understand their differences and advantages:

Flatpak:
- Sandboxing: Flatpak provides a secure and sandboxed environment for applications.
- Native Theme Support: It integrates well with the system, both in terms of functionality and visual appearance.
- Bundled Libraries: Supports bundled libraries, ensuring compatibility.
- App Portability: Offers full app portability across different Linux systems.
- Online App Store: Has an online app store for easy installation.
- Automatic Updates: Supports automatic updates.
- Multiple Parallel Installations: Allows unlimited parallel installations.
- Disadvantage: Flatpak packages tend to be larger than AppImage packages⁴.

Snap:
- Ease of Use: Snap emphasizes user-friendly installation.
- IoT and Embedded Devices: Originally developed for Ubuntu, it's now used on various devices, including IoT and embedded systems.
- All-in-One Packages: Snap packages include all required libraries and dependencies.
- Disadvantage: Larger package size and slower startup compared to Flatpak or AppImage.

Recently there has been some concern about Snap images not being tested for security before they are added
to the snap repo. Some snap applications have contained malware.

AppImage:
- Portability: AppImage offers a simple and portable packaging format.
- Decentralized: Although less centralized, it serves as a straightforward solution.
- Disadvantage: Lack of sandboxing and automatic updates.

AppImage doesn't have a central repository. Generally different applications have to be downloaded from different
sites. Some people consider this to be insecure, as anyone can be an AppImage repo.

In summary, choose Flatpak for security and sandboxing, Snap for ease of use, and AppImage for simplicity and portability. Each format has its strengths, so consider your specific needs when deciding which one to use!

 

[MikeRocor]

Do you know what are the internal formats/mechanics of each of these formats? And what OS infrastructure is required to use them?

I haven't paid much attention to these things and I'm not looking for an in-depth tutorial slightly more technical description of "what" as opposed to "why".

What would it take to make a flatpak, a snap or an appimage of some very simple application?

 

[dos2unix]

What would it take to make a flatpak, a snap or an appimage of some very simple application?

This isn't trivial, after you create your applications filles, binaries, scripts, text files, or whatever.
For snap you install snapcraft. Most Debian based distro's have this in the repos. For RPM based
distro's you can get snapcraft from the snap store.

sudo apt install snapcraft

mkdir my_snap_project
cd my_snap_project

Next create a snapcraft.yml file.

name: my-snap
version: '1.0'
summary: My awesome snap
description: A brief description of your app
base: core22
confinement: strict

parts:
  my-app:
    source: /path/to/your/app/files
    source2: /path/to/your/app/more/files
    plugin: dump

Run the snapcraft build command.

snapcraft

Next push your app up to the snap store.

snapcraft login
snapcraft push my-snap.snap

=================================================================

For flatpak it's different obviously.

flatpak install flathub org.freedesktop.Platform//22.08

you'll also need the SDK.

flatpak install flathub org.freedesktop.Sdk//22.08

mkdir myapp

# Here is a sample app.
#!/bin/bash
echo "Hello World!"

Create a manifest file here.

org.flatpak.Hello.yml

app-id: org.flatpak.Hello
runtime: org.freedesktop.Platform
runtime-version: '22.08'
sdk: org.freedesktop.Sdk
command: hello.sh
modules:
  - name: hello
    buildsystem: simple
    build-commands:
      - install -D hello.sh /app/bin/hello.sh
sources:
  - type: file
    path: hello.sh

Finally run the builder.

flatpak-builder

There isn't really a central store. You can host your own appImage repo if you like.

 

[MikeRocor]

Thanks! That is far and away more than I knew about them before.

 

[JasKinasis]

Personally, of the three - I prefer to use an appimage. And even then, I only use them as a temporary, stop-gap solution. If a native package is not available to me, I will typically install an appimage (from a trusted location) and will use that until I have time to download the source-code and build and install from source.

I did that some time back with OBS, when the version of OBS in the Debian 10 stable repos had a serious memory leak bug and the fix was not forthcoming. I used an appimage downloaded directly from OBS until I had time to build and install from source via their github repo.

Once I'd got OBS built properly, I removed the appimage and installed the version I'd built.

Snapcraft and flatpak are extremely over-complicated/over-engineered solutions to the so called problem of "Universal packaging" IMO. They introduce more problems than they solve. They don't always respect the installed system theme/colourscheme, they aren't always updated in a timely fashion. The snap store and flathub do not vet applications very well - both have had a lot of fake crypto wallets and other malware uploaded to them. There doesn't seem to be a very good process when it comes to verifying applicaitons.

As an early adopter of snaps on Debian - I quickly abandoned snapcraft when it added over 2 minutes to my boot times, thanks to all of the sand-boxing it sets up for each individual application.
A "Universal packaging system" shouldn't have to waste additional system resources at boot time.

Flatpak is probably the lesser evil of the pair. Sandboxing the flatpaks makes sense, because you can isolate untrusted flatpaks from the rest of the system. And like snap store, flathub has seen it's share of malicious programs uploaded to it. Flathub and the snap store are the biggest drawbacks with snap/flatpak IMO.

With appimages - they might not be sandboxed, but if you download them directly from the official site of the developers of the original software - you can pretty much guarantee that they will be safe. Well, unless the developers site has been hacked, but again - that's always a risk. Most notably, even the Mint website got hacked several years back and the attackers uploaded a modified .iso which was loaded with malware. It was only up for a couple of days before an administrator noticed the hack, but that was long enough for a lot of people to download and install it!

Which again, is why I always prefer to build and install from source whenever I need to, rather than using an appimage, flatpak, or god forbid snapcraft (which I vowed never to use again after my bad early experiences with snapcraft!).

So yeah, for me - I'd take an appimage from a trusted source over a flatpak, or a snap any time.

 

[MikeWalsh]

@MikeRocor :-

I can probably supply a bit more information about AppImages.

At its most basic, an AppImage is a "squash file system" package. And since the SFS has been Puppy's staple package format ever since the very early days, over 20 years ago, it won't surprise you to learn that one of our Puppy devs cobbled together some scripts a few years ago, to let anyone in our community easily construct their own AppImages. (A side "bonus" of the build-script is the construction of one of Puppy's 'ROX-app' executable directories alongside the AppImage.....or you can choose, instead, to create a 'self-extracting script'). BUT:-

.....as @dos2unix says above, the actual construction of the package is a relatively straight-forward matter. The skill lies in assembling the contents correctly, so that everything necessary is present, and also merges properly with the rest of the file-system + contents.

This is what takes the doing. And no; AppImages are NOT sandboxed, although you can assemble them with a .yml file to facilitate auto-updates.......where the developer/project supports such. Not all do. Not by a long chalk.

Properly-constructed AppImages contain absolutely everything needed for them to run. Frequently, this will include statically-compiled binaries, to obviate the need for the app to have to hunt round the system to find required dependencies. Since these will have been linked-in at build time, there's no need for lib-hunting.....though it does explain why statically-compiled items are often larger than their dynamic brethren. Because the deps are in fact built-in to the binary..!

I came across this diagram a while back. Explains it very simply:-

Invariably, AppImages "unpack" themselves into /tmp for the duration of a session - which explains the slight 'delay' you get with them - and run from there. The only system requirement for them to be able to do so is the presence of FUSE (Filesystem in USErspace), which is pretty much standard across the board these days.

The only time they CAN come unstuck is if the user attempts to run them on an older system than that under which they were constructed.....then you'll get complaints about stuff like the glibc/libstdc++.so.6, etc., being too old, although the afore-mentioned 'static' linking at build-time will largely negate this requirement (especially if done correctly).

One of the best central 'catalogues' I've found for these is here:-

www.appimagehub.com

A community where developers and artists share applications, themes and other content

www.appimagehub.com

.....though AppImages are often found where you least expect them. Many GitHub 'projects' offer them alongside the more usual package formats.


Mike.

 

[MikeRocor]

@MikeRocor :-

I can probably supply a bit more information about AppImages.

At its most basic, an AppImage is a "squash file system" package. And since the SFS has been Puppy's staple package format ever since the very early days, over 20 years ago, it won't surprise you to learn that one of our Puppy devs cobbled together some scripts a few years ago, to let anyone in our community to easily construct their own AppImages. BUT:-

.....as @dos2unix says above, the actual construction of the package is a relatively straight-forward matter. The skill lies in assembling the contents correctly, so that everything necessary is present, and also merges correctly with the rest of the file-system + contents.

This is what takes the doing. And no; AppImages are NOT sandboxed, although you can assemble them with a .yml file to facilitate auto-updates.......where the developer/project supports such. Not all do. Not by a long chalk.

Properly-constructed AppImages contain absolutely everything needed for them to run. Frequently, this will include statically-compiled binaries, to obviate the need for the app to have to hunt round the system to find required dependencies. Since these will have been linked-in at build time, there's no need for lib-hunting.....though it does explain why statically-compiled items are often larger than their dynamic brethren. Because the deps are in fact built-in to the binary..!


Mike.

OK then, thanks.

Appimage doesn't sound too rocket-science-ish.

I'm on Tiny Core and our ".tcz" format is a squashfs, usually mounted rather than extracted. In the case of .tcz files, however, one tcz might depend upon others so blah_blah.tcz is, if necessary, accompanied by blah_blah.tcz.dep which is a text file listing those .tcz files upon which blah_blah.tcz depends (each of which may have its own *.dep file).

 

[MikeRocor]

Which again, is why I always prefer to build and install from source whenever I need to, rather than using an appimage, flatpak, or god forbid snapcraft (which I vowed never to use again after my bad early experiences with snapcraft!).

Yeah it seems to me that just plain "installing" software is the best way.

I hadn't realized there might be such a boot time penalty for snaps. That seems like a deal breaker to me.

 

[ron.alan]

so consider your specific needs when deciding which one to use!

None of the above.

 

[The Duck]

Snap:
Recently there has been some concern about Snap images not being tested for security before they are added
to the snap repo. Some snap applications have contained malware.

As with any software the user should always check the integrity of the software that is being considered prior to downloading.

Snap packages are labeled / marked if they have been checked and tested for security.

If not checked or marked as being tested for security than don't download the package.

Simply enough if the user has a brain and uses it.

I've yet to experience any problem with any Snap packages.


I've used all of them and depending on the distro I choose to use depends on which package choice I will use.

Depending on the user choice of package the user needs to learn how to properly keep them maintained and updated.

 

[MikeRocor]

Simply enough if the user has a brain and uses it.

I'm afraid we're trending into a world where users (and drivers and voters and ...) are encouraged not to use those.

 

[Condobloke]

Is that what that thing is for ??!!....sometimes it hurts !