The default is completely sandboxed. Developers need to allowlist exactly what they want. So it is transparent.

The default before the developer touches it doesn’t matter; compare this to Android, iOS, or macOS’s permission system. An app needs to ask for permission to use the microphone or access your files. With Flatpak, all a developer needs to do is specify --filesystem=home or --socket=pulseaudio and if the user hasn’t specified global options like --nofilesystem=home, then the developer gets access to it. Having a sandbox that is optional for the developer rather goes against the point of a sandbox, don’t you think?

I’m not unsympathetic to Flatpak developers, though. The status quo on Linux for decades has been, “you get access to everything.” If Flatpak enforced that sandbox, more than half of the apps on Flathub right now just wouldn’t work because they don’t support the filesystem portal.

I think GNOME and KDE need to do the work of manually restricting Flatpak apps’ access to sensitive permissions like home by default, maybe in a few years when the idea of the filesystem portal has had time to gestate among developers. Kind of like how Firefox’s HTTPS-only mode (which I think should be the default) prevents you from accessing the website unless you give permission.

That’s something we can work on, I think. At least we have a way to get there.

KDE Plasma now includes a GUI settings page that allows to change these.

I think GNOME needs to integrate that into their settings, I mean just include damn Flatseal as a settings page…

I recall saying the exact same thing. They have a built-in area for it in the Apps section. They’ll probably get around to it eventually…

There are packagers maintaining a shitload of apps at once.

It’s pretty crazy. I think this is probably the craziest example: https://old.reddit.com/r/archlinux/comments/f3wrez/much_love_to_felix_yan_an_arch_maintainer_from/

Felix Yan is awesome to be maintaining thousands of packages for Arch. But man, that’s a lot of work. If we could reduce the workload of our package maintainers who rarely receive any gratitude (usually only demands) and let them focus on the really important packages, I think that would also be awesome.

What storage expense? appimage are actually the smallest thanks to their compression.

I’m saying that Flatpaks use more storage for reliability, and that AppImages are less reliable because they rely on system dependencies in some circumstances.

but usually the issue is that you are missing a lib and not that the app itself is less reliable

This is why AppImages are less reliable. Flatpaks either work for everybody, or they don’t work at all. AppImages might not work if you’re on a “weird distro” or forgot to install something on your system.

And the support channel of yuzu in their discord was full of people having issues with the flatpak that were magically fixed the moment they tried the appimage, due to that issue with mesa being outdated in the flatpak.

Packaging your software with Flatpak does not mean you won’t have issues. But when you do have issues, you know they’ll be an issue for everybody. So when you fix it, you also fix it for everybody.

For example, the RetroArch package was using an old version of the Freedesktop Platform, which comes with an old version of Mesa. When they bumped the version (just changing it from 22.08 to 23.08), the problem was fixed: https://discourse.flathub.org/t/problems-with-mesa-drivers/5574/3

Tech Enthusiasts: Everything in my house is wired to the Internet of Things! I control it all from my smartphone! My smart-house is bluetooth enabled and I can give it voice commands via alexa! I love the future!

Programmers / Engineers: The most recent piece of technology I own is a printer from 2004 and I keep a loaded gun ready to shoot it if it ever makes an unexpected noise.

This is kind of a bad comparison. Theoretically, malicious authors could sign their Flatpak packages and Flatpak could verify it with cryptography. It doesn’t matter if you’re downloading a “crypto-wallet” that’s really just a phishing exercise.

Will still be using 4.79 GiB?

It will use more, but not exponentially more if de-duplication works as well as is claimed. The problem with AppImages is that they don’t include all of the dependencies, making them less reliable. At the expense of storage space, Flatpak bundles everything for reliability.

De-duplication works better the more Flatpak applications you have installed. e.g. de-duplication saves TheEvilSkeleton over 50GB of storage space here: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users

You don’t have many Flatpaks installed, but you happened to install applications that depend on three different runtimes (Freedesktop, GNOME, KDE), which is where a lot of the weight is coming from. Install 20 more Flatpaks and see what happens.

Well, if you think about it, the Freedesktop Platform is essentially a distribution. And Flatpak used to be called “xdg-app”. If you’ve got all your graphical applications installed via Flatpak, with GNOME, Systemd, glibc, GRUB and all the core dependencies only packaged for the base system (essentially Arch’s core repository), that’s pretty much a Freedesktop OS.

Hey, maybe we could use Snaps for the base system and Flatpaks for the userland? Or are these the kinds of ideas that get people stoned?

if you have a flatpak with an uncommon library

In this case, you’re responsible for packaging it yourself. This usually means specifying the git URL and build options in the manifest. You can see Krita doing this in their manifest because they don’t depend on the KDE Platform, as they need much older dependencies. So they’re responsible for over 1000 lines worth of dependencies.

The Freedesktop Platform is essentially a distribution unto itself, and I don’t think there’s ever been a case of dependencies in that distribution not being kept up-to-date.

Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there’s usually someone who can take over.

