Warning: the audio is bad and will occasionally get very loud
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.
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
pre installing flatpaks
Did the room just get a bit colder or is it just me
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.
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!
