I have had the least issues with AppImage. It does not fit every use case. It does not need to. If you can ship an AppImage, please consider doing so.
Flatpak Is Not the Future
141–150 of 410 posts
Re: Flatpak Is Not the Future
#142There is a deep trend happening in software development. As the number of dependencies for building an application grows, it becomes exponentially harder to shake the tree. This used to be the role of Linux distributions, they were acting as a push-back force, asking projects to support multiple versions of C libraries. This was acceptable because there is not C package manager. Now that each language has their own p…
> On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API. Now, with Flatpak, each runtime is an SDK on its own. However, unlike Windows and macOS, specific runtime is not being bound to a specific OS release, but to the app requirement.
That's right, it makes the problem worse.
The first time I noticed that trend was on macOS, where applications bundle most of their libraries, and binaries compiled for multiple architectures.
Then we had Electron apps that ship with their own full copy of a browser and dependent libraries.
When NPM was designed, they observed that resolving colliding versions of the same dependency was sometimes difficult. Their answer was to remove that restriction and allow multiple versions of the same library in a project. Nowadays, it's not uncommon to have 1000+ dependencies in a simple hello world npm project.
Our industry is moving away from that feedback force that was forcing developers to agree on interfaces and release stable APIs.
Re: Flatpak Is Not the Future
#143To 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…
> if developers actually used a small set of common runtimes instead of picking from one of a gazillion slightly different rebuilds
All the runtimes on Flathub are built on top of the standard fd.o runtime, so the OSTree-level dedup should generally work for them.
> 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.
I believe there's an extension available for the latest Mesa builds, so you can opt for the bleeding edge and then just remove the extension if things break.
Re: Flatpak Is Not the Future
#144Earlier quoted context omitted.
Maintainers are not developers, they are users, so the developer cannot push unwelcome changes, such as ads, trackers, trojans, backdoors, keyloggers, etc. directly to users because the maintainer will refuse to accept that.
On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained"), which reflects poorly on the developer in the mind of the user. I personally see no upside to shoving an unpaid third party between user and developer.
> I personally see no upside to shoving an unpaid third party between user and developer.
I think F-Droid is a good example of striking a balance between those two extreme models. Their existence enforces community vetting of apps as well as somewhat-reproducible thanks to their standardized build infra, which are two major wins.
I personally have much more trust in such schemes (such as guix/nix) because i don't necessarily trust all of the developers of apps i use not to get hacked, and i believe enabling one-click updates to every user of an app without review is a dangerous pattern for security.
Re: Flatpak Is Not the Future
#145> If you are a Linux distribution maintainer, please understand what all of these solutions are trying to accomplish. All your hard work in building your software repository, maintaining your libraries, testing countless system configurations, designing a consistent user experience… they are trying to throw all of that away. Every single one of these runtime packaging mechanisms is trying to subvert the operating sys…
The whole point is that this is technically worse and only being used to try to bootstrap a walled garden where they (RedHat, Canonical for flatpack or snap) get paid a fee due to a monopoly on app distribution to their users. This is not 'the revolution' we should support. I encourage you to study the technical arguments until you understand them well enough that they become convincing.
Re: Flatpak Is Not the Future
#146Earlier quoted context omitted.
> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it…
Flatseal gives users a GUI to manage the permissions of each app. Would that address your concern?
I think it's great, but we're still far off from an ideal solution because it's not exactly fine-grained. For example, flatpak portals enable me to grant/block access to my home folder, but don't enable me to allowlist a specific folder in my home. So i'm stuck with the possibility that a vulnerability in the app can take over my entire system (eg. by rewriting ~/.profile), or with my app not accessing my home folder at all.
As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.
Re: Flatpak Is Not the Future
#147Flatpak is the future of Linux desktop applications for so many reasons, but among them it allows users not to be caught up in the dependancy mess that plagues Linux distributions. Some of the criticism here does not belong to Flatpak. E.g Fedora's weird duplication of repositories is exclusively a Fedora problem. Has absolutely nothing to do with Flatpak.
Applications such as VLC and GIMP which 'ship' with access to whole filesystem permission is an eternal dilemma. Would you rather the authors ship without access to this permission and break app functionality ? Or let them ship with restrictive permission and allow users to manually enable respective permissions to regain function when the software breaks? It is easy to see the feasible decision here that works for all parties here. The permission on the different accessibility store however has confusing labels on sandboxing, I agree with the point that the store should make this as clear as possible.
I think the bigger point the article misses is the ability to control these permissions at this level. Even if the software author ships 'dangerous' default permissions, the user can always revert this decision and sandbox it effectively if they so wish.
Flatpak is a crucial needed fix for the Linux package distribution problems highlighted elaborately by this article but in my humble assessment, the benefits to this solution massively outweigh the nuances such as the one the author mentioned about package sizes.
Re: Flatpak Is Not the Future
#148Don't know what to think about this blog post; it's not a very coherent critique, since it throws together various issues of user-packaging-formats that mostly specific to only one of the formats. And these don't seem to be 'inherent' in their design. Well, one is. Let's go through some of the issues: > Size My /var/lib/flatpak is 13 GB in size. That's a lot of space. On the other hand; that's about one game with con…
> Neither Flatpak nor Snap have increased memory usage because of containerization. Yes it does, because you end up loading multiple versions of the shared libraries. There is also the memory used by the flatpack/snap daemons. Snapd is quite big since it is written in Go.
IME, all running portal services add up to around 30MB RAM usage, and the two processes that need to run with each Flatpak are around 1MB each. (XDG portals aren't Flatpak-specific and can be used by host applications for some cross-desktop APIs as well.)
Re: Flatpak Is Not the Future
#149And nobody talks about Slax modules. Too many years ago, they had some basic containerization (only at filesystem level). If it got some kind of dependency managment, it would be really great.
Re: Flatpak Is Not the Future
#150People have tried to provide a packaging format that would allow apps to declare their depencies in a distribution neutral manner[1]. It was, uh, not a huge success.
Let's take an extreme example. If I build an app on Ubuntu and then try to run it against the system libraries on Alpine, it'll fail, because Alpine is built against a different libc. We can simply declare Alpine out of scope and only support glibc based distributions, but if we want good cross-distribution support we're still going to be limited to what's shipping in the oldest supported version of RHEL. So let's skip that problem by declaring LTS distros out of scope and only target things shipped in the last 3 years - and now apps can't target any functionality newer than 3 years old, or alternatively have to declare a complicated support matrix of distributions that they'll work with, which kind of misses the point of portability.
In an ideal world distributions would provide a consistent runtime that had all the functionality apps needed, but we've spent the past 20 years failing to do that and there's no reason to believe we're suddenly going to get better at it now. The Flatpak approach of shipping runtimes isn't aesthetically pleasing, but it solves the problem in a way that's realistically achievable rather than one that's technically plausible but socially utterly impossible.
Flatpak is a pragmatic solution for an imperfect world - just like most good engineering is.
Edit to add: one of the other complexities is that dependencies aren't as easy to express as you'd like. You can't just declare a dependency on a library SONAME - the binary may rely on symbols that were introduced in later minor versions. But you then have to take into account that a distribution may have backported something that added that symbol to an older version, and the logical conclusion is that you have to expose every symbol you require in the dependencies and then have the distribution resolve those into appropriate binary package dependencies, and that metadata simply doesn't exist in every distribution.
[1] http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-gene...