Well…debatable. There were over 1200 orphaned packages in Debian last year, many of which had not been maintained in over 3 years.

In general I agree, though had something to add regarding these points:

by defaults the sandbox is pretty good

This is a rather major problem with Flatpak; the maintainer decides what permissions they need by default, not the user. The user needs to retroactively roll them back or specify global options and manually override them per-app, but that’s not user-friendly at all. Though many Flatpaks do have good permissions because Flathub maintainers step in and offer suggestions before approving the Flatpak for publication, there are a number of Flatpaks that punch big holes in the sandbox; so much so that they might as well be unsandboxed.

But Bottles has a great sandbox, for instance, which is just what you’d want when running lots of proprietary Windows applications you maybe don’t trust as much as your Linux-y software.

It’s better than what we have with traditional packages but it can sometimes get in the way and not all beginners can easily figure out how to fix permissions issues with Flatseal. This will probably improve as we get more portals built.

some apps are less maintained and use EOL runtimes etc

Not much is different for distribution-maintained packages, either. See TheEvilSkeleton’s post about how there are over 1200 unmaintained packages in the Debian repositories, and even over 400 in Arch’s much smaller repositories that are outdated (!). At least Flathub applications are usually maintained by upstream, and so are usually as up to date as they can be.

not suited for some apps like terminal apps or system stuff

This isn’t really true. It’s only true when terminal applications need privileged access to something. Flathub ships Mesa userpace drivers and NVIDIA’s proprietary userspace drivers just fine. You can package something like yt-dlp in Flatpak just fine with --filesystem=host. Hell, they’ve even got Neovim on Flathub. Sure, it’s a little more cumbersome to type, but you can always create an alias.

Flatpak is not suitable for all graphical applications, either. Wireshark’s full feature-set cannot be supported, for example.

I would add that:

• You can easily rollback Flatpaks to a previous version (even from a long time ago) with flatpak update --commit. Much harder with traditional package systems, and you’ll probably need to downgrade shared libraries too.
• You get a consistent build environment with Flatpak manifests. If you want to build a newer version of a stable package you’re using straight from master or with a few patches, all you really need to do is clone it from flathub/whatever, change a few lines, and it has a very high chance of building properly. No need to figure out dependencies, toolchains, or sane build options. And it’s all controlled from an easy-to-read and modify file.

Most Flatpaks depend on the Freedesktop Platform runtime, or GNOME/KDE runtimes, which are derived from it. This contains several hundred common dependencies and librarires programs need, like gcc and python. When you update the runtime (change it from 22.08 to 23.08 in the manifest), all the dependencies are updated too. Many simple applications don’t depend on many more dependencies than are available in the runtime. Some…have more complicated dependency trees.

But counterpoint: the developer will update the dependencies when they are known to work properly with the application. Upgrading GTK3 to GTK4 in the GIMP flatpak will just break the application. Same thing with Krita and the dozens of patches to libraries it depends on. If you upgrade the application in the name of security before it’s compatible, all you end up with is a broken application. Which I guess is more secure, but that’s not helpful to anyone.

When my KDE screenlocker crashes on Wayland, all my monitors tell me to switch to a TTY and run a manual unlock. Which is reassuring!

If it doesn’t work in Wine (the only reason I’ve encountered so far is DRM), I just run it in a Windows VM. I play mostly visual novels, so it’s not that much slower. For Anti-Cheat games, I boot into my Windows 10 installation. I still haven’t quite figured out what I’m going to do with that installation come October 2025.

Eminently logical.

I believe all Flatpaks incorporate the codecs already.

Flathub even has hardware decoding with the drivers they distribute. However, Flatpak applications need to specifically opt in to ffmpeg-full rather than the normal ffmpeg package, which has support for patent-encumbered codecs.

Fedora Flatpaks, on the other hand, have no such codec support.

Fedora is a top-tier project and I completely understand why they weren’t comfortable risking patent law unnecessarily.

💯

If I cared one wit about either of them, I’d put money on VLC. If only because Star Citizen won’t make it before the heat death of the universe.

VLC 4.0 will be released with a massive change in the interface…eventually.

Yes.

MakeMKV. It’s better than anything else.

Just disable Javascript; it will load fine.

It’s been 5 years. I don’t think they’re going to change the license to allow distributions to distribute MongoDB more easily.

We should actively be against corporate leeching.

In a world without free software, Amazon will build their own proprietary software for servers that is better than everyone else’s, and will be in the same position. At least with Redis, multiple employees of AWS were core maintainers for Redis. It isn’t like Amazon didn’t contribute anything back. Now that it’s non-free, they’ll just fork it. Again.

All this really accomplishes is making licensing a headache for everybody, which is the main reason people and organizations use free software.

I think free software developers should be able to make money from their software, and money from working on their software. I also think everyone else should be able to, too.

To put it another way, open source means surrendering your monopoly over commercial exploitation.

Additionally, Elasticsearch does not belong to Elastic. Redis doesn’t belong to Redis, either.