chameleon

Basically yes. Rancher Desktop sets up K3s in a VM and gives you a kubectl, docker and a few other binaries preconfigured to talk to that VM. K3s is just a lightweight all-in-one Kubernetes distro that’s relatively easy to set up (of course, you still have to learn Kubernetes so it’s not really easy, just skips the cluster setup).

Most paid certs aren’t worth much anyway. Payment and delivery info for DV certs isn’t validated by anyone, it’s literally the same concept as Let’s Encrypt. OV and EV are the only ones that theoretically have any value, but nobody is using those ever since they got rid of the URL bar labeling; even Amazon is on DV nowadays.

It depends on if you can feasibly implement compatibility layers for large parts of the “required” but very work-intensive drivers. FreeBSD has the same driver struggles and ended up with LinuxKPI to support AMD/Intel GPUs. I know there’s a whole bunch of toy kernels that implemented compatibility layers for parts of Linux in some fashion too.

It’s a ton of work overall but there’s room to lift enough already existing stuff from Linux to get the ball rolling.

In my experience, most hangs with a message about amdgpu loading on screen are caused by an amdgpu issue of some kind. I’d check to see if amdgpu ends up being loaded correctly via lsmod | grep amdgpu and just a general journalctl -b 0 | grep amdgpu to see if there’s any obvious failures there. Chances are that even if it’s not amdgpu, the real failure is in the journal somewhere.

Could be a wrong setting of hardware.enableRedistributableFirmware (should be true) or the new-ish hardware.amdgpu.initrd.enable (can be either really but either true or false might be more or less reliable on your system).

Gonna add a dissenting “maybe but not really”. YT is really aggressive on this kinda stuff lately and the situation is changing month by month. YT has multiple ways of flagging your IP as potentially problematic and as soon as you get flagged you’re going to end up having to run quite an annoying mess of scripts that may or may not last in the long term. There’s some instructions in a stickied issue on the Invidious repo.

Did a physical-to-virtual-to-physical conversion to upgrade and unbreak a webserver that had been messed up by simultaneously installing packages from Debian and Ubuntu.

It’s a problem in the Secure Boot chain, every system is affected by any vulnerability in any past, present or future bootloader that that system currently trusts. Even if it’s an OS you aren’t using, an attacker could “just” install that vulnerable bootloader.

That said, MS had also been patching their own CVE-2023-24932 / CVE-2024-38058, and disabled the fix for that in this update due to widespread issues with it. I don’t think anyone knows what they’re doing anymore.

My dotfiles aren’t distro-specific because they’re symlinks into a git repo (or tarball) + a homegrown shell script to make them, and that’s about the end of it.

My NixOS configuration is split between must-have CLI tools/nice-to-have CLI tools/hardware-related CLI tools/GUI tools and functions as a suitable reference for non-Nix distros, even having a few comments on what the package names are elsewhere, but installation is ultimately still manual.

There’s been an exFAT driver in the kernel for a couple of years now (merged after Microsoft’s patent pact added ExFAT), it works fine. Same driver gets used on Android for SD card support.

Easiest way would be to use borg create --read-special --chunker-params fixed,4194304 '/home/user/sdcardbackup::{now}' /dev/sdX (which I copied from the examples in the documentation). I’m not sure if Vorta has a way to activate --read-special but I suspect not; you can most likely still use it to make the repo and manage archives inside of it though.

Backing up from a command/stdin might also be relevant as an alternative, since that lets you back up more or less anything.

Elixir, or Gleam/pure Erlang/some other Erlang VM language. I think Erlang is extremely cool and I’ve enjoyed the little time I spent with Elixir. I also have absolutely no use case to make proper use of it.

Eh. I’ve been on the receiving end of one of those inboxes and the spam is absolutely, utterly unbearable. Coming up with a better system than a publicly listed email address is on Google at this point, because there is no reasonable way to provide support when you need a spam filter tuned up to such a level that all legitimate mail also ends up in spam.

Personally, I do believe that rootless Docker/Podman have a strong enough security boundary for personal/individual self-hosting where you have decent trust in the software you’re running. Linux privilege escalation and container escape exploits fetch decent amounts of money on the exploit market, and nobody’s gonna waste them on some people running software ending in *arr when Zerodium will pay five figures for a local privilege escalation or container escape. If you’re running a business or you might be targeted for whatever reason (journalist or whatever) then that doesn’t apply.

If you want more security, there are container runtimes that do cooler security stuff under the hood, like Firecracker/Kata Containers implementing a managed VM, or Google’s gVisor which very strongly intercepts kernel syscalls and essentially reimplements Linux in userspace. Those are used by AWS and Google Cloud respectively. You can integrate those into Docker, though not all networking/etc options are supported.

