8 Ways Snaps are Different

by Alan Pope on 15 August 2019

Depending on the audience, the discussion of software packaging elicits very different responses. Users generally don’t care how software is packaged, so long as it works. Developers typically want software packaging as a task to not burden them and just magically happen. Snaps aren’t magic, but aim to achieve both ease of maintenance and transparency in use.

Most software packaging systems differ only a little in file format, tools used in their creation and methods of discovery and delivery. Snaps come with a set of side benefits beyond just delivering bytes in a compressed file to users. In this article, we’ll cover just 8 of the ways in which snaps improve upon existing Linux software packaging.

Easy publishing on your timescales

Getting software in officially blessed Linux distribution archives can be hard. This is especially true where the software archives impose strict adherence to a set of distribution rules. For the leading Linux brands, there can be a lengthy delay between a request for inclusion, submission and the package landing in a stable release.

External repositories can be setup and hosted by software developers. However, these software archives are often difficult for users to discover, and not straightforward to enable, especially for novices. The developer has the added overhead for to maintain the repository.

On the other hand, snaps are published in a central store, which is easily updated and straightforward to search and install from. Within a single day (and often faster), a developer can go from snapcraft register to claim the name of their application to snapcraft push to upload, and snapcraft release to publish their application.

Developers can publish builds for multiple processor architectures at their own pace without having to wait for distribution maintainers to rebuild, review, sponsor and upload their packages. Developers are in control of the release cadence for their software.

Automatic updates

With the best will in the world, most users don’t install software updates. Sure, that doesn’t mean you, dear reader. We’re confident you’re on top of apt upgrade, dnf update or pacman -Syyu each day, perhaps numerous times every day. A significant proportion of users do not update their systems regularly, though. Estimates place this anywhere between 40% and 70%. This can be even worse for unattended devices such as remote servers, or Raspberry Pis tucked away running an appliance

Modern Linux distributions have sought to mitigate this with background tasks to automate critical security updates, or graphical notifications to remind users. However, many users switch these off, or simply ignore the notification, leaving themselves at risk.

Snaps solves this by enabling automatic updates by default on all installations. When the developer publishes a new release of software to the store, they can be confident that users will automatically get those updates soon after. By default, the snapd daemon will check in for updates in the store multiple times a day

However, some users do not wish to have their software updated immediately. Perhaps they’re giving a presentation and want to use the current version they’ve prepared for, or maybe their Internet connectivity or allowance is limited. Snaps enable users to control when updates are delivered. Users can postpone them to update outside the working day, overnight, or later in the month

Users are also able to snap refresh to force all snaps to update, or individually with snap refresh (snapname). Auto refreshing ensures users get the latest security updates, bug fixes and feature improvements, while still retaining control where required.

One package for everyone

It’s commonly known that there are (probably) more Linux distributions than there are species of beetle on Planet Earth. Upon releasing a package in one format, users of all other distros will rise up and demand packages for their specific spin of Linux. For each additional package to be created, published and maintained, there is extra work for the developer(s). There’s a diminishing return on investment for every additional packaging format supported.

With one snap package, a developer can hit a significant proportion of users across more than 40 distributions, saving time on packaging, QA, and release activities. The same snap will work on Arch Linux, Debian, Ubuntu, Fedora and numerous other distributions built upon those bases, such as Manjaro, Linux Mint, elementary OS and CentOS. While not every distribution is covered, a large section of the Linux-using community is catered to with snaps.  

Changing channels, tracks and branches

When publishing software in traditional Linux distribution repositories, usually there is only one supported version or release of that software available at a time. While distributions may have separate ‘stable’, ‘testing’ and ‘unstable’ branches, these are typically entire repositories. 

As a result, it’s not usually straightforward or even possible to granularly populate the individual release with multiple versions of the same application. Moreover, the overhead of maintaining one package in those standard repositories is enough that uploading multiple versions would be unnecessarily onerous.

Usually a developer will build beta releases of their software for experts, QA testing or enthusiasts to try out before a release candidate is published ahead of a stable release. As Linux distributions don’t easily support multiple releases of the same application in their repository, the developer has to maintain separate packages out of band. Maintaining these repositories of beta, candidate and stable releases is further overhead.

The Snap Store has this built in for all the snaps. By default there are four risk levels called ‘channels‘ named ‘stable’, ‘candidate’, ‘beta’ and ‘edge’. Developers can optionally publish different builds of the same application to those channels. For example, the VLC developers use the ‘stable’ channel for their final releases and the ‘edge’ channel for daily builds, directly from their continuous integration system

Users may install the stable release, but upon hearing of new features in the upcoming beta may choose to snap refresh (snapname) --channel=beta to test them out. They can later snap refresh (snapname) --channel=stable to revert back to the stable channel. Users can elect to stick to a particular risk level they’re happy with on a per-application basis. They don’t need to update their entire OS to get the ‘testing’ builds of software, and don’t have to opt-in en-masse for all applications either

Furthermore, the Snap Store supports tracks, which enables developers to publish multiple supported release streams for their application in the store. By default, there is only one implied track – ‘latest’, but developers may request additional tracks for each supported release. For example, at the time of writing, the node snap contains separate tracks for Node 6, 8, 9, 10, 11 and 12 and the default ‘latest’ track which contains Node 13 nightly builds

