Podman/docker leave behind old images, image layers, and containers that need to be cleaned up occasionally. podman system prune will do so.
If 8TB was taken up quickly or unexpectedly, it might be something like a container failing to start and being recreated over and over, leaving each failed container behind as it goes. podman ps --all will list all containers, running or stopped. Before doing the system prune run that and podman image ls --all to see if anything looks amiss.
Subscribed/Scaled most of the time, which gives me a nice selection of things I'm interested in, with a boost for posts from smaller communities so they don't get drowned out by larger ones.
All/Hot when I want to check in and see what the rest of the fediverse is up to.
It's the central meta-community for our instance, which has been having a lot of downtime the last few days. We tend to check in here when it comes back online.
I just set up Readeck a few weeks ago, and I've been liking it. Very minimalist, utilitarian. One feature I'd like that isn't included is the ability to add specific labels or collections to the sidebar, but that's my only quibble so far.
It has an official browser extension for adding urls to it, but if you can't or don't want to use that, it has a nice api. I use the api to add bookmarks from my phone using a termux-url-opener script, which is as easy as the extension - just hit the "share" button and select termux, and it does the rest.
Navigating around supporting bad actors in the foss community is probably far easier than in the closed, commercial software space, given that all the code, discussion, and money are out in the open.
Also I think the proportion of fascists and bad actors in the foss community is probably lower than elsewhere in the first place, given that the community is based on the free and open sharing of work and knowledge.
I think my favorite thing in tech is blinkenlights, and my homelab is designed with that in mind. It's pretty, and it's like you can see the bits and bytes flowing around ♥️✨
I compile the kernel on all of my raspberry pis with LEDS_TRIGGER_ACTIVITY enabled, just so I can turn the power light into a cpu blinkenlight, and set the led triggers to some kind of activity on all my laptop and openwrt leds to turn them into blinkenlights too. Blinkenmaxxing.
I think one of the issues inherent to the node ecosystem is that the coast is never clear. When the ethos is to never reinvent the wheel, and instead pull in a dependency chain of thousands of tiny things made by thousands of people (not necessarily a bad thing, it saves time and lets developers focus on what they really want to do), you're going to have supply chain attacks that go undetected, because nobody has time to vet every single change to all those thousands of things.
The rclone fuse mount is essentially running in the memory of the container, and doesn't translate back into the filesystem that the host presents from itself into that container.
Since rclone is available in the debian repos, the simplest and easiest option would be to do the rclone mount on the host and then pass that via bind mounting into the Plex container.
If you want to keep the rclone mounting containerized though (or if your Proxmox host is clustered, you want to mount it on the host, and you want the mount to be shared between your nodes), you can use rclone's experimental but built-in nfs server feature: https://rclone.org/commands/rclone_serve_nfs/
Make sure your 2 containers can talk to each other over a secure network ("this server does not implement any authentication so any client will be able to access the data"), start the nfs server in the rclone container, and mount it via nfs in the Plex container.
apt-get clean will clear the apt cache and should give you enough temporary storage headroom on /var to do things, but if you're bumping up on this limit often, you'll need to reconfigure your storage.
/var is often where processes dump a lot of data (logs, databases, etc), and subpartitioning of /var sets a cap so that when too much data is dumped there, the application crashes instead of the whole system. /var/log is often recommended to be subpartitioned separately as well, so that logging can still go on if the application data fills up and crashes.
These kinds of overruns can be intentional DOS attacks, also, so the subpartitioning is often a security recommendation. NIST 800-171 requires separate partitions for /var, /var/log, /var/log/audit, and /var/tmp
Forgejo (Gitea fork used by codeberg.org) is a lightweight self-hostable option, and has a web-ui-based file editor. It's got an official docker image, and it's packaged for freebsd, as well, which makes it very easy to deploy and maintain either containerized or on a server.
With the size of modern linux kernels, I think 1GiB for a /boot partition is the absolute minimum I would go for a current full-sized distributuon. You'll run into these out-of-space issues on updates all the time otherwise.
My adhesion was like this until I washed my bed with dish soap, and now I have to chisel my prints off with a hammer because they stick on too well.