Sarah Dickinson
on 11 October 2017
elementary on why snaps are right for their Linux distro
elementary is the company behind the elementary OS Linux distribution and the associated app store. Celebrating their tenth anniversary this year, elementary began in 2007 with their first release in 2011. They are currently on their 4th release (Loki) and are working towards their 5th (Juno) with Jupiter, Luna and Freya as previous releases. At the Ubuntu Rally in New York, we spoke to elementary’s founder Daniel Fore and Systems Architect, Cody Garver, to discover what made snaps the right Linux application packaging format for their distro.
How did you find out about snaps?
We were searching for a confined app format and discovered snaps. The team at Canonical has been really friendly and even invited us to be on the technical oversight board which furthered our interest. There was really strong outreach to us and they clearly wanted us involved from the beginning so it’s a been great developer experience. We just weren’t getting that from any of the alternatives. Taking part in the Ubuntu Rally has helped us identify a few issues and solve them along the way too so it’s been a very useful event for us.
What was the appeal of snaps which led you to invest in them?
The confinement that snaps offers provides an extra layer of security. In some cases, third-party developers targeting our platform want to ship dependencies with their app that may turn out to be security-sensitive. Confinement means that we don’t have to spend a lot of time performing a security audit in order for developers to do this; we can both save time reviewing and keep our users safe.
How does building snaps compare to other forms of packaging you produce? How easy was it to integrate with your existing infrastructure and process?
We haven’t begun integrating snap building into our infrastructure just yet, but the simplicity of the format is really promising. At the moment we supply a lot of documentation and packaging templates to our third-party developers and still end up spending a decent amount of time helping them package their apps. Debian packaging can be confusing because it requires multiple files and folders in a very specific format and structure. Having a single snap yaml file seems much easier and makes packaging on our platform more attractive. Secondly, the format isolation allows for less opportunity to break the system or otherwise force abandonment – you can use newer libraries than the system offers without altering the base.
How do you think snap packaging helps your users? Did you get any feedback from them?
We expect our users to appreciate the security model that snaps have. Being able to enable runtime permissions or restricting to certain hardware access will be well received. It is a good message on the privacy side. Users are aware of the problems that unconfined package formats cause, even if they aren’t necessarily aware that lack of confinement is the problem and they tend to be upset with the general lack of stability that PPAs inevitably cause.
How would you improve the snap system?
One suggestion we would make is to improve the error messaging. In other words, make it more obvious for the developers on what steps need to be taken to fix any problems they encounter. There was a decent amount of discussion this week about changing some default options in the Snap yaml that will make snap file sizes much smaller. One concern that we have is the ability for large ISVs who don’t target our platform to be able to provide their own updates outside of the store and we’re interested to see where discussion goes on that.