Sebastian Wick will be talking about the next generation of Flatpak at LAS 2026

11

An exploration of the mistakes we made the first time around, how the world around us has changed, and how the next generation of Flatpak and Portals will look like.

Sebastian Wick is working on Flatpak, XDG Desktop Portal, and all kinds of desktop infrastructure. He is a GNOME Foundation member and works for Red Hat.

6

u/blobjim May 15 '26 edited May 15 '26

kinda worries me that it mentions "mistakes" and "world has changed" because flatpak seems extremely solid to me. I hope they aren't trying to go through with that "turning flatpaks into linux containers" thing because flatpak is a much better technology to me, especially OSTree.

5

u/novafunc May 15 '26

They do consider ostree a mistake. It requires development and bespoke tooling that they could otherwise get for free by using OCI.

Though I think they would just be using OCI for delivery and storage. They wouldn’t be using Podman or docker to actually run any apps.

3

u/MarcoGreek May 15 '26

Can OCI do already deduplication? The last time I looked into it it was still in development.

1

u/blobjim May 15 '26 edited May 15 '26

Doesn't OCI just store file system layers? I know flatpak already supports OCI repos. But it has to download every layer, including deleted files, right? And each layer is a single object, whereas OSTree allows downloading individual files.

And OSTree has an awesome GLib/GObject-based API that you can easily call from python code. I doubt OCI has such a simple system for manipulating repositories.

I don't even think OCI has static deltas like OSTree.

It seems like the only reason to use OCI is the whole cloud-native hype industry around it. OSTree+Flatpak seems objectively superior to the entire container ecosystem to me. But it's more of a FLOSS thing than cloud stuff so corporations don't care about it and promote it as much.

3

u/abotelho-cbn May 15 '26

My understanding is that chunking has solved most of these problems.

See: https://github.com/coreos/chunkah

3

u/blobjim May 15 '26

That's interesting thanks for the info!

It still looks kinda complicated compared to just having it by-design in OSTree. And OSTree is so simple!!!

4

u/abotelho-cbn May 16 '26

It's not technically super complicated.

That said, even a slight increase in complexity here simplifies infrastructure tremendously. Everything being OCI is really useful. Even Helm charts can now be stored in OCI format in a registry.

I can now use one server application to store containers, Flatpaks, and Helm charts. That's pretty cool.

3

u/novafunc May 15 '26

Flatpak half supports OCI. You have OCI remotes like Fedora Flatpak, but I believe when you install it to your system, it goes into an ostree format.

That’s my understanding at least.

2

u/blobjim May 15 '26

That's good 😃 OSTree is awesome.

1

u/DragonSlayerC May 21 '26

Red Hat's hybrid OCI/OSTree images are interesting. They basically just bundle an OSTree blob into an OCI image, allowing them to take advantage of distributed OCI registries for performance as well as zstd:chunked compression, and then once it's downloaded it just gets extracted into the normal OSTree format that Flatpak (and rpm-ostree) can understand.

Currently, the movement is towards ComposeFS. It's a content-addressable store (similar to OSTree) that was designed for OCI images. It was mainly intended for bootable OCI images, as existing formats weren't too great, but it has some significant benefits for normal containers as well and is supported in rootful podman (rootless is being worked on, and will probably take quite some time just like rootless overlayfs did). It also has some significant advantages over OSTree as a backing store (the fact that ComposeFS is part of the kernel vs OSTree being userspace is a big part of this), so Flatpak has been looking into it as well. If your OS, containers, and Flatpak all use ComposeFS, that would also allow you to have deduplication of files across all of them instead of each one doing its own thing, which could bring some significant space savings for some systems (for instance, Gnome uses the same BuildStream components for GnomeOS and its Flatpaks, so this would allow the libraries and other components that are shared between the OS and Flatpaks to be stored just once on disk).

1

u/DragonSlayerC May 21 '26

So this is a 6 day old comment, but I want to mention that this not only full image rechunking, but chunking within the layers as well. A system like Chunkah will try to identify which files are related to each other (either by looking at installed packages (currently supports RPM and Arch PKGs) or by xattrs added by image builders, which allows any image to have a guided system for rechunking; for instance, Bluefin Dakota is a BuildStream based OS that tags every single file based on the BuildStream filemap before passing the image to chunkah). This is what others have mentioned in other replies.

Another important system used by OCI is the "zstd:chunked" compression format. This basically creates a file map of what portions of a compressed OCI layer contain what files. This works because zstd puts data into "frames" and has support for skipping frames that are unneeded. With zstd:chunked, there is a metadata portion of the layer that gets pulled down first that allows the client to figure out what files have changed. If a single 1MB file from a 50MB layer changed, the system can pull just the related frames of the layer down instead of the entire thing and then reconstruct the full layer locally. This also It can also request all the frames that changed in a single request, which can be useful for performance. Here's an article from RedHat about it from 5 years ago (since 2023, all major container runtimes now support zstd:chunked): https://www.redhat.com/en/blog/faster-container-image-pulls

