antimba

Podman winning is good. Red Hat consistently does things right, for example their quay.io is open source, unlike Docker Hub and GitHub Container Registry. The risks of not using rootless containers weren’t blown way out of proportion, because rootless containers really are much more secure. Not requiring a daemon, supporting cgroup v2 early, supporting rootless containers well and having them as the default, these are all good engineering decisions with big benefits for the users. In this and many other things, Red Hat eventually wins because they are more open-source friendly and because they hire better developers who make better engineering decisions.

In the end, it seems what happened is that christel sparked a huge misunderstanding between freenode staff and Andrew Lee by making misleading statements to both parties and lying to hide the fact that she had sold freenode to get herself out of financial troubles.

Nix doesn’t guarantee binary reproducibility. It does help with reproducing build inputs and the build process, as do the tools used to create Flatpak applications and runtimes—flatpak-builder and BuildStream. Nix can build packages in a sandbox, but the same is true of flatpak-builder and BuildStream.

The Freedesktop SDK has a CI pipeline (run on schedule, not on every change, because it is expensive) that tests reproducibility, similar to r13y.com. Currently everything is reproducible except a few components.

There are also many respects in which Flatpak is objectively better than Nix (other than sandboxing, which is an important one). For example, Flatpak guarantees atomic updates with restarting merely the updated application. NixOS only guarantees atomic updates with a reboot (`nixos-rebuild boot`); `nixos-rebuild switch` can still break your running system, though the Nix store is safe and problems will not persist after a reboot, which is still a huge improvement over traditional package management. Still, using containers allows giving stronger guarantees.

Another example is that flatpak-builder and BuildStream are substantially faster than Nix. Evaluating Nix expressions is quite inefficient, even if they are convenient to write. Worse is the cascading rebuilds that come with the Nix approach when dependencies like compilers and glibc are patched or updated. Rebuilding after significant updates to gcc and glibc has advantages, such as benefitting from newer compiler features, but it is very desirable to have the option not to do that.

Also, Nix’s languages lacks domain abstractions for building packages, which makes tools to generate and update derivations have to rely on assumptions about their format or be unnecessarily complex. In comparison, flatpak-builder and BuildStream use JSON and YAML. The result is less expressive but more convenient, consistent, efficient, and simple to manipulate.

Similar to nixpkgs-update, Freedesktop SDK uses a simple auto-updater[1] for BuildStream and Flathub apps can use the Flatpak External Data Checker[2] for a bot to open merge requests or pull requests to update dependencies in the runtime and in application manifests.

OSTree uses a content-addressable store for all files, giving Flatpak deduplication for free. Nix gets deduplication only with an expensive process (`nix store optimise`) that involves scanning the Nix store and replacing duplicated files by hard links.

Yet another advantage of Flatpak is that due to dependencies being “flat”—that is, apps can depend on runtimes and have extensions, but there are no complex dependency trees—there is no need for dependency resolution. This also reduces the amount of metadata that needs to be downloaded. This makes installing and updating software with Flatpak very fast, which is unfortunately not at all true with Nix.

So, there are tradeoffs, and overall Flatpak has the better of them. Employing Nix to manage dependencies or to build apps would cause Flatpak to lose many of its advantages.

[1] https://gitlab.com/BuildStream/infrastructure/gitlab-merge-r...

[2] https://github.com/flathub/flatpak-external-data-checker

The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing.

The current mockups[1] for a UI refresh of GNOME Software have the “Sandboxed” badge and the permission details replaced by a context tile giving an overall “Safe”, “Potentially Unsafe”, or “Unsafe” rating, with additional indications and a safety dialog giving the full information. The ratings are determined from the permissions as well as license, whether the runtime is no longer supported, and whether the source is known.

[1] https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw...

Have a small main drive? You can store maybe three or four Flatpak'd apps.

That’s not true. Even the smallest consumer hard drives are big enough to store as many apps as you will want to install.

Slow internet connection? Good luck, you'll be here a while.

