Flatpak Is Not the Future
ludocode.com
Flatpak Is Not the Future
1–10 of 410 posts
Re: Flatpak Is Not the Future
#2Flaptak? I'm going to call flatpak from that now.
OP might want to edit this.
Re: Flatpak Is Not the Future
#3Flaptak? I'm going to call flatpak from that now. OP might want to edit this.
Thank you for the heads up!
Re: Flatpak Is Not the Future
#4Right! Time to pushback against these developers who uses Flatpaks, Appimages, Snaps, Electron, etc. We are no longer in the world of doubling performance and memory size. Even more, nowadays people are conscious of the power usage. Time to fight the bloat!
Re: Flatpak Is Not the Future
#5> Flatpak and Snap apologists claim that some security is better than nothing. This is not true.
Oh no we're all doomed.
Re: Flatpak Is Not the Future
#6Right! Time to pushback against these developers who uses Flatpaks, Appimages, Snaps, Electron, etc. We are no longer in the world of doubling performance and memory size. Even more, nowadays people are conscious of the power usage. Time to fight the bloat!
[deleted]
Re: Flatpak Is Not the Future
#7To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux.
While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro.
For example, the Elementary OS "AppCenter" apps are now available in any other distribution, thanks to the Flatpak remote. Testing daily GNOME apps has become as easy as installing their Flatpak reference, and letting them update automatically.
Regarding memory, storage and power consumption:
- The base runtimes (which are the heaviest bit) are downloaded only once per system, e.g., one for the KDE Plasma ecosystem, one for Elementary, and so on. The first app you install will pull them, so I do not see it as much more bloaty than having an enormous bundle of system-wide dependencies (e.g. if you install a KDE app in a primarily GNOME environment) as would happen otherwise.
- Memory and CPU-wise, Flatpaks are very light containers (which do not require loop disks, or anything else) which should have almost no overhead. I never witnessed any loss of performance, at least.
- Bug and crash-wise, I experienced a tremendously stable and "flat" experience on Flatpaks. That is, if there is a bug in one app on one distribution, the bug will exist on all, or vice versa. This is not as common as it should be in containerized app install tools, and makes debugging overall much easier.
The only drawback are updates taking longer than on other platforms, probably because compressed deltas are not yet available unlike in other major package managers.
With this, I don't want to describe Flatpak as a panacea in everything, but at least for GUI apps, it solved a lot of distribution fragmentation issues in my case.
Re: Flatpak Is Not the Future
#8The article bashes Flatpak portals as complex but otherwise doesn't make any solid arguments against them. That's important because it's easily the most important remaining problem to solve to get an effective sandbox.
I actually like that for apps that have no business reading any files on my system they simply cannot do so. Sure, you can point to apps like GIMP and such that have chosen to give access to the file system by default to make it easier for users while portals get polished. If that bothers you then simply use Flatseal to change those permissions. Meanwhile apps like Spotify are entirely restricted from accessing any of my filesystem. Likewise Discord can only access files from a specific directory or a youtube-dl style tool like VideoDownloader also cannot access any of my files and always includes the latest version of ffmpeg and youtube-dl regardless of distro politics.
Re: Flatpak Is Not the Future
#9To be fair most of that is a result of an ecosystem of idiots and not of the fundamental design itself.
It has a namespacing feature, so f-ck'n use it. Instead, they intentionally produce collisions.
Providing and sharing common runtimes could have worked pretty well if developers actually used a small set of common runtimes instead of picking from one of a gazillion slightly different rebuilds.
As a replacement for "native" package management? No. Flatpak makes sense if you have a small number (Unfortunately (and ironically) it's ill-suited for games, which need to have the latest GPU drivers available, which is antithetical to the whole idea of a stable, universal base system.
Re: Flatpak Is Not the Future
#10To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS…
Nah they take up too much disk space. Rather use Gentoo