App images
Virtual environments and packaging The problem: when installs break other installs Language agnostic packaging · App images Python packaging · Ruby packaging · Rust packaging · R packaging |
App images
App images as a general concept mean that everything an application depends on is stored within it (often in a single file), even if that ends up containing duplicates of dependencies stored by other applications, or the system.
It is a way of ensuring you can run in more varied systems, and being robust to some longer-term changes, without having to specifically consider each system and historic changes.
App images are, in a sense, a lot more stable -- at the cost of each app being much larger.
It's also not a full answer -- e.g. some OS changes and major libc changes still affect apps, but the amount of shared surface/API is small and more manageable.
There are a few different implementations of that idea.
AppImage
The SUID sandbox helper binary was found, but is not configured correctly
Snap
Intent
Snap (and its origins, click) are intended as an implementation of the app images idea: packaging all the dependencies. This makes it easier to create packages that run on any ubuntu variant - or any linux variant potentially - e.g. letting you have newer or older libraries without creating dependency conflicts.
Yes, containers would allow the same, but would be overkill and a little harder to handle - isolation would actually be in the way of accessing filesystem, local networking, X and thereby any GUI.
Upsides:
- updates are smoother for users
- coexistence of more apps is easier for users - the package manager isn't as fussy
- certain development is easier (and less tied to distribution updates)
- if you as a dev target only the Ubuntu flavour of linux, anyway
- one way to avoid dependency hell
- apps being images also allows transactional/atomic updates, making it easier to do rollbacks, avoiding unknown half-broken states.
- makes it easier to sign apps
- distribution-agnostic in theory
- can be lightweight
Limitations/downsides:
- not so distribution-agnostic in practice
- not so lightweight in practice
- confusing why we need two independent package managers
- They take more space.
- Expect each graphical program to take order of 300MB almost regardless of what they do, and
- Expect to retain up to three versions of everything
- ...meaning that you will very quickly fill 10, maybe 20GB or more, with a relatively basic set of programs. HDD space may be cheap but SSD less so.
- It's not precisely static linking, but leads to the same bloat as static linking (though snap seems to allow for shared files more than e.g. AppImage(verify))
- security implications seem mixed - yes, the readonly thing is nice, and updates can be pushed out faster - but are arguably more on the application developer (verify)
- They are slower to start
- (than native installs, but also than flatpack)
- (because they are compressed filesystem images that need to be mounted first)
- They take more RAM(verify)
- the snap store is proprietary(verify)
- canonical ends up forcing it for some programs in ubuntu (increasing amounts of packages are snap-only, or only updated in snap)
- note that firefox was snap-ized at the request of mozilla, to get updates out faster
- does not integrate with your GUI settings as well
- (it wasn't initially made for desktop, it was made for cloudy stuff)
- the partial filesystem access may be secure, but also confusing to users
- my first experience was not being able to save my work at all but there's other issues like not being able to access network shares
In technical terms
A snap package is basically a compressed filesystem (based on squashfs) that can be mounted as a loopback filesystem. A service (snapd) ensures these run containerized.
From the app's view, it has
- mounted read-only access to the snap image (app+libraries)
- mounted read-only access to /
- a mounted writeable directory, like your own homedir
snapd - the daemon managing
snapcraft - the CLI
store - app store [1]
On size differences
For some things, you can install an apt version of the same - you get a single installed version of the same, in a shared dependency tree, that might in a few cases take Gibabytes less.
You can try to see the difference by doing
snap list
to see what's installed, see if there's an according apt package, and do
snap remove name apt install name
See also
flatpak