yet another reason to back flatpaks and distro-agnostic software packaging. We cant afford to use dozens of build systems to maintain dozens of functionally-identical application repositories
I will back flatpaks when they stop feeling so sandboxed. I understand that is the point, but on Mint it don’t get any specific popuo requests and instead have to sit in flatseal and manually give access.
.deb 4 lyfe
the sandbox is the point! but yes there’s still shortcomings with the sandbox/portal implementation, but if snaps can find a way to improve the end user experience despite containerising (most) apps, then so can flatpak.
It’s similar to how we’re at that awkward cusp of Wayland being the one and only display protocol for Linux, but we’re still living with the awkward pitfalls and caveats that come with managing such a wide-ranging FOSS project.
I am definitely not against flatpaks, but I still use system packages when possible. I find too many weird issues with flatpaks when I need them to do more than be a standalone application (see Steam).
Flatpaks feel like a walled garden more than a sandbox. Just give me more UI prompts for what you want to access as opposed to needing an entirely separate program (Flatseal).
We have this guy saying we cannot build all the Alpine packages once to share with all Alpine users. Unsustainable!
On the other hand, we have the Gentoo crowd advocating for rebuilding everything from source for every single machine.
In the middle, we have CachyOS building the same x86-64 packages multiple times for machines with tiny differences in the CPU flags they support.
The problem is distribution more than building anyway I would think. You could probably create enough infrastructure to support building Alpine for everybody on the free tier of Oracle Cloud. But you are not going to have enough bandwidth for everybody to download it from there.
But Flatpak does not solve the bandwidth problem any better (it just moves the problem to somebody else).
Then again, there are probably more Apline bits being downloaded from Docker Hub than anywhere else.
Even though I was joking above, I kind of mean it. The article says they have two CI/CD “servers” and one dev box. This is 2025. Those can all be containers or virtual machines. I am not even joking that the free tier of Oracle Cloud ( or wherever ) would do it. To quote the web, “you can run a 4-core, 24GB machine with a 200GB disk 24/7 and it should not cost you anything. Or you can split those limits into 2 or 4 machines if you want.”
For distribution, why not Torrent? Look for somebody to provide “high-performance” servers for downloads I guess but, in the meantime, you really do not need any infrastructure these days just to distribute things like ISO images to people.
There are other costs, too. Someone has to spend a LOT of time maintaining their repos: testing and reviewing each package, responding to bugs caused by each packaging format’s choice of dependencies, and doing this for multiple branches of supported distro version! Thats a lot of man hours that could still be used for app distribution, but combined could help make even more robust and secure applications than before.
And, if we’re honest, except for a few outliers like Nix, Gentoo, and a few others, there’s little functional difference to each package format, which simply came to exist to fill the same need before Linux was big enough to establish a “standard”.
Aaaanyway
I do think we could have package formats leveraging torrenting more though. It could make updates a bit harder to distribute quickly in theory but nothing fundamentally out of the realm of possibilities. Many distros even use torrents as their primary form of ISO distribution.
Interlude: Equinix Metal née Packet has been sponsoring our heavy-lifting servers doing actual building for the past 5 years. Unfortunately, they are shutting down, meaning we need to move out by the end of April 2025.
I don’t think it’s a solution for this, it would just mean maintaining many distro-agnostic repos. Forks and alternatives always thrive in the FOSS world.
yet another reason to back flatpaks and distro-agnostic software packaging. We cant afford to use dozens of build systems to maintain dozens of functionally-identical application repositories
I will back flatpaks when they stop feeling so sandboxed. I understand that is the point, but on Mint it don’t get any specific popuo requests and instead have to sit in flatseal and manually give access. .deb 4 lyfe
the sandbox is the point! but yes there’s still shortcomings with the sandbox/portal implementation, but if snaps can find a way to improve the end user experience despite containerising (most) apps, then so can flatpak.
It’s similar to how we’re at that awkward cusp of Wayland being the one and only display protocol for Linux, but we’re still living with the awkward pitfalls and caveats that come with managing such a wide-ranging FOSS project.
I am definitely not against flatpaks, but I still use system packages when possible. I find too many weird issues with flatpaks when I need them to do more than be a standalone application (see Steam). Flatpaks feel like a walled garden more than a sandbox. Just give me more UI prompts for what you want to access as opposed to needing an entirely separate program (Flatseal).
We have this guy saying we cannot build all the Alpine packages once to share with all Alpine users. Unsustainable!
On the other hand, we have the Gentoo crowd advocating for rebuilding everything from source for every single machine.
In the middle, we have CachyOS building the same x86-64 packages multiple times for machines with tiny differences in the CPU flags they support.
The problem is distribution more than building anyway I would think. You could probably create enough infrastructure to support building Alpine for everybody on the free tier of Oracle Cloud. But you are not going to have enough bandwidth for everybody to download it from there.
But Flatpak does not solve the bandwidth problem any better (it just moves the problem to somebody else).
Then again, there are probably more Apline bits being downloaded from Docker Hub than anywhere else.
Even though I was joking above, I kind of mean it. The article says they have two CI/CD “servers” and one dev box. This is 2025. Those can all be containers or virtual machines. I am not even joking that the free tier of Oracle Cloud ( or wherever ) would do it. To quote the web, “you can run a 4-core, 24GB machine with a 200GB disk 24/7 and it should not cost you anything. Or you can split those limits into 2 or 4 machines if you want.”
For distribution, why not Torrent? Look for somebody to provide “high-performance” servers for downloads I guess but, in the meantime, you really do not need any infrastructure these days just to distribute things like ISO images to people.
There are other costs, too. Someone has to spend a LOT of time maintaining their repos: testing and reviewing each package, responding to bugs caused by each packaging format’s choice of dependencies, and doing this for multiple branches of supported distro version! Thats a lot of man hours that could still be used for app distribution, but combined could help make even more robust and secure applications than before.
And, if we’re honest, except for a few outliers like Nix, Gentoo, and a few others, there’s little functional difference to each package format, which simply came to exist to fill the same need before Linux was big enough to establish a “standard”.
Aaaanyway
I do think we could have package formats leveraging torrenting more though. It could make updates a bit harder to distribute quickly in theory but nothing fundamentally out of the realm of possibilities. Many distros even use torrents as their primary form of ISO distribution.
I’m a fan of flatpaks, so this isn’t to negate your argument. Just pointing out that Flathub is also using Equinix.
Source
I don’t think it’s a solution for this, it would just mean maintaining many distro-agnostic repos. Forks and alternatives always thrive in the FOSS world.
Let the community package it to deb,rpm etc while the devs focus on flatpak/appimage