Canonical, the UK based organisation which supports Ubuntu, has been developing a new method for working with software packages which many of us are aware of since April 2016. The new technology, which has appeared in some experimental editions of Ubuntu, is called Snappy. Snappy packages are supposed to have a number of advantages over software packages common to most other Linux distributions. Five characteristics of Snappy packages in particular stand out.
= > The OS and application files are kept completely separate, as a set of distinct read-only images.
= > Transnational, image-based delta updates for the system and applications that can always be rolled back.
= > Files are read-only, which means they cannot be tampered with and can be updated perfectly and predictably every time.
= > Delta management keeps the size of downloads to the bare minimum.
= > Signatures and fingerprints ensure you’re running exactly what was published by the developer.
As you keep on reading this article you may want to check this post about Snapcraft.
I had been reading a lot about Snappy being used on mobile devices and Snappy packages being developed for embedded devices and the much-hyped Internet of Things. I have also heard rumours Ubuntu’s desktop edition may move to using Snappy packages by default in the near future, depreciating APT and .deb packages. However, it was not until recently that I found time to experiment with Snappy and see how the new package manager compared against other Linux package managers. The Ubuntu website has a tutorial for setting up a virtual machine running a minimal edition of Ubuntu and the Snappy package manager, a brief introduction to snapcraft. I followed the instructions provided and soon had a virtual machine running with a bare bones, text console interface. I was able to sign into the minimal operating system and begin experimenting.
One of the first things I noticed upon logging into my virtual instance of Ubuntu was that there is a welcome message letting us know .deb packages were not being used on the system, instead we should use Snappy. Despite the message, I did find the low-level dpkg package manager was installed and I could bring up a list of about three hundred .deb packages which apparently made up the base system. However, trying to run apt-get to install or remove packages caused a message to be displayed letting me know I should be using Snappy rather than apt-get. I suspect running the two package managers together on the same system is not recommended.
While Snappy can perform several actions, I want to focus on seven core commands the Snappy package manager recognises. The first is snappy info. Running snappy info display some basic information about our operating system and what it is running. The summary is very short, but it can give us an idea of what kind of hardware we are running on and the applications installed. We can extend the command a little and run snappy info <package> in order to get a very brief summary of information concerning a specific package.
The second command I experimented with was snappy list. Running this command will show us a list of packages currently installed on the system. Modifying the command to snappy list -v will display all the installed packages along with their version numbers. Since we can have multiple versions of each package installed, the active version of a package is marked with an *. This means if we have, for example, two copies of a web server on our system, we can identify which version is actually running. We can further extend the list command a little to find out which Snappy packages can be upgraded. Running snappy list -uv shows our installed packages with an * next to items that can be upgraded from Snappy’s software repository.
Speaking of updates, the snappy update command will update all packages installed on the operating system. So far as I can tell, all packages are always upgraded to their latest version. I was unable to find a way to simply upgrade one specific package in my test environment. However, I was able to upgrade all packages and then rollback unwanted upgrades, which brings me to the next command.
When we have upgraded a package and found we preferred the older copy of the software we can rollback to a previous version. This is done using the snappy rollback <package> command. Without any further arguments, Snappy will rollback the given package to its previous version. However, we can also specify which version of the package we want to be using. We can do this by running snappy rollback <package> <version>. Perhaps counter-intuitively, it is possible to use the rollback command to upgrade to a newer version of an installed package. This means the rollback command can activate any version of a Snappy package, whether it is older or newer than the currently active version.
Snappy allows us to search through its repository of software using the search command. Running just snappy search will display all packages currently present in the remote repository. We can hunt for specific types of software by running snappy search <pattern> which will return packages with names similar to the provided pattern.
The two final, and perhaps most important, commands are snappy install <package> and snappy remove <package>. These two commands install software from Snappy’s repository and remove all versions of an installed package, respectively. So far as I can tell, there is no way to remove one version only of a Snappy package. I suspect this is because Snappy installs a base package and then applies delta updates to the package rather than maintaining multiple whole versions of an application.
I made a few observations while experimenting with Snappy. One is that Snappy appears to work fairly quickly. Transactions are not instant, but they do happen rapidly. The packages I downloaded and installed from the software repository appeared to be about an equivalent size to .deb packages. I did not find Snappy packages to be unusually large.
At the moment there appear to be very few Snappy packages available to try. I found a simple terminal echo program, a web server, some hardware specific packages for various embedded devices, but little else. It may be I was using a testing repository just for people who want to experiment, but at time of writing the range of functionality we can get from Ubuntu’s Snappy repository is limited. With regard to the packages in the demo repository, there is not much information to be had about them. The descriptions provided by Snappy for each package are quite short and do not tell us much about what each package does.
When we install new Snappy applications they are stored in the /apps directory. If we wish to, we can explore the /apps directory and browse or run applications stored in this corner of the file system. It appears as though each program gets its own sub-directory, isolating it from other programs and other versions of itself. Most Linux package managers will complain if the user modifies or removes files directly. I experimented to see what would happen if I deleted the directories containing Snappy applications. I found Snappy correctly identified when a piece of software had been manually removed and Snappy considers the package deleted. Snappy does not seem to care how the package was removed, merely that it is no longer present.
At this point I feel it is safe to say Snappy is in its early stages. While the package manager works, it feels limited in some ways. We can install packages, remove them and hunt for new software, but I feel some functionality is missing. Specifically, I wanted more documentation and to be able update just one package while leaving other items at their original versions. Hopefully this feature (or documentation on how to perform the task) will appear later. Locking packages at a specific version would also be a nice feature to have. I was happy to note Snappy does not appear to have any bugs. While Snappy may still need to grow, everything it does do appears to be done correctly and I encountered no problems.
Finally, I like how easy it is to rollback (or roll ahead) packages. Switching between active versions of packages happens quickly and smoothly. I think this will be a very welcome feature on servers and desktops as well as embedded devices.