Feeling snappy? Self-contained apps won’t replace distro packages

Keeping on this week’s theme of Linux software repositories, an announcement from Canonical last week caused quite a commotion in various Linux communities. As Ars Technica reported, Canonical is touting “snap packages” as the next big thing in software distribution. The client software has been ported to platforms other than Ubuntu, which has been misrepresented as other distros actively supporting it.

The idea behind snaps (and Flatpak, which is under development in Fedora) is that software projects can build a single, self-contained package that runs on any version of Linux. It’s certainly an appealing prospect for some use cases. Not every open source project wants to rely on community packagers or spend their own effort being the maintainer in a dozen different distros. Some applications, particularly large web apps, could definitely benefit from an easier install process. I’ve found several open source project management tools I wanted to try out, but wasn’t interested enough to go through all of the setup.

Increased security is also being touted as a benefit, but I’m less inclined to buy into that. I count 63 packages on my Fedora machine that depend on the openssl-libs package. That means the next Heartbleed would require 63 updates instead of one. If some of the upstreams are slow to release updated snaps, sorry about your luck. I did see some discussion that snaps can depend on each other, but that sort of kills the “self-contained” aspect. Containerizing the applications does offer some improvements, but in most implementations, the containerization is disabled.

I think snapd (and Flatpak) are going to be useful tools, but they’re not there yet. And they certainly won’t solve all of the problems that the tech press seems to think they will. For the foreseeable future, maintainers will matter.

Are Linux repos like proprietary app stores?

Bryan Lunduke had a column in Network World last week comparing Linux software repositories to proprietary app stores. His point is a valid one: just because software was once available, that doesn’t mean it will be in perpetuity.

It’s tempting to argue that his example isn’t a fair comparison because the repos in question were hosted by Nokia, who was making money off device sales, instead of being a community project. That’s a weak argument, though, because community is no guarantee of longevity. Community provides some extra momentum, but if Red Hat decided it was going to pull its support for Fedora tomorrow, would the community be able to keep the infrastructure running? Would Ubuntu continue without Canonical? Perhaps, at least in the short term. At least in those cases, community mirrors would allow the current state to be maintained for a while.

This isn’t really a problem with repositories, though. If you had to go to the project’s website to get the code, you’re still in the same boat. Or in many small boats that are the same. At any rate, software you get from the Internet is always going to be at risk of going poof. This is true for both commercial and open source software.

Somewhere in my parents’ house, there are still probably 3.5″ floppies of DOS games I bought at Target for $5. If I had a 3.5″ drive, I’d see if the disks are still readable. But the software I actually use? It all comes from Internet distribution. I guess good backup hygiene includes keeping the appropriate install media stashed away somewhere.