A few weeks ago, Canonical announced cross distribution support for Snap application delivery mechanism, one that could support mobile, desktop and server-based applications. The announcement ruffled some feathers within the linux community , who saw scant evidence of any other Linux distro supporting Snaps.
Snap is Canonical’s attempt to refine the app packaging and delivery mechanism on the Linux platform. The origin of Snap finds its roots in Click, a solution that Canonical created for its mobile platform back in 2014 ,to handle the complexity of delivering apps to Ubuntu phone and tablet users, an ecosystem far different from desktops and servers. Additionally, mobile also needed to confine apps and sandbox them so that they would not compromise the entire platform.
Click enabled developers to bundle all dependencies into a single app package , so users and developers didn’t have to worry about conflicting systems and app libraries. It allowed developers to use the latest libraries in their apps, to offer new features as they were decoupled from the libraries installed on the system.
Beyond mobile to servers and IoTClick evolved into Snap and Canonical extended its potential use to the server, cloud, Internet of Things (IoT) and desktop spaces. With the release of Ubuntu 16.04 in April, Canonical officially brought Snap to the Ubuntu desktop .
Canonical is also developing Snappy Ubuntu Core , a tiny Linux-based operating system for large-scale cloud container deployments, IoT devices and much more, and anything that needs transitional updates and tiny footprint. Snappy Ubuntu Core works more or less like Google’s Chrome OS and CoreOS where it offers transitional image based updates for the system and apps that can be rolled back. Simultaneously, it offers the confinement that is known in the container world.
Snap is the soul of that technology.
The Linux Mess of AppDeliveryThe existing app delivery model on Linux has many flaws. The Linux world is mostly divided into two camps of app packaging: rpm and deb . Also, there are different versions of the same distributions that use different libraries, so it becomes quite challenging for app developers to package apps for Linux.
As a result,app developers can’t take advantage of the latest libraries and offer more features to their users if the distribution is still using older libraries.
In most cases, open source app developers don’t package their apps for distributions. Popular or long-established apps are usually packaged by the distro developers. Newer or less popular ones are either packaged by the upstream for each distro they want to support, or not offered as a distro package at all. When anew version of an app is released, these developers test the app and then make it available for the distro. As you can see, instead of the app developer just writing one app for the entire platform, which in this case is Linux, there are many people bringing that app to users.
It adds more complexity.
There are cases where windows and MacOS get the latest versions immediately, as apps are packaged by primary developers, whereas Linux distros can take a while. That’s not all; some distros get them fast, and some have to wait for weeks or months.
In the case of commercial apps like Skype, Dropbox, Chrome, the onus is on the primary developer to package apps and offer binaries for different distributions. Many apps don’t work on older, yet supported versions of many distributions.
In a word, it’s a mess.
Even the creator of Linux, Linus Torvalds , is not happy with the existing app delivery model on Linux. He doesn’t offer binaries of his apps for the Linux platform citing this mess. Dirk Hohndel , the maintainer of SubSurface (a project started by Linus), explained , “The current situation with dozens of distributions, each with different rules, each with different versions of different libraries, some with certain libraries missing, each with different packaging tools and packaging formats… that basically tells app developers ‘go away, focus on platforms that care about applications’.”
“Application packaging is hugely important, but so is the provenance and maintenance of all the pieces involved,”agreed Gunnar Hellekson , Red Hat director of product management for Red Hat Enterprise Linux.
Snap was designed to bring some order to this state of affairs. But whether it will be adopted another question entirely.
Hellekson argued that tools like Snap don’t “magically solve interoperability problems between Linux distributions, and actually shift more responsibility for upkeep and security to the application vendors. In this way, they could make developing on Linux even harder despite the many benefits to the users.”
“Snap’s advantages directly relate to its disadvantages were, in essence, Snap is the equivalent of static linking ― it is convenient on the one hand, [but] creates duplication and challenges with respect to security (and security patching) on the other hand,” said Gerald Pfeifer , SUSE vice president of products and technology programs.However, not everyone is of the same opinion. Brandon Phillips , co-founder and Chief Technology Officer of CoreOS told us that containers are the future of apps on Linux. But Docker containers can’t be used everywhere . They have their limitations. What we need is a container-like solution, something like Snap.
During another interview , leading Linux kernel developer Greg Kroah-Hartman told us that Android has been doing containers “for your applications for eight or nine years now. Every application runs in its own namespace. It can’t see outside of that. That is the way you have to do it. That is the future of Linux and the way systems work.” He said that Snap is the same concept, same idea.
Snap goes cross platform The success of Snap very much depends on its adoption by the larger open source community. What good is an app format if no