One of the great disadvantages of the Linux desktop is its software distribution mechanism. While the overall concept of central software repos works great and has been adapted into powerful Stores in commercial products, deploying and using programs, delivered as packages, is a tricky business. It stems from the wider fragmentation of the distro ecospace, and it essence, it means that if you want to release your product, you must compile it 150 odd ways, not just for different distributions but also for different versions of the same distribution. Naturally, this model scares away the big game.

Recently though, there have been several attempts to make Linux packages more cross-distro and minimize the gap between distributions. The name of the game: Snap, and we’ve tasted this app-container framework before. It is unto Linux what, well, Windows stuff is unto Windows, in a way. Not quite statically compiled stuff, but definitely independent. I had it tested again in Ubuntu 17.04, and it would appear that Snap is getting more and more traction. Let’s have another look.

Background

For those of you still wondering, contemplating and getting confused, think applications that do not need a million permutations of compilation. They can be easily deployed on any which Linux that supports Snap without additional modifications, and they run in their self-contained isolation. Of course, they also bring a heavier data footprint, but that’s a small penalty to pay. The typical package dependency mechanism makes for smaller, lighter systems, but brings in weaknesses and cracks in the foundation of the package pyramid, which threatens to collapse the entire structure.

If you’re not into development – only usage, then you need not concern yourself with the internals of the mechanism. What you require is the snapd service installed and running, and it will do all the necessary translations to make applications behave in a distro-agnostic manner. This is the core idea behind the project, and it allows for a wider adoption of Linux (finally!) across multiple devices. Think mobile, think Internet of Things. And again, we have Canonical to thank for leading the way.

Experiment underway

I resumed my testing from last year on Ubuntu 17.04 Zesty Zapus. Like before, Snap still remains a nerdy tool, because you’re supposed to utilize its power from the command line using its somewhat vague interface. You can search for packages using the find command, but therein also lies the problem. Normal people may not be enthused running CLI, especially not one that is so very developer oriented. Indeed, I did struggle finding all the stuff I wanted this way. A global search functionality is still missing, and it is a blocker in making Snap more visible and appealing to ordinary users, which could actually be a deliberate choice.

To GUI or not to GUI

With my curiosity piqued to a new level, I searched for complementary tools that could help me utilize Snap in a more humane way. In other words, I wanted a frontend, a store if you will, similar to what all distros use, and what you get on any Internet-heavy platform. As it turns out, there isn’t any such framework yet, probably because it requires a lot of server/backend work. But going forward, this will be absolutely essential, otherwise no one will really use Snap except people who like to have multiple PC monitors.

However, not all is lost. There are several utilities at the moment, which you get through Snap – inception! – allowing you to browse, search and install packages in a more visual, more enticing manner. One such tool is uappexplorer-cli, but while it has a superior search functionality, it’s still a nerdy app. If you’re interested:

snap install uappexplorer-cli

Then, once it is installed, you run:

uappexplorer-cli --type snap

Snapweb

The closest to having a real store is the Snapweb package. What this does is run a small web server on your client (locally), allowing you to interact through it using any which browser interface on port 4200 (4201). Still nerdy, but once configured, it’s lightyears ahead of the rest of the stuff.

The installation is simple (snap install snapweb). Then, open a browser and go to localhost:4200. This will launch the GUI, and ask you to provide an access token, which you can only generate with sudo rights. The idea is that if you have root, you can do pretty much anything. In other words, this is the modern-day equivalent of .htaccess username+password authentication. It is designed to prevent accidental or malicious access to the snap interface. After all, it’s a package manager, so it can deliver and remove stuff from your system. Therefore, the first step is to create a token and verify:

sudo snapweb.generate-token Snapweb Access Token: I7MVWtl4UgwmCG6ggR0vib5RjlK2zvl8Xir2i3I0rwclVO3R2YRkNgnsAvfBePJa Use the above token in the Snapweb interface to be granted access.

Once this is done, you can begin browsing the Store.

Snapweb store

At this point, the Store is very rudimentary. The UI has a feel quite similar to Unity8, as well as what we’ve seen on both the Ubuntu Phone and the M10 tablet. Moving forward, I do not know if this will be retained or how it will change. Regardless, the store comes with a short list of categories, a small bunch of available programs, and you can install or remove them from within the browser.

I decided to install VLC and Krita. Both programs were configured just fine, and you can have both the Snap version and the standard version of the same application, and in fact, why would you not. With Krita, the interesting thing was that it did not respect the global menu functionality, so I guess more work is needed in making sure it’s all peachy. This will probably be a challenge, given how different desktop respect application designed in non-native frameworks (Qt, Gtk, whatever), resolution, DPI, etc.

Another problem was, neither of these two showed in Dash. Ubuntu had not cataloged them, probably because the Snap does not expose its database to the system yet. Again, this must be resolved, and the system should be able to manipulate snaps natively, even though things go through the Snapd service, and the translation layer occurs there.

Other observations

There are fewer errors on the command line, so the whole experience was less verbose. The application find/search is still tricky. You need to know what to look for to find it, which is difficult. There’s no distinction between stable and beta releases. There’s a separate way to browse private snaps, and it requires that you login, on the command line, into the snap server. Maybe the Ubuntu SSO will finally come in handy.

Overall, snap is not as powerful as apt, yum, dnf, or others in terms of raw capabilities, and this should not be the case, as it needs to handle a much simpler subset of programs and dependencies. This is all done behind the scenes. I would like to be able to search the entire snap world, and then slowly filter down the stuff I do not like. Both CLI and GUI.

Conclusion

I am optimistic. Snap is evolving slowly but surely, it’s becoming more serious, more mature, and there’s a growing acceptance that the old 1,000 package managers and a manager saga cannot continue anymore. Using snap is relatively easy for advanced users, still widely inaccessible to everyone else. The CLI is reasonable, but it needs a lot more work, especially the search piece. The GUI is simple, very early, and there aren’t that many amazing packages just yet. But it’s a good beginning.

I would like to see Snap become a serious thing, with commercial integration, powerful options and menus, and lots of great programs. And of course, some ability to save the user’s app catalog/manifest so that when you reinstall on a different box, you get everything, and maybe even user settings. All this without having to have the entire system hooked into the cloud, or use a global online account. Definitely interesting. Well, let’s see what gives in a few months. Take care.

Cover Photo: Drone Delivery by DodgertonSkillhause for the Morguefile.com.