I really don’t see any advantages in your post for choices other than NixOS. I’m sure you’ll improve quickly by necessity! :D
I really don’t see any advantages in your post for choices other than NixOS. I’m sure you’ll improve quickly by necessity! :D
That shirt is awesome 💜
It is difficult to get a man to understand something, when his salary depends upon his not understanding it!
+1 for Codeberg.
Sourcehut is interesting too, but its workflow is different from GitHub.
Spongebob obviously uses doas.
I know, I got the wording from some online website. Linux phones doesn’t make too much sense to me, I would prefer to just call them GNU phones. The kernel can’t be what defines this group of OSs when the main OS you’re trying to exclude from this group runs the same one. GNU-like is a compromise.
Some people take offense in referring to Alpine/postmarketOS as GNU.
I totally see what you mean with the GNU-like Linux phones. But what issue could you have with Wayland in the year 2024?
Maybe this isn’t low effort bait but a bad NixOS ad
ARM I guess, or increasingly RISC-V
deleted by creator
maybe he got those quotes from Wozniak, too /j
Declarative OS, tmpfs root, disabled sudo
How do you change anything about the OS/do updates? iirc nixos requires elevated privileges for that?
With Debian it’s just the apt-tor package, and the project maintains an official list at… onion.debian.org iirc?
I don’t know if serving onion traffic is more expensive for Debian/mirror maintainers so idk if this is something everybody should use
I think Heads (osresearch.net) uses security keys as a kind of substitute TPM, however that only works if you replace your - supported - PCs firmware with it.
I don’t know too much about how this works in particular, so I can’t really compare it. safeboot.dev recommends Heads where possible, which I understand is partly due to safeboot relying on proprietary firmware implementations, while Heads uses libre software for the most part. Sadly the Heads firmware only supports older models/CPUs, which afaik don’t receive (all) microcode updates, including one which weakens the IOMMU.
Yes, with a TPM. A TPM (2.0) can seal secrets and only release it when a machine fulfills certain configuration and state requirements (saved into registers called PCRs).
For example: make the decryption key one part dependant on a passphrase you memorized (to not only rely on a TPM), and one part on something saved in a TPM. If you select the correct PCRs when saving the latter, and your TPM works as advertised (and doesn’t offer an easy way to eavesdrop/fool it), removing the battery would make the TPM not release the secret (if removing the battery even still works on modern machines).
However, this depends on having a unified kernel image, having configured dm-verity and maybe more stuff I don’t recall right now. Probably should also make sure you don’t allow Microsoft’s Secure Boot keys and instead only your own. I hope this will get easier in the future, but I know SystemD is actively developing useful tools for that (e.g. ukify).
That all doesn’t mean the critique of TPMs (intransparent, proprietary) is invalid. Maybe we’ll have OpenTitan based TPMs at some point?
See safeboot.dev for a project which tries to fix this.
Dino and Conversations weren’t good enough?