Pros and Cons of Snap Packages: Page 2

How a simple announcement was overhyped.
(Page 2 of 2)

Con Rumors

1. Snap packages are insecure on the X11 Window System.

True. Mathew Garrett pointed out this fact, but it has been mostly ignored because Ubuntu is poised to use Mir for graphical interfaces instead, while other distributions will be using Wayland shortly. However, X Window is likely to remain standard for most distributions for at least a year, and maybe two or three, so the concern is real enough for now.

2. Snap packages are much larger than existing packages.

This claim has been greatly exaggerated. A sample package of LibreOffice included debugging tools, making it appear four times larger than a standard package. However, without the debugging tools, the snap package was only about 50 megabytes larger than the standard package — a real but trivial difference except for those using older or smaller hard drives.

The serious overhead would come when several versions of a library or runtime environment are installed on the same machine.

3. Snap packages consume more RAM.

True. Using containers inevitably increases the overhead. But the difference is unlikely to matter on modern computers although it might offend some users' sense of efficiency.

4. Software installed by Snappy is slow.

True in some circumstances. Snappy packages use SquashFS, the same filesystem used on Live CDs. To run, they must be loaded into RAM, and connect to UnionFS if an application writes to disk. In most other circumstances, applications installed by Snappy are likely to be faster.

5. Snap is poorly documented.

The documentation for the snap command mixes options for making Snappy packages with options for using them. Many of the concepts for making the packages — assertion, change, connect, plug, slot — are left undefined. Presumably, the quality of the online help will improve eventually, but meanwhile finding the omitted information can take a while.

6. Using snap requires learning two sets of commands.

True. Snappy is not meant as a complete replacement for other package formats. The basic command must be installed by other means and uses a set of options unlike those of other formats.

A Birth Much Exaggerated

This summary makes two clear that the stories about Snappy have been distorted beyond credibility.

It also makes clear that, Snappy is a technology that is at early beta stage at the very most. It attempts to solve problems that many do not see any pressing need to solve, and, like many new technologies, its advantages seem to depend tradeoffs. Its success will depend very much on how it develops, and on how its developers address some of its current limitations.

Much will depend, too, on how other distributions respond. Unless the technology to build Snappy packages is released as free code or an alternative is developed, distributions like Debian and Fedora cannot place Snappy in their core repositories without violating their policies on software freedom.

Snappy has grown from a specialized use into a candidate for a universal package system. Yet whether its developers have become too ambitious is uncertain. Earlier efforts like the Linux Standards Base have failed to encourage a universal package system, and Red Hat's Flatpak could mean that the only result is a repeat of the old division between .rpms and .debs. More than one observed has linked to an xkcd cartoon that suggests the result of making a universal standard is only one more competing standard, and, so far, that seems the likeliest outcome — something as far away from the reporting in the open source media as is possible to imagine.

Photo courtesy of Shutterstock.


Page 2 of 2

Previous Page
1 2
 





0 Comments (click to add your comment)
Comment and Contribute

 


(Maximum characters: 1200). You have characters left.