The Future of Flatpak | Sebastian Wick @ LAS 2025
(www.youtube.com)
from that_leaflet@lemmy.world to linux@lemmy.ml on 01 May 20:46
https://lemmy.world/post/28974261
from that_leaflet@lemmy.world to linux@lemmy.ml on 01 May 20:46
https://lemmy.world/post/28974261
Warning: the audio is bad and will occasionally get very loud
threaded - newest
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.
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.
I hope they plan on keeping pulse for the foreseeable future. Pipewire is great and all but pulse is very entrenched, I still maintain quite a bit of systems that are pulse only.
That is planned. But pulse is not secure, so exposing it is not great.
Why is it stagnant?
Major people of the project had moved on. It’s being maintained, getting security fixes, but pull requests are slow to be merged.
until they give us android like permissions handling and always off by default with a proper request when needed, meh.
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!
Interestingly, that’s never a problem with text files.
** SOMETIMES IT IS **
(Sorry, couldn’t resist)
Did the room just get a bit colder or is it just me
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?
Ah I had the same issue. JavaFX still uses X11. By default VSCode only lets X11 be used if Wayland is not available (this is the X11 fallback permission). Disabling X11 fallback will let VSCode use Wayland and let JavaFX use X11. I might make an issue for this on the flatpak’s GitHub asking for this change.
Honestly, the truth is that setting up containers for development will always be a hassle. My low tech way is just to make a distrobox container with its own home folder, install an IDE in it, and install packages. The more proper way to do it would create your own containerfile to build your container for developing.
VSCode also has its DevContainers extension but that doesn’t work in VSCodium and does some weird things.
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
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.