Lol @siosm we've got a PR in to fastfetch to fix the disk display thing for #composefs
#ComposeFS
@abbra Sorry for the late reply, missed your toot.
Is there really no way to create a directory at runtime anymore? Creating and maintaining a container image where the only difference is a symlink seems a little tedious.
I already tried tmpfiles.d, but either I did it wrong or it runs too late in the boot process and the root filesystem is already read-only...
WOW I didn't realize I am already using #Bootc and #ComposeFS on my system.
Thanks #uBlue #AuroraLinux
Now let's check the status of #Podman + ComposeFS...
Incredible how Alexander Larsson was ahead of times with that reply about sharing libraries, it's basically the approach by Docker images... but OSTree, used by Flatpak, predates Docker and it is even more efficient with its by-file deduplication. And the recent #ComposeFS by the same author will allow #Podman containers to have the same deduplication not only on disk but even on RAM (to my understanding)
@hopland this so much. 😅
It takes the whole layering approach to the next level with something like #composefs. Something that will be a real contender to #nix current design. All without necessarily require to reinvent the tool you use to packer either. Getting that repeatedly and reproducible struct from the normal built artifact. 🤯
If you are a maintainer of #nix, #nixpkgs or #nixos: listen up.
You've got about 2 years or so being a serious contender, until someone like #lix or even #ostree with #ComposeFS comes in and eats your lunch.
Part and parcel of that is the community, the language, the security of knowing that there is culpability and responsibility.
Linus Torvalds had to walk it off because an entire foundation told him to. If the nix "community" is beyond this, why give #DeterminateSystems contracts?
#OSTree people in the meanwhile introduced #ComposeFS that can also enable cryptographically sealed systems
I instead hope that in the future distros will have their own selection of Flatpak built from the same packages as the host system, so that if #Flatpak, #Podman and a #Bootc -powered host system all use the same #ComposeFS store then the deduplication will be maximized and seamlessly degraded when mixing stuff from different distros.
#Podman is already one step further with #Bootc and soon one more with #ComposeFS ;-)
1. #Flatpak uses #OSTree for storage and OSTree is used to deploy the host system in #FedoraAtomic.
2. OSTree and #Podman will be ported to use the new #ComposeFS
3. The host and containers will share the same storage, see Phase 4 here:
https://github.com/ostreedev/ostree/issues/2867
4. Flatpak may be the next one to get access to this shared storage since it already uses OSTree, check the comments here:
https://blogs.gnome.org/alexl/2023/07/11/composefs-state-of-the-union/
Finally, since OSTree and Podman will support #ComposeFS we will have deduplicated storage between different containers and the host OS. And maybe even Flatpak since it already uses OSTree.
If hypothetically a distro uses its packages to build images for OSTree, Flatpak and containers we would have the max deduplication, resulting in a reimplementation of a traditional distro.
[...]
Le #système de fichiers #ComposeFS est désormais stable
https://blog.desdelinux.net/fr/Le-syst%C3%A8me-de-fichiers-composefs-est-d%C3%A9sormais-stable/
@ramin_hal9001@emacs.ch
You may want to reconsider #Flatpak if in the future #ComposeFS will allow shared storage between the OS, Flatpak apps and #Podman containers:
https://mastodon.social/@alxlg/112000758150683850
Of course if you are happy with #Guix keep using it, but Flatpak is not stupid, there is nothing that offers the same functionalities.
Do you know that #Flatpak uses #OSTree to deduplicate files? Be sure to use a tool to check the used storage that doesn't count hardlinks multiple times.
BTW, OSTree will use the new #ComposeFS that will enable shared storage between the host OS and #Podman containers. If it will be shared with Flatpak too and a distro builds the host images, the container images and Flatpak runtimes and apps from the same packages we would have a "traditional" distro in terms of ...
Do you know #ComposeFS by Fedora #CoreOS though? It will provide shared storage between the host system (deployed with OSTree) and containers run with Podman (and hopefully Flatpak apps in the future). The cool thing is that file content is decoupled by metadata and folder structure and shared both in storage and in *RAM* across multiple containers:
In my opinion, #Guix is an overkill for anything except computer science research. I think an approach that has better chances to succeed is reusing the OCI ecosystem and in particular using #ComposeFS for a per-file deduplication, that is important for large datasets. The missing piece for me it's a package manager for knowledge i.e. that links papers, datasets, source code for both calculations and documents (LaTeX, #Typst etc) in a graph of dependencies, citations etc.
The same maybe true for Flatpak in the future too, since it uses #OSTree. Not to mention that #ComposeFS de-duplicates files not only in storage but in RAM too, so shorter startup time for Flatpak apps or in containers.
2/2
Let's say Flatpak uses a bit more storage and memory when apps are not perfectly aligned to each others, but at least run them with no need to integrate everything in a single graph of packages.
There is duplication between the OS and Flatpak and it may be solved in the future with #ComposeFS, but if you use distros like Fedora Atomic flavours or OpenSUSE MicroOS you can reduce that duplication a lot.
2/2
In those distros you may want to use #Distrobox to easily start containers with whatever distros you want, allowing you to choose a (stable) distro for the system and other (cutting-edge) distros for tools and development.
And soon OSTree and Podman will use the new #ComposeFS under the hood, so hopefully one day we will get deduplicated storage among the system, Flatpak apps and containers. We'll be free to use the best packages for each task without duplicated files.
2/2
@thelinuxEXP @jorge @frigidcode
Once this approach will be mature you won't be supposed to need to modify your system. Now we are already at a point you don't need it 99% of the time.
We will finally use Linux distros to build independently custom OSes, a platform of third-party applications (Flatpak) and dev environments (Podman).
Maybe those three will also share the storage with something like #ComposeFS and it would be the nirvana.
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst