By Bertel King - Published Apr 22, 2026
From the moment GNOME 3 launched back in 2011, I felt like it was perfect for a touchscreen, and I’m happy to say that it absolutely is. I’d even go so far as to say that the GNOME interface is a better way to navigate a touchscreen than that of Android or iOS. I’ve said before that I would love to see an official GNOME-only OS, and this experience has only strengthened that desire.
Every aspect of GNOME is easy to tap with a finger. Opening the app drawer and swiping between workspaces feels completely natural with three-finger gestures. Windows are easy to drag around, maximize, or pin to the side. The virtual keyboard that pops up when I tap an input field is the only visual distinction from desktop GNOME. (…)


TPM2 + Secure Boot via
systemd-cryptenrollis the closest to the “just works” FileVault/Android experience. Keep a recovery passphrase in your password manager. You don’t lose your data if the motherboard dies, you just use the recovery key.I use this on my daily drive laptop. Only real hiccup is that I still keep the dual boot because fwupd does not cover my laptop BIOS firmware updates but in a Linux tablet this a no issue.
Why not use LUKS? Hibernate to partition (even LVM) works, all native, and full disk support.
LUKS isn’t the alternative here, it’s the baseline. The question is how to unlock LUKS without manual passphrase entry at boot.
Using TPM2 + Secure Boot (e.g. via systemd-cryptenroll) binds the LUKS key to platform integrity, so it auto-unlocks when the system hasn’t been tampered with. You still keep a recovery passphrase, so you’re not locked out if hardware changes or fails.
But then anyone can just walk up to the machine and turn it on and have it be decrypted. Am I missing something?
TPM auto-unlock still relies on measured boot integrity (Secure Boot/PCRs), so it protects against offline theft and tampering when the machine is off or storage is removed.
But if an attacker has repeated physical access during boot, the protection depends on whether you’ve added extra factors like a TPM PIN or pre-boot passphrase. Login prompts don’t re-protect the disk once it’s decrypted.
In practice, for my use case (mostly shutdown or battery-dead scenarios), this is an acceptable trade-off for convenience. If your threat model includes targeted physical access during boot, then keeping a pre-boot secret is still the safer choice.
Ahh so the pin or passphrase would basically give the same protection. Thanks.