Andres4NY
@MrMcGasion @Sunny Come to the dark side (xmpp, and jmp.chat) and get decentralized messaging and SMS support with that data-only sim!
@Blue_Morpho @Onomatopoeia Hm, is that something that snapraid scrub would theoretically catch? I'm thinking probably not, as the corruption would likely happen when initially writing the files, rather than after the files have been sitting around on disk for a while.
@eddyizm @flightyhobler A lot of us are just using Tempo out of f-droid (which has been stuck at 3.8.x), and would love to have a fork or update available in f-droid. Alternatively, an external f-droid repo.
@Flamekebab @non_burglar Sounds like snapraid might be a better fit for your needs. Since it runs over top of the filesystem, if you lose a disk you can still access files from the other disk(s). It's better than rsync, in that it would provide regular data validation ('snapraid scrub' once per week or so). It is more designed to work in raid5 rather than mirroring (raid1) setup, however.
@empireOfLove2 @tintedundercollar12 Yeah, that absolutely looks like a hardware issue. Memtest is a good idea, but also reseat the nvme and keep an eye out for overheating (eg, ssh'ing in and keeping the following running in a terminal:
while (sleep 5); do sudo smartctl -a /dev/nvme0|grep 'Temperature:'; done
). Components on the drive could be failing early when temperatures get high, but not high enough to trigger warning thresholds.
@kiol Syncthing? Restic? All packaged nicely in Debian, no need for containers. I do use Ansible (rather than backups) for ensuring if a drive dies, I can reproduce the configuration. That's still very much a work-in-progress though, as there's stuff I set up before I started using Ansible...
@kiol And then there's the stuff that's not packaged in Debian, like navidrome. I use a container for that for simplicity, and because if it breaks it's not a big deal - temporary downtime of email is bad, temporary downtime of my streaming flac server means I just re-listen to the stuff that my subsonic clients have cached locally.
@kiol On the other hand, for doing builds (debian packages and random other stuff), I'll use podman containers. I've got a self-built build environment that I trust (debootstrap'd), and it's pretty simple to create a new build env container for some package, and wipe it when it gets too messy over time and create a new one. And for building larger packages I've got ccache, which doesn't get wiped by each different build; I've got multiple chromium build containers w/ ccache, llvm build env, etc
@kiol I mean, I use both. If something has a Debian package and is well-maintained, I'll happily use that. For example, prosody is packaged nicely, there's no need for a container there. I also don't want to upgrade to the latest version all the time. Or Dovecot, which just had a nasty cache bug in the latest version that allows people to view other peoples' mailboxes. Since I'm still on Debian 12 on my mail server, I remain unaffected and I can let the bugs be shaken out before I upgrade.
@MimicJar @moseschrute *touches finger to earpiece*
...hang on, I'm getting word that the most recent edition of this book will crash your nvram's firmware
@possiblylinux127 @A_norny_mousse ungoogled-chromium disables safe browsing, and for Debian's chromium package I keep going back and forth about whether to pull that patch in or not.