dd-mm-yyyy is not an insane format, thank you.

KDE Connect and SyncThing

(Edit: Fixed image)

Honestly, don’t use hobby distros unless it’s just for testing purposes. They will fail you in the end, always.
That being said, if you want to check out another hobby distro, PikaOS is pretty fucking cool: https://wiki.pika-os.com/

Should I worry that this is essentially a security update for vulnerabilities that are (intentionally?) not explained?

Do you have a writeup about this somewhere? I’d be interested in learning how that works.

Dude, you can’t even use the right abbreviation. Get lost.

I tried running chromium, removing :home and was still able save and open webpages in ~/test.html. However, this happened through the native file picker dialog.

It’s not proprietary, though.

your firewal

Well, blocking inbound traffic from these countires is part of my firewall. I have some services that are exposed on the internet, but I don’t want the whole world to hammer these services, scrape them and potentially exploit vulnerabilities on them. I know a VPN would be more effective here, but that’s not an option for every service.

That’s not a Graphene feature, that’s a feature of the supported device and one of the few reasons why Graphene is only available on Google Pixel phones.

$ grep -i "dns" /etc/letsencrypt/renewal/enter.domain.here.conf

authenticator = dns-netcup
dns_netcup_credentials = /path/to/netcup/credentials.ini

AFAICT it is using DNS challenges, unless the cerbot netcup plugin somehow does stuff it shouln’t need to do.

enter.domain.here is simply a redaction of my real domain as I did not want to doxx myself.

Outbound traffic has never been blocked, so it’s not a matter of me or my “certificate manager” being able to reach Let’s Encrypt.

I’ve been using DNS challenge for this domain from the start. I’m not sure what you mean by external DNS hosting. The domain is from netcup, the certbot host runs in my local network (as does the HTTP server that the domain points to).

Netcup is a German hosting company, I live in Germany, inbound traffic from Germany is NOT blocked on my router, outbound traffic isn’t blocked at all.

I have an old Debian 11 “bullseye” installation running on one of my servers. It’s stuck at nginx 1.18.0, but it should theoretically still be covered by Debian 11 LTS security updates, right? https://wiki.debian.org/LTS/Using
nginx/oldoldstable-security,now 1.18.0-6.1+deb11u5

Huh?

Android (TV) on a Raspberry Pi: https://konstakang.com/

You miiight be able to recover the array if you’re lucky

I don’t see how this would apply. Having the disks connected externally is the same as having them connected internally, maybe over a different bus/protocol, but the principle is the same. No RAID solution I know of would lose the array on a power outage (AFAIK).

the problem is the target not being able to manage its own interrupt

Honestly I don’t see how interrupt handling would be any different between internally or externally connected devives, except for different buses/protocols handling it differently intrinsicly. Are you absolutely sure this is a thing or are you just speculating?

you have two different states

Maybe I’m too spolied by using ZFS, but again I don’t think this would actually be a problem. But AFAICT you don’t even need a CoW filesystem for that to be not a problem. Every journaling filesystem (e.g. ext4) would solve this by dismissing the newest non-consistent data and restore a working state.

I mean, there are 60-bay 19" expansion units for enterprise storage systems. I doubt these would be a thing if having the drives connected externally was a problem.

Nope, just JBOD enclosures.