Branches are useful for developers to push short-lived ‘hidden’ builds of their software. This can often be useful when users report a bug with the software, and the developer wishes to produce a temporary test build specifically for that user, and anyone else affected by the bug. The developer can snapcraft push (snapname) --release=candidate/fix-1234 to push a candidate build to the fix-1234 branch.

Delta uploads and downloads

With most of the traditional Linux packaging systems when an update gets published, all users get the entire package every time. As a result, when a new update to a large package is released, there’s a significant download for every user. This places a load – and cost – on the host of the repository, and time and bandwidth on that of the user.

The Snap Store supports delta updates for both uploads and downloads. The snapcraft tool used for publishing snaps to the Snap Store will determine if it’s more efficient to upload a full snap or a delta each time. Similarly the snapd daemon, in conjunction with the Snap Store, will calculate whether it’s better to download a delta or the full size snap. Users do not need to specify, this is automatic

Snapshot on removal

Traditional Linux packaging systems don’t associate data with applications directly. When a software package is installed, it may create databases, configuration files and application data in various parts of the filesystem. Upon application removal, this data is usually left behind, all over the filesystem. It’s an exercise for the user or system administrator to clean up after software is removed.

Snaps seek to solve this as part of the application confinement. When a snap is installed, it has access to a set of directories in which configuration and application data may be stored. When the snap is removed, the associated data from those directories is also removed. This ensures snaps can be atomically added and removed, leaving the system in a consistent state afterwards.

Starting in snapd 2.37, it’s possible to take a snapshot of application data prior to removal. The snap save (snapname) command will create a compressed snapshot of the application data in /var/lib/snapd/snapshots. The list of saved snapshots can be seen with snap saved and can be restored via snap restore (snapshot). Snapshots can be removed with snap forget (snapshot) to reclaim disk space

In addition, starting in snapd 2.39, an automatic snapshot is taken whenever a snap is removed from the system. These snapshots are kept for 31 days by default. The retention period may be configured as low as 24 hours, or raised to a longer duration. Alternatively, the snapshot feature can be disabled completely

Parallel installs

Existing packaging systems on Linux don’t cater well to having multiple versions of the same application installed at once. In some cases, developers are well catered for. Multiple versions of a small selection of tools are available such as gcc-6 and gcc-7 in the repositories, which can be installed simultaneously. However, this is only for specific packages. It’s not a universal constant however, that any packaged application could be installed multiple times with different versions

Snaps solve this with an experimental parallel install feature. Users can install multiple versions of the same snap side-by-side. Each can be given its own ‘instance key’ – which is a unique name to refer to the install. They can then choose which instance to launch, or indeed launch both. For example, a user may want both the stable and daily builds of VLC installed at once, to allow them to test both upcoming features while still being able to play videos on the stable release when the daily build is unstable.

Application discovery

Traditional software packaging is typically combined with a graphical package manager to make it easier for users to install software. For a long time, many of these graphical tools have languished in design and features, serving as a predominantly technical frontend to the underlying console package management tools.

For some years developers have been publishing their software in external repositories, PPAs, in GitHub releases pages or their own website download page.

The default tools don’t expose applications that aren’t part of the default repositories.  While some have had visual refreshes and featured updates, they still don’t enable users to discover brand new software hosted externally. This makes it difficult for developers to get their software in front of modern Linux distribution users.

The Snap Store solves this in multiple ways. The graphical desktop package managers GNOME Software and KDE Discover both feature plugins that can search the Snap Store. Moreover, a web frontend to the Snap Store enables users to browse and search for new applications by category or publisher

Making it easier to publish software in the Snap Store means that delivering a snap can become part of the standard release process for applications. Once developers publish their snap to the Snap Store, it’s immediately visible to users both in the graphical storefronts and on the web.

Developers can link directly to their Snap Store page as a permanent storefront for their application. The storefront pages show screenshots, videos, descriptions along with currently published versions and details of how to install the application. The store features buttons and cards, which can be embedded in pages and blog posts to promote the snap. Users are able to share these pages with friends and colleagues who may appreciate the application, which will drive other users to these snaps.

Furthermore, the Snap Advocacy team regularly highlight new applications on social media and via blog posts to draw user attention to appealing, up-to-date and useful new software. The team also regularly updates the list of ‘Featured Apps’ presented in both the graphical desktop package managers, and on the front page of the Snap Store web frontend.

Developers are encouraged to ensure their store page looks great with screenshots, videos, a rich application description along with links to support avenues. Application publishers can reach the Snap Advocacy team via the snapcraft forum to request their app is included in a future social media or blog update, or to be considered for inclusion as a featured entry in the Snap Store.

Conclusion

In this article I picked eight of the features that set snapcraft, snap and the Snap Store apart from other traditional and contemporary packaging systems. For many people a lot of the technical details of software packaging and delivery are of little interest. What most people care about is getting fresh software with security updates, in a timely fashion. That’s exactly what snaps aim to do. The rest is icing on the cake.

As always we welcome comments and suggestions on our friendly forum. Until next time.

Photo by Samuel Zeller on Unsplash