Skip Navigation

Will Flatpak and Snap replace desktop Linux native apps?

Actually, the better question is: When will they replace most desktop Linux programs?

32 comments
  • Probably unpopular opinion: I hope that happens sooner than later.

    I always saw packaging every piece of software for every distribution as a lot of duplicate work that could be better used somewhere else.

    As an example, Gentoo's default repository has 18k packages (not to mention the many other packages in additional repositories), each one of them with its own building script, maintainers and tests.
    Most of those packages are also present in other Linux distributions, again with their own maintainers, different building scripts and having passed their own tests.

    Doesn't that sound like a lot of duplicated work for each distribution that could be used instead on improving the core system and pushing the burden of packaging applications upstream as flatpaks?

    Also, since flatpak packages dependencies with the application, they could fix the dependency hell problem in a big part because the developer will determine what dependencies your package runs with, instead of relying on whatever version of the dependencies may be installed in your system.

    And it could also solve the quick death of Linux applications. I'm sure most of you saw how quickly applications get unusable in Linux. You find an application you like, but because it was developed for an older version of some library (like OpenAL or GTK+2) you cannot use it anymore.
    Have you seen that in Windows? You can still use most of the applications developed for Windows XP in Windows 10.

    That of course has its drawbacks. Because you are packaging dependencies with the application, you will have duplicates of the same library for each application, but I think that's a fair price to pay for more stable and durable applications. That's very similar to what Windows applications do.

    I'm talking about flatpak. Like most of the people here, my experiences with snap were bad, I am not interested in it and I think it's Cannonical going their own way.

  • Snap? It is fundamentally broken and Canonical shows zero interest in fixing that. Instead they try to patch applications to not be as awful when running via Snap.
    Firefox is the best example, its a big application and suffers greatly from taking forever to start on Snap because of course the filesystem image is compressed, so it needs to be uncompressed, mounted and then firefox can start which is still slowed greatly due to snaps poor I/O performance.

    A unpatched firefox took 30 seconds to start on Snap, they patched it to load only one language pack and some other small things, and now it starts in incredible 15 seconds.

    Which is shit poor compared to the native firefox starting in one second and the flatpak starting in also one second. All on the same machine.

    Snap is by far the most cruel joke out of canonical.

    Flatpak has no such problems.

  • I'm in the camp of thinking Flatpaks are definitely the future for GUI applications. While there are definitely cons...

    1. CLI applications are not feasible as Flatpaks. This isn't what Flatpak is designed for, standard package management will still be needed here.
    2. Dependency duplication wastes storage space, but I'm personally willing to give up a couple GBs for the benefits I get.
    3. Developers might package their application incorrectly. This is possible, but it hasn't caused any notable issues for me in the 2 years that I've been primarily using Flatpaks.
    4. As far as I'm aware, Flatpak doesn't have a way to allow applications to set udev rules. This generally doesn't matter, but for something like Steam Input, you will need to install the steam-devices package or setup udev rules manually so it can manage your controllers. Google's Android Flash Tool also doesn't work out of the box in the Chrome Flatpak last I checked.

    ...The pros more than outweigh these (in my opinion at least).

    1. Non-distro-specific packaging means you can use Flatpaks on whatever distro you want. You can have more up-to-date applications on stable distros like Debian, or on smaller distros that don't have the resources to package every application possible. Rather than Red Hat spending a significant amount of time packaging LibreOffice for RHEL/Fedora, they can just rely on the Flatpak and spend time on more important elements of the distro itself. There's also Bottles, which enters dependency hell if packaged incorrectly, they had a blog post about this a while ago.
    2. Application files are stored in one place in /.var/app. For some apps this doesn't matter, but it keeps applications like Steam from cluttering up your home directory with random game saves and other garbage. This also makes backups easier since you already know where all applications keep their files.
    3. It makes immutable distros actually usable, which I believe will be the future for some use cases.
    4. Permissions management. Even if no one is setting privileges for their applications correctly right now, having the groundwork for this in place will be important if more proprietary applications are going to be ported to Linux in the future.
  • There is no need for. Flatpak as an additional format is nice to have, but I don't want to trust 200 independent sources. I want to trust my distribution who test and bring those stuff together into a native packaging format, specialized for the distribution. I don't want to fiddle with every Flatpak application until it gets the correct rights for my setup or try to make it look like any other native package. Flatpak does not even work with CLI programs (but could be extended to in the future).

    Flatpak is great for big and complicated programs, such as Firefox and LibreOffice. Especially if they get a lot of updates and need to be as fast as possible distributed, such as any web browser.

32 comments