The real question is why do flatpaks exist at all if you can just run programs in containers
flatpaks and containers use the same kernel tech underneath, cgroups and namespaces, it’s just a specific implementation designed for desktop apps, and it has things like portals and stuff that’s specific for gui apps. So for example, if you use silverblue, you use htop, but it wouldn’t make sense as a flatpak when there’s a full fedora installation delivered via a container already on your desktop, you’d just dnf install htop and move on.
But not if it takes away my ability to make my system fit my needs.
This is the problem with the term “immutable”. For some reason people seem to think that these systems take away configurability and freedom to tinker, which is wrong because the entire point of cloud native is composability. You declare what your system is supposed to look like, and then a deployable artifact comes out the other end, that’s pretty much it. Hope this helps!
I think flatpak could perfectly fine for installing cli applications even though it is designed for desktop applications.
Shoving CLIs into flatpaks could be a thing but that wouldn’t really solve a problem, it would just mean adding one more ocean to boil and someone would have to volunteer to package htop for the 30th time.
Flatpak is distribution independent, which means, it could be actually reduce repackaging.
flatpaks and containers use the same kernel tech underneath, cgroups and namespaces, it’s just a specific implementation designed for desktop apps, and it has things like portals and stuff that’s specific for gui apps.
While that is true, I don’t see, why this is a problem for CLI applications to be installed and run via flatpaks.
Direct package management in your home dir - also an option, you can just install homebrew, nix, or tea or whatever install packages in your home directory and then it’s totally decoupled from the system.
Can you explain, why this works better, than flatpaks? I mean it does not matter what flatpaks were intended for originally, if they do the job just fine.
So for example, if you use silverblue, you use htop, but it wouldn’t make sense as a flatpak when there’s a full fedora installation delivered via a container already on your desktop, you’d just dnf install htop and move on.
I found this approach lacking, because:
I always have to remember what is the right container for the right tool.
Installing software can be quite annoying. I can’t simply add some dnf install foo in a bashscript. Controlling a container via bash is not that easy (or, I don’t know how it works)
Tracking installed software is painful. Now I have to check every container, if and where something is installed.
flatpaks and containers use the same kernel tech underneath, cgroups and namespaces, it’s just a specific implementation designed for desktop apps, and it has things like portals and stuff that’s specific for gui apps. So for example, if you use silverblue, you use htop, but it wouldn’t make sense as a flatpak when there’s a full fedora installation delivered via a container already on your desktop, you’d just dnf install htop and move on.
This is the problem with the term “immutable”. For some reason people seem to think that these systems take away configurability and freedom to tinker, which is wrong because the entire point of cloud native is composability. You declare what your system is supposed to look like, and then a deployable artifact comes out the other end, that’s pretty much it. Hope this helps!
I think flatpak could perfectly fine for installing cli applications even though it is designed for desktop applications.
Flatpak is distribution independent, which means, it could be actually reduce repackaging.
While that is true, I don’t see, why this is a problem for CLI applications to be installed and run via flatpaks.
Can you explain, why this works better, than flatpaks? I mean it does not matter what flatpaks were intended for originally, if they do the job just fine.
I found this approach lacking, because:
dnf install fooin a bashscript. Controlling a container via bash is not that easy (or, I don’t know how it works)