Ooops

These people have no clue how to get around these DNS filters.

But not thanks to the virtue of some effective blocking but just a lack of knowledge of the average user...

I have used several of those cheap routers over the years. And they simply can't block you from using encrypted DNS (unless they want to create giant blocklists and want to play wack-a-mole with DNS servers...).

So all they usually do is very low tech like ignoring the DNS you set in the router configuration and reroute it (or not providing such configuration in the first place). But they can effectively ony do so with unencrypted DNS.

With encrypted DNS they could at best try to block the default port used by DNSoverTLS but that still leaves DoH. And they can't block that because it's just regular encrypted HTTPS traffic (with the DNS quesry inside).

Iirc even Windows allows easy configuration of DoH nowadays (and for much longer if you were ready to edit the registry) where you can simply chose between unencrypted, DoH only or encryption preferred if available.

The only thing they can realistically harcode is the DNS server their router's DHCP provides.

Just configure devices to not use that setting, also use DoH or DoT (which you should do anyway, not just to circumvent your router's settings).

make sure all of your devices are secure using encrypted DNS and encrypted traffic

Which is so easy it really should be the default nowadays yet sadly isn't.

No, that's just the latest official nvidia driver still supporting those cards provided as a regular package for that distro.

Basically the moment nvidia dropped support for some cards, they split the nvidia package. They are now provinding nvidia-open (all cards still officially supported by nvidia are also supported by the new open soruce driver) and 'nvidia-580xx' for older ones. And although the actual driver by nvidia doesn't change anymore the package isstill maintained in the sense that they look out for it to work with up-to-date Linux kernels.

Arch Linux at the moment provides (via the community maintained repos) nvidia drivers all the way back to 'nvidia-340'. That's GeForce8800 or QuadroFX age from 20 years ago.

I don't know how Ubuntu in particular handles their drivers, but I would assume that at some point support of your card ends end you will then have to install nvidia-<number of the last driver version with support> or nvidia-legacy or something like that, which automatically replaces nvidia.

Nvidia ends support at some point, no matter which OS.

Your card is one of the oldest series still supported (Turing), they just cut support for roughly gtx750 to 1080 (Maxwell, Pascal, Volta).

So 10 years from now, you won't get working Nvidia drivers anymore and will have to rely on older driver versions.

But unlike Windows -where you will have the same problem and MS won't care at all, so when an old driver has problem with Windows then, you will be on your own- you will have distros or their communities still providing those older drivers regularly and also there is now an open source driver. And your card is the first generation supported by that driver, although with still some hickups. That one will not go away and get better over time, too. Probably also including some work to increase performance on older cards if there is demand - and if I take a look into my crystall ball (or at the hardware prices shitshow) I assume there will be demand.

TL;DR: I can't absolutely guarantee that your card still works in 10 years as Nvidia's support will just end at some point. But your chances are a) very good and b) definitely much better on Linux than on Windows.

Take a look at the config file (/etc/radicale/config). It's extensively commented. Although you barely need to change any defaults for regular use.

Just create an htpasswd file (with htpsswd, apache-tools or just any of the one million available online generators) and edit two lines under [auth] to read type = htpasswd and htpasswd_filename = <the location and file you created>.

