So i have allocated about 50GB for Zorin, now only about 15GB is available mind you all i do was only customize(install themes and icons shell themes) and play very light games (which i have moved in my external hard drive, So that means i have no games installed).
I have tried emptying the Trash, Clear file history, Delete Temporary Files. which did free about 1GB.
Do you use flatpaks and snaps when installing from the software center?
As a first step, I would use the Disk Usage Analyzer app to see what is using your disk space.
Yes, mainly flatpaks
As you have only a 120 GiB drive with dualboot win and Zorin (I have the same) I would recommend you not to use flatpaks (if possible and there is an alternative .deb package) and snaps because they need more storage space than .deb packages.
You might want to consider using .deb pakages instead to free up space. flatpaks is nice and all that, BUT they take a lot of space.
Try install flatsweep and see if you can free up some space of flatpaks.
since i should be avoiding flatpaks where can i install flatsweep other than the one on the software?
There's no around it, it's only flatpak availble if you don't want to compile from source. Just uninstall it afterwards.
You can run
sudo apt clean && sudo apt autoremove
but take a look at the packages that will be removed, that there are no important ones as e.g. gnome-desktop
sudo journalctl --vacuum-size=1M
This command limits the size of log files.
As a side note: Flatpaks will not show up in Disk Usage Analyzer since they are isolated from the system.
IF only 50Gigs is available to Zorin OS, then Flatpaks and Snaps will both be a constant thorn in your side - and since it will be tricky to know how much space they are taking up - you run high risks of losing your ability to boot if the space is filled during a write cycle.
How does that part of the isolation work? I'm not saying you're wrong (I'm saying I don't understand), but even if flatpak installs applications in a container, that container needs to exist as a file on disk somewhere, and should be visible to an analyzer, even if it's just showing up as one big, homogenous blob.
On Flatpaks, dependencies (like old runtimes) that are no longer needed by any of your Flatpak apps can be removed.
flatpak uninstall --unused
Flatpak and Snap are both a bit more complex. They do not point to standing files like your familiar file tree. In fact, if you ever installed something that also installed Snap as a carry-along, then tried to remove that snap package, you might have experienced the weirdness.
They mount decompressed and deduplicated copies of themselves at runtime.
You must unmount these if uninstalling them. With Flatpak, it is easier since running a Flatpak Uninstall command automatically unmounts the OST object. Snap, it is like pulling teeth...
Disk Usage Analyzer can only see the file sorting at the top. The compression and deduplication creates storage that is 'hidden' from Disk Usage analyzer (or other apps).
Because that is the nature of how they operate, it is not easy to solve to make that space visible.
And I suspect that Gnome and Canonical are not in hurry to - since it has a benefit for them making it appear as though Snaps and Flatpaks are much less spacehogging than they really are.
But some users on the forum have had a lot of trouble due to running out of space and file corruption due to being misled into thinking that they had more free space than they did.
My experience, admittedly with other container files is that the analyzer should still see that deduplicated container, no? It may not be able to recognize individual flatpaks and tell you how much application A is taking up, but it should be able to tell that flatpak's OST is 140 GB (or whatever). That size may change dynamically (one of the things I've sometimes had to do is resize a qcow2 file and then access the android system that runs it and use resize2fs to sync the container and file system), but a disk analyzer should still see the container at whatever size it is when the analyzer is run, should it not? The contents of that mounted container are absolutely a mystery to the disk analyzer, but the file on drive ought to have a set size at any given point in time.
And this is what makes me second guess the logic I've presented above. >_<
This is an example of a monolithic container. Monolithic containers operate as one base size, which is the container, within which your files will go.
Snap and Flatpak are not monolithic, they are runtimes that are fragmented across many different applications and storage pools.
They are called containerized, but they do not occupy one big container. So there is no 'container' for the disk usage analyzer to see.
What Disk Usage can see is the hardlinks, which it will count only once. This does not account for the heavy data pools.
These hardlinks reference the stored application repositories and so they do not show its actual size, only the small size of the link.
Baobab, the program that is Disk Usage Analyzer, predates Snap and Flatpak.
It is fully applicable on logical file systems; but would need a complete overall in order to account for Snap and Flatpak. And while Snap and Flatpak have seen some rise in usage and popularity, it wavers because when they fail, they do so catastrophically and are very hard for the end user to fix
...huh. I trust that you're correct, but have a hard time getting from point A to point B here. I think I'm missing some element of file systems that would make this make sense--which is entirely possible, since all I know I picked up by osmosis. Thanks for clarifying the difference between monolithic containers, which I'm familiar with, and whatever the heck these weird things are.
I'll be over here continuing to prefer AppImage for containerized applications I think. <_<
Flatpak and Snap are weird and of the two... Snap is the weirdest and most infuriating.
Flatpak is much more stable, usable, customizable - an end user can manage and merge flatpaks, remove them, add them and they pool their bloat.
Snap... Needs to just go away. You Lost Canonical. Give. It. Up.
I think no one can make heads or tails of the mounting and redirecting of Snap and Flatpak in a moment or a couple posts...
I wouldn't touch snap even if I get paid for it. Flatpak is tolerable for me if there's no other choice, but prefer native packages.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
