avidamoeba

Perhaps the best answer by far is ZFS but I don't know how much pain it is to set it up to boot from on a Pi. The easiest to setup is probably LVM.

With ZFS you can trivially keep a hot spare even over the network. Just tell syncoid where to replicate.

Yeah, you're right, if it's meant as disks-only, then TPM is the easy solution.

I think SSH unlocked LUKS at boot might be a decent compromise, with the SSH server at a different physical location.

I mean, TPM-locked machine with all the other parts configured correctly should be reasonably secure. It would boot without interaction and be available on the network. It would require a sophisticated and motivated actor to find a vulnerability in one of the systems in the boot chain to get in. That's probably good enough for preventing data leaks from theft. But the user has to make sure the whole boot chain is configured securely.

This is probably an additional halving. 😂

If someone can login as root on that machine, by for example rebooting in recovery mode, they can also run the script and access the drives. Or they can get the password from the keyring. A keyring that doesn't require a password to unlock or whose password is stored somewhere on the machine is equivalent to plain text storage. There's no obvious solution other than ensuring the system can't be rooted without a login, I'm just pointing the flaw out in case you feel it's more secure than it is.

Wait, how's this gonna help? If someone swipes the machine, they also have the TPM. TPM only helps against someone reading the disks on another machine. TPM is only useful to protect data during physical access if the rest of the firmware/software stack is impenetrable. In practical terms this would mean locked UEFI, disabled alternate boot device, Secure Boot, locked GRUB, and locked logins. In effect the security of the data is transferred from the knowledge of a passphrase to the knowledge of a login password, and the attack surface is expanded across multiple systems that all have to be secure and configured correctly to not allow access prior to OS login.

Only useful if the backup machine isn't also used as a hot spare.

Swallowed the clickbait, hook, line and sinker.

HardKernel makesa a few ODROID models that come with available Android TV builds. Some have the same chipset as the AMLogic on the CCwGTV 4K and they aren't terribly expensive. If I wanted an open source Chromecast replacement I'd go for that.

Debian unstable: am I a joke to you?

Oof, hit them where it hurts 🤕

each vendor’s CPU design can differ vastly from one another unlike x86 which is standard and only between amd and Intel.

The ISA guarantees that a program compiled for it can run on any of these vendor designs. For example native binaries for Android run on any SoC from any vendor with the ARM ISA compiled for. The situation is exactly the same as with x86, Intel and AMD. Their core designs are very different yet binaries compiled for x86 run on either Intel or AMD, and on any of their models, even across different architectures. E.g. a binary compiled for x86_64 would run on AMD Zen 2, as well as Intel Skylake, as well as AMD Bulldozer.

How is RISC-V better at this?

It's better in that it's free to use. Anyone making a chip implementing RISC-V doesn't have to pay ARM or Intel for a license. Not that Intel sells them anyway.

The fragmentation issue might become a new problem. With that said we definitely want to move away from the only usable cores using ARM or x86, neither of which we can design and manufacture without the blessing of two corpos, one of which is a proven monopoly abuser.

Got it, so take the NES out of the drawer.