Can your distro handle my package?
Here’s something to get angry about: Linux distros are just glorified package managers with some exclusive content. With enough effort, you can compile just about any open source library, tool, or app for whichever distro you want. Or, you can throw them together and call it a new distribution of Linux. As a bonus, make some proprietary SaaS to go with your distro and start selling commercial support.
Still not with me? Good, because oversimplifying things like that is wrong. There is, in fact, a plethora of low-level components which make an average Linux distro, from the boot loader, system daemons and libraries, display server, UI toolkit, and so on. Linux distros takes care of connecting and managing all these parts into a stable operating system for the end user. Most distributions also take special care to ensure packages in the official repository use compatible dependencies, which means you shouldn’t have to install multiple versions of a library for your software to work.
Life is never so simple
Let’s say you’re sifting through an archive of your digital photos from the 2000s, and you’d like to convert them from an obsolete raw format to something modern. The only problem is your format has been discontinued back in 2009, and the latest tool you could find for the job has a binary from 2010. Its dependencies have introduced several breaking changes in the meantime, so they no longer work.
Let’s take a break here to list the most common things Linux users say about such problem:
- “Just compile it yourself”
- “Run a live boot of an OS from that time, and try there”
- “That’s because you didn’t use a proper open standard for raw images”
Now for Windows users:
- “Try reinstalling that tool”
Enter snaps
The previous point makes Windows users sound like total idiots. However, consider their reasoning: when packages are expected to contain every dependency, a missing library probably means something just didn’t get copied properly. That’s how things have been done in Windows since the beginning, and to make sure dependencies from one program don’t mess with other programs, installers put each application in its own folder. For users to access the relevant application binaries, installers create shortcuts (aliases) for them on the desktop, in the start menu, or in another easily accessible location.
So, back in the early 2010s, clever guys behind some major Linux distros decided they could do the same. They created what they call snaps, packages containing an application along with its dependencies, and optionally a way to configure some things at install time. Unlike Windows installers, snaps still need their own package manager, but unlike the traditional Linux package managers, these can be installed on almost every Linux distro as long as it has a supported hardware architecture.
Fast forward to today
It’s been six years now, and snaps still aren’t very popular among Linux users. If you look online, the most common complaint is how they use a lot more space than traditional Linux packages, and how a lot of Linux users find them unnecessary. They’re not wrong; if you can install a program through the official package manager, snaps are just a pile of overhead. And if you’re trying to have a portable distribution for your software, you can always bundle those libraries as a part of your build process. Besides, packages built specifically for your distro will probably run faster.
Fair enough. Average users often find Linux unnecessarily complex, so let’s call it a draw. When an average user finds a tool which does what they need, they don’t want to compile it first; they just want to use it, even if it’s not as small and efficient as possible.
Which brings us back to the old debate: does it really matter how big your package is? Users who tried more than one generally agree that size matters, but only if you can use it. They also agree that being too fast is often a bad thing. Keep in mind that making Linux popular is all about satisfying other people as much as yourself.