What happens if the NAS dies though? What does recovery look like?
Is it possible to recover the data from the drives without Synology's OS? If so what is that process and how difficult is it to do correctly?
I know that with ZFS, recovery is independent of vendor OS and/or hardware, so if the hardware dies you can just throw the drives into any COTS system with enough ports, but I'm genuinely unsure if that is the case for Synology or not.
ZFS, btrfs, and other software RAID solutions can use mixed drives w/o much issue as long as you make sure that the capacities match or that you set the array up with the smallest disk size in mind.
Do not use hardware raid controllers. They provide no meaningful performance benefit over software raid and make data recovery much more difficultm(if not impossible) in the event of hardware failure.
RSA4096 has a bit of an edge over ed25519 both in effective key size as well as support by things like YubiKeys and other HSMs that is beneficial for GPG but not really helpful for SSH.
SSH generally best to use ed25519, for GPG RSA4096 is better supported by HSMs and slightly more secure for longer-lived keys like root keys.
https://git.mlaga97.space/mlaga97/persistent-live-docker-flake has a builder for a live disk that will mount /dev/sda as ext4 to /persistent, and then start up dockge and whatever containers are present from the previous boot automagically.
OCI as in Open Container Initiative.
I've done something extremely similar with a custom NixOS iso for my docker VMs to make versioning and backups easier (golden image live disk with SSH+Docker+Dockge shared between all VMs + local persistent storage specific to each VM).
You can configure frigate via OCI container with custom config, as well as NFS mounts, SSH server, etc and then have a read-only live disk that boots up, mounts NFS share, and then starts up frigate.
I use a pair of small (2"x2" maybe) cheap adjustable adhesive parabolic mirrors, one at the outer bottom corner of each side view mirror and angled down towards the rear wheels for this purpose.
That way they are there for backing in or lining up the back of the vehicle pulling in, but the main mirrors can be aimed better for general use.
Have a bunch of KAUF Smart Bulbs that come pre-flashed with ESPHome
Also have a bunch of SonOff S31's and a bunch of Treatlife 3-way in-wall switches running ESPHome, but those both all required opening them up and making jigs to reflash them over to ESPHome from the stock firmwares.
(Edit: Plus a ton of custom ESPHome boards and piles-o-wires running ESPHome)
Yeah, I used Chrome up until extremely recently because genuinely no browser Just Works to the extent Chrome does.
Fast, good media codec support, Web API support for hardware access for PWAs, doesn't lock up w/ a lot of tabs (post-quantum FF is better about this, but not quite there), excellent DevTools, and just generally snappier and more polished than even chromium.
I switched to firefox recently exclusively for better home-manager support, and other than the ability to use home-manager more easily, it's just a slightly slower and jankier experience at all times whether it's requiring transcode for Jellyfin, laggy WebGL performance, janky DevTools, or missing WebAPIs.
Why are you being so condescending about this?
FPGAs are a great tool, but they're not magic.
They are a great way to prototype ASICs or for performing relatively simple low latency/high-throughput tasks below the economies of scale where actually taping out an ASIC would make sense but there is pretty much no case where an FPGA with a bunch of the same logic path is going to outperform a dedicated ASIC of the same logic.
NPUs are already the defacto ASIC accelerator for ML. Trying to replicate that functionality on an FPGA fabric of an older process node with longer path lengths constraining timing is going to be worse than a physically smaller dedicated ASIC.
It was the same deal with crypto-mining, the path for optimizing parallel compute is often doing it badly on a GPU first, moving to FPGA if memory isn't a major constraint, then tape out ASICs once the bugs in the gateware are ironed out (and economies of scale allow)
And that doesn't even begin to cover the pain of FPGA tooling in general and particularly vendor HLS stacks.
I need the max call volume to be about 20% higher than it currently is to understand what is being said outside of an anechoic chamber.
If zstd is available, it is a lot more efficient and performant over gzip.