

I use unbound as an upstream resolver for Pi-hole, not directly on my machines. Be aware that resolving new domains can incur some delay (about 1s), but once cached, it’s pretty quick, even for additional entries on the same domain.
I use unbound as an upstream resolver for Pi-hole, not directly on my machines. Be aware that resolving new domains can incur some delay (about 1s), but once cached, it’s pretty quick, even for additional entries on the same domain.
Every developer wishing to offer applications on F-Droid will have to register their identities and package names to Google for Android devices to install their apps, regardless of the distribution platform (F-Droid, Obtainium, GitHub releases, etc.)
From my understanding, it will only allow apps that were registered, so since ReVanced uses identical package names to the patched apps, it probably won’t work unless they start using ReVanced-specific package names that are tied to their identity. But that would allow Google to block these package names (or ban ReVanced completely) if say, Spotify or YouTube complain about them.
Hopefully, the EU and other jurisdictions block this.
This is very similar to the notarization process Apple introduced to comply with the EU requirement of allowing third-party stores, and yet the EU doesn’t seem concerned (maybe because Apple did not allow third-party stores in the first place, will it be different for Google?)
I first read the original report from Android Authority thinking it would only be an additional hurdle for third-party stores and developers, but I’m now thinking that it would potentially block the use of ReVanced
1: I’m assuming (hoping) this wouldn’t be a full wipe and start over? It should just upgrade right?
Yes, you can upgrade in-place. If I recall correctly, you just have to change the release channel from LTS to non-LTS in the Sources app, then trigger an update (I don’t quite remember how to do)
2: Do I need to do the whole USB route, and if so is there an option to keep everything (I’m hoping, I put a LOT of work into this so far and I don’t remember if that was an option on first install).
No, as I said above. But it’s always a good idea to have backups if you ever need to wipe and re-install.
3: I remember a few apps I installed were specific to Noble, will this break those apps?
Hard to be 100% sure without knowing which apps and how they were installed, but most likely yes as their dependencies might no longer be available on Plucky.
4: It seems like there should be an option to upgrade from the desktop, but I don’t have that option. If I run
plasma-distro-release-notifier
I should get an update notification right? In which case I can just say “hell yeah!” and it’ll do its thing?
Refer to my first answer
What’s your issue exactly?
Personally, I set up Caddy with subdomains like radarr.local.example.tld
, added a DNS entry on my domain so that *.local.example.tld
points to the local IP of Caddy, then followed this guide so that Caddy issues TLS certificates using the DNS challenge (since the subdomains don’t point to anything accessible from Internet) along with the caddy-docker-proxy plug-in to easily manage upstreams.
Don’t you have any off-site backup? It would help keeping some peace of mind knowing you have a copy somewhere else.
In my experience with unbound, it tends to return expired records in the hope that they are still valid, causing issues with services hosted in the cloud, where IP addresses rotate regularly. What I did was update the serve-expired-ttl
setting in unbound’s configuration to 3 hours (down from the default 24h)
Ah, good idea! I just don’t have any non-magnetic screwdriver at home, I’m afraid as to what might happen if I get its magnetic tip close to a drive.
Oh wait, I found a lousy screwdriver, it works like a charm! It’s definitely the bottom one. Thank you very much!
What originally started as a git repo for storing backup scripts and a list of GNOME Shell extensions morphed now contains dot files, systemd units, Pipewire and Wireplumber configs, scripts for installing new software from Brew and Flatpak, and a systemd service that pulls and apply the latest changes on session startup.
I’d pick OpenSUSE over Bazzite because I don’t like the idea of updates possibly overwriting anything I install myself that isn’t flatpak/distrobox/homebrew
In atomic distributions you would install non-sandboxed programs in a layer that is applied on top of the base system. When your system is updated, that layer is applied back on top of the updated system. The only possible breakage would be if what you installed depends on a dependency in the base system that has been removed or which is no longer compatible.
I personally ended up running my containers on a VM on top of TrueNAS to get the best of both worlds (and because back then running applications directly on TrueNAS SCALE was convoluted)
You could read this article where the author runs NixOS in VMs on top of TrueNAS.
This. I have been using it a lot lately to manipulate CSVs, it is such a godsend.
You can’t, it just part of how Fedora works now. Maybe Fedora should patch Dolphin to take /sysroot into account instead of /
Fedora Atomic Desktop 42 switched to composefs, which has a small full partition mounted to /
. Your “real” filesystem is mounted on /sysroot
https://fedoraproject.org/wiki/Changes/ComposefsAtomicDesktops
I remember quite well burning an Ubuntu 9.04 Live CD, and before that trying an ancient Knoppix Live CD that my dad had laying in a drawer. I must have been 15 back then.
This. Just setup fail2ban or similar in front of Jellyfin and you’ll be fine.
Oh, that makes sense.
I would add that you can follow this guide for building Caddy with DNS Provider modules. For Docker you can start from the instructions for Caddy Docker Proxy