Snap

Canonical is planning an ‘All Snap’ desktop next year. It will likely be available side-by-side with the traditional deb-based installation we’ve been used to since 2004.

If the “All Snap” or “immutable” platform is to be a success, Canonical needs to get a grip on the broken, uninstallable, insecure, and outdated snaps provided in the snap store.

This is a long post, so feel free to skip to the ‘Solutions’ section for my positive thoughts.

Preamble

Until recently, I worked for Canonical on the Snap Advocacy Team. Some of the things in this blog post may have changed or been fixed since I left. It’s quite a long post, but I feel it’s neccessary to explain fully the status-quo. This isn’t intended to be a “hit piece” on my previous employer, but merely information sharing for those looking to control their own systems.

I’ve previously provided feedback in my previous role as Snap Advocate, to enable them to better control updates. However, a lot of this feedback was spread over forum threads and other online conversations. So I thought I’d put together some mitigations and the steps I take in one place.

This is a bit of a dayjob post, but as I maintain a bunch of snaps in my own time, I figured it’s not out of place here.

Typically when I (or indeed any developer) uses snapcraft to build a snap, a snapcraft.yaml drives the process. I’ll integrate some kind of CI or build system, and start publishing to the Snap Store. Usually, once created, the yaml doesn’t need much in the way of changes. Back when we first started building snaps, we were using Ubuntu 16.04 LTS systems. At runtime the snap would leverage the base of core. The core snap is a super minimal Ubuntu 16.04 LTS runtime environment.

On Thursday I mentioned we were restarting the Snapcraft Clinic. Basically we stand up a regular video call with engineers from the snap and snapcraft team & us from Snap Advocacy. Developers of applications and publishers of snaps are invited to join to troubleshoot.

There was nothing especially secret or private discussed, but as we don’t record or stream the calls, and I don’t have direct permission to mention the applications or people involved, so I’ll keep this a little vague. In future I think we should ask permission and record the outcomes of the calls.

At work we have a forum where developers can discuss packaging Linux applications, specifically as snaps. Sometimes developers just want to pair through a problem to get it either resolved for themselves, or for whatever is blocking to be handed off to the right people.

One strategy for supporting developers we found effective was via regular live video conference. So last year we started the Snapcraft Clinic. On a semi-regular basis we dedicate time to join with anyone who has technical issues with snapping, to help them.

Before last week, I’d never heard of SonoBus. While on holiday I’d packaged up Spot - a Gtk Spotify client, which I wrote about recently. The next day I made a snap of SonoBus too! I did this because while there were binary builds for Windows and Mac, there was no binary release for Linux, other than in the Arch User Repository.

For those that, like me, didn’t know about SonoBus, it’s an “easy to use application for streaming high-quality, low-latency peer-to-peer audio between devices over the internet or a local network”.

I had a few days off work this week. It was very enjoyable to spend a bit more time with the family, doing some jobs around the house, going for walks, and generally nothing else, thanks to The Event.

However, in the quiet moments I still find myself browsing around, stumbling on new software I know will be enjoyed by my friends on Linux, and feel compelled to package it up, as a snap. This time around I found a post on /r/gnome about “Spot” a Gtk/Rust Spotify client.

This is an early PSA aimed at developers who publish snaps in the Snap Store. They can probably skip this preamble, but for anyone else here’s some backstory in case you’re bored interested.

Preamble

Snaps are confined software packages for Linux. They were originally designed / intended for IoT use cases so are optimised for size, bundling dependencies, are compressed on disk and auto update. They can also be used to package server software, like NextCloud, and desktop software like Signal Desktop. There’s millions of desktops, routers, servers and other interesting devices with snaps installed.

Last week I wrote a blog post titled null which did rather well! Note the giant (for my blog) spike on the right of this goaccess graph.

That’s the Hackernews effect. It was super to see the conversations over in the comments there. Quite proud to get 3 blog posts and one git repo on the front page of HN in the first month of the year. Don’t expect me to keep that momentum up, but we’ll come back to that another day.

I quite like to break things. While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. Some developer friends of mine have lamented that they didn’t show me software before they released it. Because I sometimes find annoying bugs immediately after they release.

Here’s some fun examples of pushing the boundaries of software, sometimes by doing things a little “out there”, beyond what the developer expected or tested.