The Future of Flatpak | Sebastian Wick @ LAS 2025
The Future of Flatpak | Sebastian Wick @ LAS 2025
Warning: the audio is bad and will occasionally get very loud
18 comments
-
Haven't seen the video, I'm only commenting based on the summary in the comments.
It's good that flatpak is switching to OCI containers. Hopefully that will end the flatpak's dependency hell. This week I was looking at flatpak as a way to publish my app and found the user experience (user is the app publisher in this context) quite bad. Could be skill issue obviously.
I thought I could just look into a database of flatpak runtimes, pick the one with the software I need, add additional packages and be done with it. Unfortunately it is not that simple. First of all as far as I know, there is no "database" like archlinux.org/packages. You have to download the runtime and then search
/usr/include/or/usr/bin/to check if particular piece of software exists in it. Adding additional packages is also quite difficult. There are these runtime extensions which are like "baby runtimes" for special software like ffmpeg, java, etc. They kinda suffer from issues similar to the issues of the runtimes. And unlike in regular distros where you can get a package for almost anything, here you don't have the luxury and have to bundle that not so popular dependency.I hope that with OCI I will be able to just provide the binary, a link to the base image and a list of dependencies to install and be done with it.
-
Warning: the audio is bad and will occasionally get very loud
Interestingly, that's never a problem with text files.
-
** SOMETIMES IT IS **
(Sorry, couldn't resist)
-
-
is this available in text form?
-
Don't believe so, best that's currently available is skimming through the video to look at the slides.
Here's my short summary of the presentation, I tried to denote what's being worked on (open PR), what's kinda being done (WIP), and things stuff they'd like to be done in the future (wishlist). May be somewhat wrong.
- Flatpak is stagnant
- Red Hat is working on a better way to preinstall flatpak apps (open PR)
- Flatpak should is slowly moving towards OCI and away from ostree (more tooling available, don't need to maintain their own tools)
- Better permission handling that is more backwards compatible (open PR)
- Should directly use Pipewire instead of Pulseaudio (WIP)
- Allow user namespaces in flatpak sandbox (WIP)
- Move dbus proxying into dbus brokers (wishlist)
- Improve network sandboxing (wishlist)
- Improve drivers handling, currently drivers need to be built for each runtime, could cause issues if using EOL app on new hardware (wishlist)
- Work on portals directly improves flatpak
-
-
Unfortunately, it's not in a great situation. Flatpak is stagnant. There's a lot of cool things in the works, like a stronger sandbox, preinstalling flatpaks more effectively, etc, but merging things is hard.
-
About a year ago I started experimenting with the whole container-based workflow thing. I don't know how much time I've spent on setting up various programming environments, and there's always hurdles like getting a flatpak editor have access to java and actually be able to run javafx programs. And with distroboxes, what if my code needs access to a database that is started in a docker container on the host system, do I install docker inside the distrobox? I've had so many configuration issues. Every time I try I come back to debian stable and it feels like home.
-
Flatpak's usefulness for programming depends on the IDE and language. IDEs like VSCode largely suck because they are not designed to work in flatpak. But some languages still do work well in them, such as Rust, since Flathub provides the Rust SDK and dependency management is done with cargo. But it sucks for C++, where you typically install dependencies using your system package manager.
IDEs like Gnome Builder are pretty good. It's designed to work within the flatpak sandbox. Even when running as a flatpak, you can choose to build things using containers or your host system. And of course also build using the Freedesktop runtimes.
I recently setup JavaFX with the flatpak version of VSCodium and have it working pretty well. You first need to install the Java SDK from Flathub, set an env variable to tell VSCode to load the SDK. The more annoying part was JavaFX since it's not part of the JDK anymore. I just downloaded the JavaFX tar, extracted to a directory called JavaFX, and set $JAVAFX_HOME to point to it. Since VSCode has host filesystem access, it can access it. Few more steps than traditional Linux, sure, but still easier than MacOS and Windows.
Not sure about your database situation though.
-
For JavaFX I ended up putting both JDK and JavaFX in my home dir and pointed vscodium to the right paths, I could get programs to compile but for some reason it would not let me open windows from inside, complaining that DISPLAY was not set or available iirc, even though I did set the env variable inside. Either way, I'm not ready for this container work-flow. Though I suspect that I could get used to better practices. Do you install git and your editor of choice separately in all dev containers? Like, how much of the tooling should be inside or on host?
-
-
Containers are over hyped. They are so stupid for home use. People put init systems in containers, then run the entire pile of shit in Docker as root, and talk to me about security and resource isolation. And then all these shit Alpine containers with that MUSL joke. You really can't take any of it seriously anymore. These people want Windows or a mobile phone.
Flatpack is using OCI so they can publish their shit on any registry. Just another way to pollute an existing ecosystem with garbage nobody really needs. Easing the installation of crap onto your system is not a goal worth pursuing
-
-
until they give us android like permissions handling and always off by default with a proper request when needed, meh.
-
pre installing flatpaks
Did the room just get a bit colder or is it just me
-
My crazy idea is: write software so that Flatpaks can run on Windows and macOS. Plus, make high-quality Flatpak-building templates available for as many programming languages, UI toolkits, etc. as possible.
Because everything that Flatpaks provide is OSS, making shims for Windows and macOS compatibility would be tedious, but doable.
Same with crosscompiling Flatpaks, compared to the difficulties of crosscompiling for Windows or macOS from any other OS, multiplatform Flatpaks should be doable to crosscompile.
So this would lead to a world where a very convenient way to package for Windows and macOS... is creating a Flatpak that works on Linux!
18 comments