

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.


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.


$ 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.


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
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.
I like this one: https://www.qnap.com/en/product/tl-d800c
Or here, the new version: https://www.qnap.com/en/product/tl-d810tc4
Those are just nclosurs though, no built-in RAID functionality.
Please elaborate on point 3.


For rocm, old is bad.


But It’s Months Out-Of-Date
So, par for the course for Ubuntu, no?


Sure, but that doesn’t make any difference in the maintenance effort required.


If I write my own Dockerfiles to tag my own images I also have to run my own update management.
I like to outsource this, so all I have to do is a simple docker compose pull (or in reality, let Dockhand or watchtower handle it).


https://gosuki.net/
This one?
Looks like it doesn’t come with docker and seems like you don’t get access to the full source on the free version?



Little Snitch has nothing to do with ad blocking. I don’t know what you’re talking about.
KDE Connect and SyncThing