Flatpak Is Not the Future

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • Overte

    Overte is an open-source 3D client and server solution that allows for vast social & educational environments to be created and lived in while also being shared in real-time with others.

  • I think it's an unfortunate necessity for some kinds of applications.

    Eg, we make this: https://overte.org/

    We're currently using AppImage because that was the first thing that worked for us, but most of the reasons are the same either way: We want to spend time developing the software, and that means it's hard to justify packaging every release for a dozen distributions. And I'd say nobody particularly wants to do it.

    We also expect our users to keep reasonably up to date, not whenever it's convenient to the distribution. Code changes can change the networking protocol, and some of those can require everyone to upgrade.

    So at least to me it makes perfect sense to package some kinds of applications this way. Maybe not KDE's calculator, but definitely things like games and tools with specialized markets, where it may be difficult to find people wanting to do the work of packaging them for a distribution.

  • glibc_version_header

    Build portable Linux binaries without using an ancient distro

  • One major headache with trying to run precompiled binaries on Linux is that if they were compiled using a newer version of glibc than the target machine, they won't be able to run. Back while working on Factorio, I was trying to get around this problem with endless Docker containers, but coworker Wheybags came up with a much solution to this, which is simply to, at compile time, link to the oldest compatible version of glibc: https://github.com/wheybags/glibc_version_header

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • AppImageLauncher

    Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages

  • Sparkle

    A software update framework for macOS

  • * i use appimagelauncher[1] to integrate with my menus etc but sometimes it works and sometimes it doesn't? i haven't really figured out the rhyme or reason

    [0] https://sparkle-project.org/

  • AppImage is basically a runnable .zip file. It contains a loader and an application with all of its dependencies, packed into a single file. If the image was uncompressed, basic extent-based deduplication could save space, but as far as I know the compressed AppImages just don't match up the files like that.

    I don't believe Snap natively offers any deduplication. Snap also uses compression (squashfs as far as I can tell) so deduplicating filesystems are equally powerless.

    Flatpak has its own deduplication system (that will confuse df/du if you try to run it and often leads to confusion about download time). Through tools like https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker/ you can check how effective the dedup process on Flatpak is. On my machine, Flatpak is using 10.5GB of disk space, but reports 13.75GB of files. Running duperemove on /var/lib/flatpak found two identical extents (belonging to cached files) that didn't get deduplicated already.

    As for why they couldn't be unpacked: I don't know. They'd take up more disk space, I suppose. Many standard Linux file systems don't have any form of deduplication mechanism built in, so I'm not sure what the balance would be. I would appreciate the ability to decompress AppImages/snaps without writing custom wrappers for them, but if you're on ext4 like many (most?) Linux users, you'll only see the downsides.

  • go-appimage

    Go implementation of AppImage tools

  • Snap and flatpak run a daemon to integrate into your system. Appimage has an optional daemon to give you the same integration https://github.com/probonopd/go-appimage

    Handles making it executable, automatic upgrades, no need to move it to your $PATH, and adds the application to your app list.

    Only other thing you might want to do is symlink a friendly name for cli

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts