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. (…)
I’ve been running Gnome on a Surface for a while. It’s an outstanding tablet UI except for its onscreen keyboard. The keyboard is terrible. I could write a full-length article about how terrible the keyboard is, but here are a few quick complaints:
- No long-press layer; most other OSKs have a secondary layer to get numbers and punctuation via long-press
- No way to move the cursor; it’s drag on the spacebar for most OSKs
- No way to add the number row to the default layer; numbers always require tapping a key to activate the number layer
- No arrow or modifier keys by default; they show up in Gnome Console, but I might use a different terminal app or need them elsewhere
- No good way to switch to a third-party keyboard system-wide; even iOS has that now
I could write a full-length article about how terrible the keyboard is
Well then, it couldn’t be that bad.
I suppose I should clarify that I could write a full-length article about it on something else.
I see what you did there. 😆
Encrypting my hard drive requires a password at boot, which meant physically plugging in a keyboard until I could figure out how to decrypt using a USB drive instead. For a device that can easily be forgotten in public and one whose back can be easily taken off, I’m willing to deal with this slight inconvenience for encryption, but it’s one Android doesn’t require.
This is an issue I run into running a headless Linux computer as well. On macOS I’m never running headless, so never ran into this issue. But needing to enter a password before the OS boots is a decision that makes Linux kind of awkward to use disk encryption with.
And I’m almost certainly doing it wrong, so would appreciate being nudged in the right direction.
I’ve seen a post about storing the encryption keys in TPM, but others say then you can lose your keys if the mobo dies. I’ve heard you can use ssh keys, but I’m not sure how — and here that would require a second device to unlock your tablet.
macOS uses a read only OS partition to boot and then encrypts your user data partition, can I do that with Linux?
I’m about to make you happy. The below script puts SSH into initramfs, so you can SSH in to a prompt and type your LUKS password at boot. No part of the system is accessible over this SSH connection, just the prompt. You also still get the prompt locally on screen.
PORT=22 PUBKEY=... sudo apt install -y dropbear-initramfs echo "DROPBEAR_OPTIONS=\"-I 180 -j -k -p ${PORT} -s\"" |sudo tee -a /etc/dropbear/initramfs/dropbear.conf echo "no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command=\"/bin/cryptroot-unlock\" ${PUBKEY}" |sudo tee /etc/dropbear/initramfs/authorized_keys sudo dropbearconvert openssh dropbear /etc/ssh/ssh_host_ecdsa_key /etc/dropbear/initramfs/dropbear_ecdsa_host_key sudo dropbearconvert openssh dropbear /etc/ssh/ssh_host_ed25519_key /etc/dropbear/initramfs/dropbear_ed25519_host_key sudo dropbearconvert openssh dropbear /etc/ssh/ssh_host_rsa_key /etc/dropbear/initramfs/dropbear_rsa_host_key sudo update-initramfs -u -k all@tofu@lemmy.nocturnal.garden for if this is easier than what you are doing.
Yes, the dual partition approach is what I usually do with LUKS
Okay, on the weekend I’ll see if that can work with NixOS (so far my favourite distro).
You can write a luks key to a usb stick and use that to automatically decrypt at boot. https://wiki.nixos.org/wiki/Full_Disk_Encryption#Unattended_Boot_via_USB
What’s the general concept for setting up a dual partition for this purpose? I’m thinking of making a Linux server myself pretty soon.
Might want to try this instead: https://lemmy.world/comment/23441076
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.
Linux hardware can be a mixed bag. Most companies that sell PCs with Linux pre-installed are using off-the-shelf parts. When Star Labs offered a bespoke tablet
Wut. Why would you want some shitty bespoke solution? That’s vendor lock-in, broken drivers, and irreparable.
Meanwhile the rest of us are demanding off-the-shelf parts
I managed to get Debian with XFCE running permanently on a 6 year old Lenovo ChromeTab. It mostly works, but “touchscreen as a mouse” is clunky and the onscreen keyboard I use, “Onboard,” is utilitarian at best. As a low-distraction writing device paired with a mechanical keyboard and FocusWriter, it’s pretty cool. If anything, it’s a bit too decent a setup for that purpose, as the browser is usable and I left Wifi working.
Now to actually start using it… 🤣