And you can start (and enable) Radicale via the systemd service usually included in the installed package. (Or for early testing just start the server manually... radicale starts it with the defaults from the config file. You can also configure everything with parameters but that's an insanely long list (radicale --help if you are interested in seeing them)...)

The webinterface to login will be available (by default settings) under http://localhost:5232/.

All you have to do then is change the config so Radicale listens on the server's IP instead so it's available in in your network. (Plus the usual stuff of making it available from the outside if you need that like for any other sevice)

And any calendar/contact software will bring a wizard that guides you through the process of sync'ing, usually just asking for an address to reach your server, as well as user and password.

EDIT: I looked up the defaults and you can skip all the autehntification stuff in the beginning. By default just anyone can access the webpage at port 5232. So you can just test it and only bother with authentication later (definitely when you plan to make it available from the outside, for example to sync phones).

With radicale, do I need to install some other somewhere in order to use it?

No, you just need to install Radicale. That's it. calDAV and cardDAV are widely used formats available as an option with basically any calendar.

Can a self hosted calendar still send and receive invites to other calendars?

Oh, I see your problem. You don't host your calendar. You host a service that is used to synchronise all the regular calendars you already use over different devices.

Or are you at the moment using Google's calendar in browser only?

it’s getting more prevalent as more stuff (especially servers) run on Linux [...] Linux’s days of living in “security through obscurity” are over"

Servers are primarily running Linux for decades. So any security through obscurity would be gone for as long, if it even existed ever...

though I’ll admit to not having tested that sort of thing with Wine/Proton installed

The more primitive the better the chances. And there are some really primitive cases of ransonware perfectly happy with running through Wine and encrypting your files. So limiting Wine's file access (or better running it as a separate unpriviledged user with no access to anything but your games) is always a good idea.

pacman -S vulcan-mesa-implicit-layers

Which will then probably tell you that it conflicts with vulkan-mesa-device-select and asks if you want to replace it. Which might either work or just get you another conflict because vulkan-mesa-device-select is required by some other package.

Btw... pacman -Qi <package name> usually tells you anything you need to know about a package. In this context mainly why it was installed (as a requirement for which package) and which other packages are required as a dependency.

So maybe you should take one step back first. Check why 'vulkan-mesa-device-select` was installed in the first place. If it's not dependency of something else you can either remove it (or replace it) alongside its lib32 version.

That's a totally separate error... It can happen that the keyring itself is so out of date that it blocks the update, and with it the upgrade to a newer keyring. For this reason it's often safer after a long time to do pacman -Syu cachyos-keyring (pretending I guesse right and that's the name of the package) first to avoid the whole update getting blocked by signature with an out-of-date-key. Yet that should not apply here.

But Ignoring the warnings you get for now... This looks like vulkan-mesa-implicit-layers did not replace vulkan-mesa-device-select but now the 32bit library version lib32-vulkan-mesa-device is supposed to be replaced by cachyos/lib32-vulkan-mesa-implicit-layers, which would in turn need vulkan-mesa-implicit-layers as a dependency.

What happens when you answer 'no' to that first question? Alternatively, is there anything keeping you from installing vulkan-mesa-implicit-layers (thus replacing vulkan-mesa-device-select)?

Not using CachyOS but Arch... but after a long break from updates you should probably start by checking if your mirror is still up-to-date (doesn't look like it when you local stuff is newer...).

Again... not my OS but this seems to be the file you could use to manually replace the mirrorlist in your /etc/pacman.d/ directory.

Edit: Also just to be sure... -Syyu will force a refresh of all databases (doubling the u would force "upgrading" even it's an actual downgrade from your local version). You normally don't do it because it puts extra load on the mirror, but in case of problems it won't hurt.

PS: For the future (and although partial upgrades are normally to be avoided)... after a long break in updating the key breaking points are mirrors, then keyfile (they can be so out of date that you can't start the update; so do them separately first - If CachyOS keeps with its usually sane naming structure the package you should first update, just to be sure, will named cachyos-keyring, but no guarantees there...), then pacman itself...

The latter is very rare but there have been a handful of major changes in pacman's lifetime that broke down compatibility after a long time. Arch keeps a static pacman version available for these cases, so you can still do a proper update to fix it, but don't know where CachyOS keeps it's equivalent.

2nd Edit for sake of completion: A quick searched seems to indicate that CachyOS does not have a separate static pacman. So if everything else fails and it's an actual problem of pacman itself (and only then, so please don't try that just now) https://pkgbuild.com/~morganamilo/pacman-static/x86_64/bin/pacman-static has the static standalone version of pacman. So you can download this file, make it executable and run it.