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).
Flatpaks have their use-case. Alpine has its use-case as a small footprint distro, focused on security. Using flatpaks would nuke that ethos.
Furthermore, they need those servers to build their core and base system packages. There is no distro out there that uses flatpaks or appimages for their CORE.
Any distro needs to build their toolchain, libs and core. Flatpaks are irrelevant to this discussion.
At the risk of repteating myself, flatpaks are irrelevant to Alpine because its a small footprint distro, used alot in container base images, containers use their own packaging!
Furthermore, flatpaks are literal bloat, compared to alpines’ apk packages which focus on security and minimalism.
Edit: Flatpak literally uses alpine to build its packages. No alpine, no flatpaks. Period
Flatpaks have their use. This is not that. Check your ignorance.
I know there’s limitations to flatpak and other agnostic app bundling systems but there’s simply far too many resources invested into repacking the same applications across each distro. These costs wouldnt be so bad if more resources were pooled behind a single repository and build system.
As for using flatpaks at the core of a distro, we know from snaps that it is possible to distribute core OS components/updates via a containerised package format. As far as I know there is no fundamental design flaw that makes flatpak incapable of doing so, rather than the fact it lacks the will of distro maintainers to develop the features in flatpak necessary to support it.
That being said, it’s far from my point. Even if Alpine, Fedora, Ubuntu, SUSE etc. all used their native package formats for core OS features and utilities, they could all stand to save a LOT in the costs of maintaining superfluous (and often buggy and outdated) software by deferring to flatpak where possible.
There needs to be a final push to flatpak adoption the same way we hovered between wayland and xorg for years until we decided that Wayland was most beneficial to the future of Linux. Of course, this meant addressing the flaws of the project, and fixing a LOT of broken functionality, but we’re not closer than ever to dropping xorg.
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).
This is such a superficial take.
Flatpaks have their use-case. Alpine has its use-case as a small footprint distro, focused on security. Using flatpaks would nuke that ethos.
Furthermore, they need those servers to build their core and base system packages. There is no distro out there that uses flatpaks or appimages for their CORE.
Any distro needs to build their toolchain, libs and core. Flatpaks are irrelevant to this discussion.
At the risk of repteating myself, flatpaks are irrelevant to Alpine because its a small footprint distro, used alot in container base images, containers use their own packaging!
Furthermore, flatpaks are literal bloat, compared to alpines’ apk packages which focus on security and minimalism.
Edit: Flatpak literally uses alpine to build its packages. No alpine, no flatpaks. Period
Flatpaks have their use. This is not that. Check your ignorance.
I know there’s limitations to flatpak and other agnostic app bundling systems but there’s simply far too many resources invested into repacking the same applications across each distro. These costs wouldnt be so bad if more resources were pooled behind a single repository and build system.
As for using flatpaks at the core of a distro, we know from snaps that it is possible to distribute core OS components/updates via a containerised package format. As far as I know there is no fundamental design flaw that makes flatpak incapable of doing so, rather than the fact it lacks the will of distro maintainers to develop the features in flatpak necessary to support it.
That being said, it’s far from my point. Even if Alpine, Fedora, Ubuntu, SUSE etc. all used their native package formats for core OS features and utilities, they could all stand to save a LOT in the costs of maintaining superfluous (and often buggy and outdated) software by deferring to flatpak where possible.
There needs to be a final push to flatpak adoption the same way we hovered between wayland and xorg for years until we decided that Wayland was most beneficial to the future of Linux. Of course, this meant addressing the flaws of the project, and fixing a LOT of broken functionality, but we’re not closer than ever to dropping xorg.
I’m a fan of flatpaks, so this isn’t to negate your argument. Just pointing out that Flathub is also using Equinix.
Source
Pretty sure flatpak uses alpine as a bootstrap… Flatpak, after all, brings along an entire distro to run an app.
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.