1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
The world of Linux has long been divided into tribes, or distros as we called them. But what actually makes a distro? The packages it uses? The people who put those packages together? The philosophy behind the choices the people who put the packages together make? The question of what makes a distro is actually very difficult on to answer and it's about to get even more difficult.
There's a change coming to the world of Linux that's potentially big enough to make us rethink what a distro is and how it works. That change is Ubuntu's Snap packages and the parallel effort dubbed Flatpaks. While these two projects differ in the details, for the purposes of this overview I'll be considering them the same thing and using the terms interchangeably.
If you're familiar at all with the trends in Linux-based servers you'll likely be familiar with containers. Snaps and Flatpaks are more or less the desktop version of containers.
Whether a package is a Snap or Flatpak, there are few common things that make it significantly different than the packages your distro provides. For one thing your distro doesn't provide it. A Snap package comes straight from the developer of the application itself. Your distro may go ahead and put some Snap packages in its repositories so the installation experience may be the same, but behind the scenes the way Snaps are packaged, installed and run is very different.
While there's still some polishing needed in most distro's current implementations of Snap packages that I've used, for the most part the experience from the user point of view is pretty much the same as any other software. However, installing Snaps by searching your distro's repositories is probably the least interesting way to install them.
Where Snaps and Flatpak's excel is application outside your distributions repos. Consider Firefox Developer Edition. Very few, if any, distros have it available in their repos, which means if you want to run it you'll have to install and manage it separately. There are a variety of ways to do this, Ubuntu has .deb files, Arch has the AUR, and you could always compile it yourself. The problem is that Firefox Developer Edition updates daily, or close to daily. Package maintainers -- the people creating those deb files or packaging them up for the AUR -- have to update their packages.
Install Firefox Developer Edition as a <a href="https://firefox-flatpak.mojefedora.cz/">Flatpak package</a> (currently that's unofficial, maintained by Fedora and Red Hat developers) and all the sudden you're directly tied to Mozilla's updates. So far Mozilla hasn't produced an official Developer Edition Flatpak or Snap, but the company does <a href="https://blog.mozilla.org/futurereleases/2016/04/21/firefox-default-browser-for-linux-users-ubuntu-new-snap-format-coming-soon/">plan to do it for Firefox itself</a> and Snaps provide a means to switch to beta/dev "channels" of a packaged app.
A Snap/Flatpak version of Firefox has two huge advantages over the distro-based version of Firefox. First, updates come faster from a single source, which makes for better security and eases distro package maintainers' workload. Second, Mozilla can continue to provide updates well past the point that Ubuntu or Fedora might want to.
Faster updates and eliminating the distro middleman are just two advantages of Flatpaks though. Perhaps the even bigger advantage -- especially with software like web browsers -- is the security sandboxing. Flatpaks/Snaps have much more limited access to your operating system than traditional apps. Sometimes this means not all features of an app are currently available in the Flatpak/Snap version, as is currently the case with the Snap version of LibreOffice, but as the platform matures expect those issues to be ironed out.
So what's the current experience of using Flatpaks/Snaps like? I've been using the unofficial version of Firefox Developer Edition for quite some time now and am happy to report that it's much easier to update than even the AUR-based version I used previously. A single command that I put in a cron task updates my browser every night without me needing to every think about it. I always have the latest release and I don't have to do anything to get it. My only gripe is that the unofficial version requires installing a bunch of GNOME dependencies I don't otherwise need.
I also run the Flatpak versions of LibreOffice, Inkscape and Blender. All three are indistinguishable from the distro versions I used previously. I don't need the features in LibreOffice that currently aren't supported in the Flatpak version so I don't have any issues there, but be sure to double check the known issues before you try it out.
If they're indistinguishable from the distro versions why bother? Well since a lot of what I do with LibreOffice is open other people's documents I like the sandboxing -- which admittedly has some bugs, but is probably, at least under Wayland, more secure than a packaged version.
The other reason I've embraced Flatpaks is that I believe they're the future of Linux software distribution. While it's true that the history of computing is littered with examples of failed write-once, run-anywhere software, Flatpak and Snaps really aren't that. They do simplify developers' lives by making it easier to package apps independently of distros, but that's as far into the dangerous run-anywhere territory as they get. I don't think that distros will disappear as a result of Flatpaks/Snaps, but I do think that the division between rolling release distros like Arch and conservative distros like Debian will be less important. The kernel itself isn't going to be a Flatpak any time soon, but if you're using Arch for the reasons I am -- to get the latest versions of Userland software in a sane way -- then Flatpaks accomplish the same thing without the need to run bleeding edge kernels.
|