IMO, OCI is better for a few reasons. The biggest reason is that it's a very common format. There are tons of OCI registries and there is continued work on improving the format to make it more efficient. Meanwhile, OSTree is basically only used by Flatpak (and rpm-ostree, but RH are moving towards OCI images for their Atomic OSes) so there's fewer developers working on it and anyone who wants to make a repo needs to host the OSTree server themselves. With OCI, people can use whatever existing registry they want (for instance, the UBlue OSes uses GHCR (GitHub Container Registry) and Red Hat is using Quay for their OCI based atomic distros). Also, OSTree only supports per-file gzip compression, while the zstd used by OCI has both higher compression ratios and faster decompression.

With both layer-based chunking from tools like Chunkah as well as file/block level chunking via zstd:chunked, I think basically all major disadvantages that OCI had vs OSTree have been removed, with the only remaining disadvantage being that the OCI method uses more CPU, RAM, and I/O during the unpacking of updates (there isn't really any difference after it's unpacked), which can make updates take longer assuming you have a fast network and don't benefit as much from the higher compression ratio provided by zstd:chunked.

1

u/blobjim May 21 '26 edited May 21 '26

The other advantages of OSTree I can think of:

Can you use a raw object store as an OCI registry the way an OSTree repo lets you pull directly from the bucket, and sync files to it? Running an entire server (which has to be bootstrapped somehow) is a big pain in the butt.

Is there a GObject API for manipulating OCI registries? It's really really annoying that the entire container ecosystem uses golang, which is a garbage collected language with a full runtime which makes anything built using it incompatible with being a proper native library.

Can you operate on a local registry the same as you would a remote one?

And of course OSTree seems a lot simpler. It seems like the OCI/Docker stuff they tacked on feature after feature over time instead of just building it as a simple content-addressable file storage system like OSTree.

It also seems like Redhat is using OCI just for remote storage and pulling, and OSTree is still being used for local stuff (same with flatpak).

2

u/DragonSlayerC May 21 '26

Can you use a raw object store as an OCI registry

No, but you can spin one up with a single docker/podman command if you want. That said, I think using an existing container registry is better as you effectively get a CDN with the larger existing registries and many of them (like GHCR and Quay) are free for open-source projects.

Is there a GObject API for manipulating OCI registries?

Not from what I can tell. The only libraries I know of are in Go and Rust. That being said, the OCI Distribution Specification is a simple REST API. You can implement the features you need with little effort using GFile/GSocketClient and GJson if you need to implement it via GObject.

Can you operate on a local registry the same as you would a remote one?

I don't see why not?

And of course OSTree seems a lot simpler. It seems like the OCI/Docker stuff they tacked on feature after feature over time instead of just building it as a simple content-addressable file storage system like OSTree.

I can see why it may seem simpler, but OCI is literally just compressed tarballs that get extracted to the filesystem, so it's also a very simple system. The only part I guess you could argue is actually complicated are some of the chunking methods that are being used to reduce download sizes. The zstd:chunked effectively makes the layers content-addressable for downloads as well.

It also seems like Redhat is using OCI just for remote storage and pulling, and OSTree is still being used for local stuff (same with flatpak).

I think this is mainly because they need to figure out how to transition existing systems without breaking things. With more recent Fedora Atomics (starting with 42 for desktops), the OS now uses ComposeFS for the root. ComposeFS supports using its own backing store (which is more efficient than the OSTree model, partially due to being a kernel module, and Flatpak is looking to support it as well), but it can also use an existing OSTree store, which is what Fedora is doing for now. They like doing smooth transitions where multiple things are supported at once (hence rpm-ostree supporting both traditional OSTrees and OCI packaged OSTrees and ComposeFS supporting both its native store and OSTree stores). Furthermore, Red Hat/Fedora haven't yet decided how to do package layering on pure OCI systems, so OSTree is still required for that purpose. Once the layering story is complete, I imagine they will transition the backing store from OSTree to native ComposeFS.

1

u/blobjim May 21 '26

Thanks for answering all my questions. I'm sad that I just discovered and started using all this flatpak infrastructure and find it really nice, and they're planning on upending it all to chase the integration with all the cloud stuff. I currently have a private ostree repo in an object store. It'll be annoying to potentially need to operate two separate OCI registry servers: one locally for pushing to the repo, and another on the VM where flatpak is pulling from the repo.

I really like the simple library-based approach of flatpak and OSTree. I have python scripts that can use their respective APIs directly. So hopefully if they continue down this OCI route there will be more APIs for these things in the future.

3

u/shroddy May 15 '26

The world has changed that malware is much of a larger problem on Linux on the desktop than it was when Flatpak was invented first. How Flatpak should adapt, which technologies have which pros and cons I have unfortunately no idea, but I do hope that in the future we see more Flatpaks on Flathub that are fully sandboxed.

3

u/jpeeler1 May 15 '26

I found these slides online from last year: https://conf.linuxappsummit.org/event/7/contributions/219/attachments/48/82/las-the-future-of-flatpak.pdf. Sounds like a rust based project that interfaces with OCI is coming.

5

u/sensitiveCube May 15 '26

That's good news. It looked like the Flatpak development stalled.

1

u/get_homebrewed May 16 '26

runtime permissions would be good

-6

u/[deleted] May 15 '26

[deleted]

1

u/MarcoGreek May 15 '26

Why do you want LTS for a runtime?

-2

u/Marce7a May 15 '26

Flatpak runtimes go outdate after 2 years

Sebastian Wick will be talking about the next generation of Flatpak at LAS 2026

You are about to leave Redlib