You could make it about equivalent to the protections afforded by the typical BIOS password, i.e. the attacker must first disassemble your laptop to reflash the spi chip or pull the hard drive. A grub.cfg like so would do, assuming everything in encrypted partitions:

set prefix=(memdisk)/boot/grub
set superusers="myuser"
password_pbkdf2 myuser grub.pbkdf2.sha512.10000.<your hashed password>
cryptomount -u <UUID of LUKS container>
search.fs_uuid <UUID of the root filesystem under LUKS container> root cryptouuid/<UUID of LUKS container>
configfile ($root)/@rootfs/boot/grub/grub.cfg

Assuming you boot directly to GRUB or locked out the SeaBIOS boot device selector, then GRUB will only ever look for a boot device matching your disk’s UUID; attempting to do anything else aside from entering the LUKS passphrase will prompt for the GRUB password. You’d still have your own recovery path by pressing Esc, entering your GRUB password, and dropping to the GRUB shell. Bonus points for patching the GRUB code so it doesn’t echo the UUID of your disk.

No, it isn’t bulletproof against physical access. But yes, I had the same question you did when starting out with coreboot and this was the solution I came up with.

Focus follows mouse and unchecking the option to auto raise the active window. Couldn’t live without it and being used to it has made me extremely clumsy when I do pick up my Windows work laptop.

I change the taskbar clock to be a one-line MM/DD HH:MM:SS format, drop in my customized locale (based on en-US for maximum compatibility, but without having to deal with US formats and units that I’m not fond of), and point the taskbar shortcut for my text editor to a script that creates a pre-named file and launches the editor with autosave enabled. Because having to manually save and come up with a name for your spur-of-the-moment notes sucks, automatically generating 20260831_text_1 is so much better than a, b, a2, etc.

XFCE specific, I get rid of the second panel full of launchers. Acquired taste, but also Chicago95 theme and icon pack.

As others say, where the use cases are so specific to each machine, it’ll be a headache juggling all of those images if your needs and workflow change down the road.

But I’d be remiss to say I don’t practice a form of what you mention, I would go insane if I actually had to reinstall from distro defaults. I have a single perfected VM image with customizations and software common to all of my machines. And yes, if you were to go this route, there are little quirks to iron out manually each time I image to a new machine, even old and well-supported ones. Some just cosmetic, some preventing graphical output. Although still much less time than setting up from scratch.

It works well enough for me, but it also frankly leads to a poorly-documented system that will accumulate cruft with updates, and can’t propagate changes in the VM to my existing systems easily, so I’m interested too to see what other people here suggest. Particularly for those niche customizations that land outside of /home and /etc (e.g. /usr/fonts, packages not provided by the distro).

As someone who has used X11 and Wayland, it doesn’t matter for the typical user. If you, like me, have a penchant for some smaller desktop environments like XFCE or window managers, you will be stuck with X11, but many are already working on porting to Wayland.

Couple edge cases for gaming, namely screen tearing on some X11 configurations and certain Nvidia hardware running into issues on Wayland. For multi-monitor or high DPI users, Wayland handles per-monitor DPI and fractional scaling far better than X11. Maybe a couple more edge use cases for remoting into the desktop, but Wayland support is also improving quickly on that end. In any case, Wayland is by design more secure than X11.

it should use the encryption passphrase to auto unlock the keyring after the autologin

It doesn’t, hence the need to remove the password. Password only comes back every once in a while, rather than every login. Maybe a bad combination of desktop environment/session manager? LightDM with XFCE in my case.

Meanwhile, I’m fighting to get rid of the password on the keyring each time it comes back by itself. For context, my root partition is encrypted, so it’s not a huge deal if the keyring stored on it doesn’t have its own password, I think. I set up autologin to avoid a duplicate password, but since the session manager no longer unlocks the keyring, the keyring must have no password else I get a password prompt all over again. There’s probably a more elegant way, but I’ve yet to find it.

As long as you have a strong backup strategy, I would recommend full disk encryption during installation, especially if for a laptop. Peace of mind with negligible cost on modern hardware. Even accessing the encrypted disk from a live USB takes only two extra commands compared to an unencrypted disk. As long as the LUKS header doesn’t corrupt, hence the need for good backups.

Not going after a bug though, it’s just the way the included battery meter in Xfce (and other X11 battery indicators I’ve found) works, while things like Android track usage over time to give a better estimate.

But based on the other responses, it looks like I’ll have to cook it up myself.

Not that I’m aware of

Xfce

What about it? I see it kicking in at least 10 GB before my RAM is full and I haven’t noticed any fundamental differences between how zram works on my 48 GB workstation and my 8 GB devices. Maybe I’ve never had a workload that filled all 48 GB + extra zram capacity, but it’s never given me an issue.

My workstation has 48 GB RAM with 50% allocation allowed to zram, no disk swapping. It works just fine. Once I use up the majority of my RAM, it kicks in the same way it would on any other system with less RAM.

16 GB VRAM GPU, models stored on SSD, rest of the computer doesn’t have to be crazy. Intel Arc is best bang for the buck at the moment. You can get LLM running on 8 GB cards or even the CPU, but IMO such small models are more novelties than workhorses. I personally use Debian but you’ll be fine as long as your distro’s repo has drivers recent enough for your GPU.

For perspective, I’m using such a build to help with boilerplate code, single-use scripts that I don’t have the patience to trial-and-error (like ones that have to deal with directory structures and special characters), getting an idea of what’s what when decompiling and reverse engineering, brainstorming tip-of-the-tongue ideas, and upscaling images.

Can also endorse aptitude, but hopefully OP already has it installed prior to this issue. May have to manually install using dpkg if not. Whenever I run into issues like this, aptitude solves it 95% of the time, makes regular apt look like a baby helplessly crying.