Yeah that stuff I myself got rid of back in the Gnome 1 days when you could still customize all that. I appreciate that the Gnome devs came to the same conclusions as me.

• Desktop icons are usually hidden behind windows. It makes more sense to put launch icons in front of everything else, like Gnome does when you hit the Win/Super key.
• Minimize is unnecessary when you have workspaces and efficient window switching methods. Same for the task bar.
• A long time ago, when I was young, I played around with themes and shit, when that was still supported. There were always problems. Theming any complex set of applications yourself is basically impossible without causing issues, and themes made by others also exhibited this problem. You need a concerted long-term effort, plus buy-in from basically all app development teams, to make a comprehensive theme. Note how Microsoft/Apple don’t want to support theming either.
• Systray was always some excuse for apps to just keep running in the background while not taking up taskbar space. Steam can go fuck itself, just please exit when I ask you to, and don’t treat the close button as “minimize”. If I wanted Steam running in the background I would just put it on another workspace.

I have this working on Debian like how you have it set up, everything on an encrypted lvm volume, except for boot and efi. Just one disk though. When waking up, it asks for the password like it does during normal bootup. It then restores RAM from the encrypted swap after you type the password. I think it worked out of the box, but it has been a while, so not 100% sure if I had to enable this somehow. Anyway this looks good to me.

If you manually run systemctl hibernate, does that work? Assuming this also does not work, you need to look at the logs during the failed hibernate attempt. Probably something like sudo journalctl -f and/or sudo dmesg -wH (for kernel logs). Open this up in two terminals, run systemctl hibernate and observe any errors or warnings.

It’s possible this is a hardware/driver issue, i.e. a driver prevents hibernation or fails at it. You may be able to figure out which driver/device is responsible by looking at the logs.

I looked at this a looong time ago, but the basic idea is that the tokens (equivalent to cash coins/banknotes) are generated on the end user’s device, through some public-key cryptographic back-and-forth protocol. The issuer (bank/central bank/payment provider) does not see these tokens (they’re only on the end users device), but can verify that they’re legit (i.e. issued by them) somehow.

You can take one of these tokens to them, and deposit it in an account. They won’t know who it’s from but they know it was legitimately issued by them. Depositing a token is also supposed to be the only way of figuring out if it is a legit token, the bank will not tell you if a token is legit unless you deposit it.

When someone pays with these tokens in a shop, the shop will want to immediately (during checkout) deposit them, to make sure they’re legit, and also to make sure the token hasn’t been double spent. A shop that doesn’t do that makes itself vulnerable to fraud. This means shops will have a hard time hiding their revenue (to dodge taxes) compared to cash.

If someone you trust gives you a token (birthday money from your grandma, say), you don’t have to immediately deposit said token, since presumably you trust your grandma to not give you fake or double-spent tokens. Since you trust you grandma, there is no need to deposit the token and involve the bank, and that transfer would be untraceable (it’s literally just copying a number from her phone to yours).

The idea is that shop owners would have a hard time dodging taxes without opening themselves up to fraudsters using fake tokens, while the customer cannot be identified. You’d also be able to exchange tokens with family and friends in a way that isn’t traceable, as long as you trust them to not screw you over.