App images

From Helpful
Jump to navigation Jump to search

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

https://askubuntu.com/questions/1512287/obsidian-appimage-the-suid-sandbox-helper-binary-was-found-but-is-not-configu

Snap

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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)
  • 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

https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
https://blog.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app

flatpak

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.