That’s because they had a lot of people “buying the dip”. CS is in a very similar position to SolarWinds during their 2020 security slipup. The extent of managerial issues there should’ve been unforgivable but unfortunately they got away with it and are doing just fine nowadays.

My suggestion is to use system management tools like Foreman. It has a “content views” mechanism that can do more or less what you want. There’s a bunch of other tools like that along the lines of Uyuni. Of course, those tools have a lot of features, so it might be overkill for your case, but a lot of those features will probably end up useful anyway if you have that many hosts.

With the way Debian/Ubuntu APT repos are set up, if you take a copy of /dists/$DISTRO_VERSION as downloaded from a mirror at any given moment and serve it to a particular server, that’s going to end up with apt update && apt upgrade installing those identical versions, provided that the actual package files in /pool are still available. You can set up caching proxies for that.

I remember my DIY hodgepodge a decade ago ultimately just being a daily cronjob that pulls in the current distro (let’s say bookworm) and their associated -updates and -security repos from an upstream rsync-capable mirror, then after checking a killswitch and making sure things aren’t currently on fire, it does rsync -rva tier2 tier3; rsync -rva tier1 tier2; rsync -rva upstream/bookworm tier1. Machines are configured to pull and update from tier1 (first 20%)/tier2 (second 20%)/tier3 (rest) appropriately on a regular basis. The files in /pool were served by apt-cacher-ng, but I don’t know if that’s still the cool option nowadays (you will need some kind of local caching for those as old files may disappear without notice).

Realistically, immutability wouldn’t have made a difference. Definition updates like this are generally not considered part of the provisioned OS (since they change somewhere around hourly) and would go into /var or the like, which is mutable persistent state on nearly every otherwise immutable OS. Snapshots like Timeshift are more likely to help.

For that card, you probably have to set the radeon.si_support=0 amdgpu.si_support=1 kernel options to allow amdgpu to work. I don’t have a TrueNAS system laying around so I don’t know what the idiomatic way to change them is.

Using amdgpu on that card has been considered experimental ever since it was added like 6 years ago, and nobody has invested any real efforts to stabilize it. It’s entirely possible that amdgpu on that card is simply never gonna work. But yeah I think the radeon driver isn’t really fully functional anymore either, so I guess it’s worth a shot…

Company offering new-age antivirus solutions, which is to say that instead of being mostly signature-based, it tries to look at application behavior instead. If Word was exploited because some user opened not_a_virus_please_open.docx from their spam folder, Word might be exploited and end up running some malware that tries to encrypt the entire drive. It’s supposed to sniff out that 1. Word normally opens and saves like one document at a time and 2. some unknown program is being overly active. And so it should stop that and ring some very loud alarm bells at the IT department.

Basically they doubled down on the heuristics-based detection and by that, they claim to be able to recognize and stop all kinds of new malware that they haven’t seen yet. My experience is that they’re always the outlier on the top-end of false positives in business AV tests (eg AV-Comparatives Q2 2024) and their advantage has mostly disappeared since every AV has implemented that kind of behavior-based detection nowadays.

All GPUs released since they came out with the RTX 2000+ line are supported and all new GPUs will most likely have support, especially with this announcement saying they’re committed to it. There’s a support list on their GitHub and it includes all the weird little things you’d be worried about. Even silly little laptop chips like the new RTX 500 are on it.

I think the only reason they limited GPU support is because the older ones physically don’t have the hardware for this approach; they switched to their newer RISC-V “GSP” processors with the RTX line. In the new open module, all of their proprietary “secret sauce” was shoved off to firmware running on that new GSP. Previously, their proprietary kernel module loaded all of that same secret sauce as a gigantic obfuscated blob running on your normal CPU instead. The Windows side of their driver has also been moving towards using the GSP, they even advertised it boosts performance or whatever, and I can believe it.

That said, with this new stuff, the official Nvidia userland portions providing Vulkan/OpenGL/CUDA support and the like are still proprietary. It’s still worse than AMD in that regard. But at least it’s possible to replace those bits, and Mesa/NVK are working on getting Vulkan up and running (with NVK supposedly getting pretty damn good, and Mesa’s OpenGL-on-Vulkan is pretty good too so that’s free).

.eu has custom rules for whois. You’re not allowed to use privacy/proxy services for anything other than the mandatory publicly shown email field, but for domains registered by an individual, that email field and the user’s preferred language are the only things displayed. They’ve had those rules even prior to GDPR.