Search

Flatpaks, ram/disk usage and compression


I have 91 flatpaks, and it is my primary way of getting apps. But the (not very shared) dependencies have been bothering me lately.
I was primarily drawn in because Gnome Software has a cool UI and because I wanted the magic of one-click installs. I heard a lot of things about Flatpak and gave it a try.
I have a relatively small 72GB BTRFS root partition with zstd:1 (lowest) enabled. I think disk compression helps with the Flatpak dependency mess, as I only have 60% disk usage currently.
Idk how much extra RAM my flatpaks use, but I don't want 4 versions of the same dependency taking up space in my RAM. Thought about enabling zram to compensate for this. As different versions of the same library in RAM are easy to compress.
I don't think this compression mentality I instinctively adopted is healthy. Make stuff reliable in expense of storage/ram -> compress storage/ram in expense of proc. power
Another thing is slow Flatpak downloads. I have a gigabit connection, and Arch mirrors g

Git - How is it classified?
I could research this on my own, but was interested in hearing from the community.
Software tends to fall in categories based on who has control, how it is accessed, and who owns the data.
For instance, a FOSS project hosts encrypted user data for free, and the user easily controls who accesses it, but if the server/service goes down, users lose access to everything. Or, a user has their own offline files they control 100%, but sharing is more cumbersome.
Where does git fall in this spectrum? It seems that it's a mix, where authoritative copies may be offline at times before merging, when it returns to the hosted version. Its hosted, but can be self-hosted, and multiple copies of code canbee offline as well. Does it rely on a central source hosting, and a company willing to support the software?
I've never contributed to a project with version control before, though I've worked in a few places that used JIRA or git. It interests me how it works, and I'm just curious to read a Lem