Back in the day, even package managers had their issues. Remember, Linux is not just the kernel and the applications—it’s also the in-between software that makes everything click together.
The early philosophy of Linux was straightforward: keep libraries in a single, central place so every piece of software could use them. On Windows, you had .dll files scattered all over the system: in the Windows directory, in the application’s directory, and in custom folders added later on. Chaos.
Linux wanted to unify this mess. Why not put the same library (.so files in Linux) in one generic location where any program could access it? A noble idea—but in practice, things got messy. Different applications often required different versions of the same library, creating a spider’s web of dependencies that sometimes broke more than they fixed.
Package managers like apt, dnf, or pacman tried to bring order to this chaos. They kept track of which software required which libraries, updated them when needed, and attempted to balance the needs of the operating system with user-installed software. But no system was perfect. Sometimes an application just wasn’t compatible with the rest of what was installed.
Enter Sandboxing
That’s where sandboxing comes in.
Beyond the traditional package manager model, Linux now offers a way to install applications in a more “self-contained” format—something closer to a generic package that runs on any distribution.
The idea is simple: instead of relying on your system’s libraries, sandboxed apps bring along their own. They live in their own little bubble (a “sandbox”) but still integrate with your computer’s hardware: video, sound, keyboard, mouse, microphone, and even your webcam work as if nothing is in between.
Flatpak
The most popular example today is Flatpak.
Flatpak bundles the application with everything it needs into a shell that connects back to your system only where necessary. It’s like a container, but lightweight.
This is incredibly useful when distributions don’t provide the newest versions of software. For instance, Debian is famous for its stability, but that also means older packages. Maybe your distro only has GIMP 2, but you want GIMP 3? With Flatpak, you can install the latest version instantly, no waiting around for your distribution’s repositories to catch up.
Snaps
Canonical (the company behind Ubuntu) created their own version called Snaps.
It works on the same principle as Flatpak—sandboxed, self-contained apps—but the implementation differs. Snaps are tightly integrated into Ubuntu and its derivatives, but outside that ecosystem, they’ve never really gained the same popularity.
AppImage
Then there’s AppImage, which is the most Windows-like approach.
Instead of installing, you just download a single .AppImage file, make it executable, double-click it, and it runs. That’s it. No package managers, no dependency issues. It’s essentially the Linux equivalent of a Windows .exe.
AppImages aren’t as widespread yet, but they’re lightweight, portable, and might catch on more in the future.
The Trade-Offs
Of course, there are trade-offs.
-
Package managers keep things tightly organized, with shared libraries saving disk space and memory. But dependency hell can still creep in.
-
Sandboxed apps (Flatpak, Snap, AppImage) give you freedom and compatibility across distributions but use more disk space since each app carries its own dependencies. Sometimes there’s even a tiny performance penalty.
Still, for most users, it’s hardly noticeable. I’ve been running the Flatpak version of Steam for years without issues.
Conclusion
Linux gives you options. You can stick with the traditional, tightly managed package manager route, or you can embrace sandboxing with Flatpak, Snap, or AppImage for more flexibility.
In other words: spreading software love on Linux comes with many Windows.