Flatpak uses OSTree to install and update apps. It is very efficient and generally faster than traditional package managers.

Even official image on Docker Hub receive almost zero security updates

Are you talking about the Official Images program? Because if so, this is not true.

So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update.

That’s false. OpenSSL is part of the runtime[1] and only needs to be updated there.

[1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/ma...

There are several technical falsehoods on https://flatkill.org/2020/. For example, this one:

Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions

TheEvilSkeleton counts them and 23 out of 50 is not almost all, so that is a technical falsehood, albeit not one that invalidates the author’s point. There are other falsehoods that do invalidate the author’s points. This one, for example:

Two years is not enough to add a warning that an application is not sandboxed if it comes with dangerous permissions (like full access to your home directory)?

This is wrong because GNOME Software did, before the flatkill author’s 2020 update, add a warning (which is missing from the author’s screenshot) indicating that the app has high permissions and can access all files and folders (it’s still described as sandboxed, which technically it is, just with the ability to escape the sandbox; further changes to GNOME Software to make this clearer are already planned). The author’s screenshot was presumably taken using an outdated version of GNOME Software; they should have checked more recent versions before making claims about what features developers did or did not add.

And here’s another falsehood:

So I need to run multiple fcitx daemons on my desktop and switch between them as I switch flatpak apps depending on which fcitx libraries are bundled with that app

The flatkill author misunderstood the implications of the bug report (in addition to seemingly misunderstanding where fcitx comes from; it’s part of the runtimes, rather than being bundled with each app). The issue was caused by a change in Flatpak, fixed in fcitx, and there is no need for the fcitx versions to match going forward.

That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care.

For GTK apps, they don’t need to do anything different, as GtkFileChooserNative[1] is recommended for non-sandboxed apps as well. GtkFileChooserNative has glib call the D-Bus API (which is proxied inside the sandbox) for the FileChooser portal[2]. The backend running outside the sandbox (xdg-desktop-portal-gtk for GNOME/GTK; there are also backends maintained by KDE and wlroots developers) shows a file chooser and makes any file (since March 2020, there is also support for folders) selected by the user available inside the sandbox using the Documents portal.

Also the portal APIs are not specific to Flatpak. They can be used by any sandboxing framework that wants to benefit from the work already done to integrate them.

Some apps don’t use GTK or Qt, some apps (like GIMP) still use GTK 2, which doesn’t have GtkFileChooserNative, and some apps haven’t been ported from GtkFileChooserDialog to GtkFileChooserNative (or can’t be ported yet because of missing features in the latter). And the Documents portal doesn’t work perfectly for all use cases: There are issues with getting notified when a file is modified externally and with getting the path of the file outside the sandbox (to display it to the user, if that’s desired).

[1] https://docs.gtk.org/gtk4/class.FileChooserNative.html

[2] https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...

Major GUI frameworks agree with you and have already adopted this approach and it is already used by many applications, and this has already been the case for years.

This might be easier to understand with some context. This is the GTK maintainer, who is about to release GTK 4 in a few weeks, and GTK 4 needs some unreleased fixes in Cairo. He requested a release earlier this year.[1]

The last stable release of Cairo was in October 2018. A very simple merge request[2] submitted by Nikolaus Waxweiler two years ago has not been merged even though everyone agrees it is good because nobody has been willing to take the responsibility to approve it.

The test suite is broken and tests were failing CI for all commits for a year (until the tests were disabled) because there was nobody who knew how the test suite worked who had time to fix it. There has been a proposal by a Google intern to add fuzzers for OSS-Fuzz to find security issues—but no maintainer has the time to review it.

Yes, there are a few commits and merge requests getting merged here and there, thanks to Uli Schlachter who is still active, but this is a large graphics library with many, many features, used by thousands of applications. It is not finished and not in a good state. Web browsers and other applications that have resources to move to Skia have done so already; GTK probably will not have spare resources to do this.

[1] https://gitlab.freedesktop.org/cairo/cairo/-/issues/422

[2] https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/...