My problem with Flatpak is how huge are the downloads, especially when on a metered connection.
Last month I installed Kdenlive, and the size of the downloaded files was around 3 gb, to which the app itself contributed around 40 mb. (I use Ubuntu.)
A week later, I wanted to install another app (I forgot which one), but again, it was 3 gb download for 30ish mb app.
And then this week I ran `Flatpak update`, and it needed yet another 3 gb to download just because there was a new Kdenlive version (again, around 40 mb)!
How on earth does it make sense to have to download 10 gb worth of data just for apps that only total 100 mb?
The goal of these things is not to write software that works but to write software that works4me. Flatpack, snap, docker they all exist to ship your computer to someone else.
I use Snap frequently, and yes, apps that would only take 10 mb as a .deb can balloon to 200 mb.
But I can live with that; it's a reasonable price to pay for separating apps update cycles from that of the OS.
I also use Docker. But even then, my Django app — complete with pytorch, numpy and several other "heavy" deps on top of python itself — is a little more than 400 mb.
Interesting bottleneck. Considering that flatpaks are basically small filesystems themselves, there's probably some redundancy to remove. I wonder if a simple de-duplication strategy at file level may be enough to fix that.
Easy: Like most other containers, it starts by bundling an entire general purpose distro. Though I grant it is surprising that the sizes are quite that bad; perhaps there were suboptimal choices made in an attempt to make the layers more reusable but it didn't work out?
In Flatpak you define the dependencies as runtimes, and they are shared between apps. So for example when you install Kdenlive it will download the entire kde framework that is huge but when you install the next kde app it won't download it again
Agree, I feel like there must be a better way to achieve what Flatpak does. I love it because it's the only major app platform on Linux that offers some form of sandboxing, but the download sizes get ridiculously large.
And then by default everything is downloaded to /root rather then into user space, clogging up the partition. Not ideal for a partition that you would not expect to hold 20+GB worth of programs.
It feels like the update at the top entirely invalidates the article. At least I don't see why pinning dependency versions at the source level would be necessary for reproducible builds.
21 comments
[ 1.6 ms ] story [ 77.8 ms ] threadThey are unfortunately a necessary evil for keeping LTS OS running.
My problem with Flatpak is how huge are the downloads, especially when on a metered connection.
Last month I installed Kdenlive, and the size of the downloaded files was around 3 gb, to which the app itself contributed around 40 mb. (I use Ubuntu.)
A week later, I wanted to install another app (I forgot which one), but again, it was 3 gb download for 30ish mb app.
And then this week I ran `Flatpak update`, and it needed yet another 3 gb to download just because there was a new Kdenlive version (again, around 40 mb)!
How on earth does it make sense to have to download 10 gb worth of data just for apps that only total 100 mb?
But I can live with that; it's a reasonable price to pay for separating apps update cycles from that of the OS.
I also use Docker. But even then, my Django app — complete with pytorch, numpy and several other "heavy" deps on top of python itself — is a little more than 400 mb.
Flatpak is on another level by itself!
What about Snap? I use it all the time on my Ubuntu machines and works perfectly fine. Even files sizes are waay more sane than Flatpack's.
https://github.com/feather-wallet/feather/issues/47