I can sleep "sleep". All system components are still powered on at this stage, so it uses the most power. But at the same time it's the quickest to get back into your system. All that's really happening with sleep is that the screen turns off.
Then you have suspend. Laptops often first go to sleep but then suspend after a long period of inactivity to save battery.
Then you have hibernation. I don't think this is used that often nowadays.
That's true for hibernation, but not suspending. Hibernation stores everything in RAM onto the disk then shuts off the PC; to resume the system, you need to unlock the disk to access that data. Suspending doesn't turn off the computer, it keeps the CPU and RAM active.
On my Fedora system, I can hit the suspend button and get back into the OS without needing to type my encryption password, only my user password.
With an encrypted disk, you only need to enter the encryption password when you shutdown or restart. Suspending and ~~sleep~~ lock screen don't need your encryption password.
Snake case.
On the kernel side, there are disagreements between long term C maintainers (who may not know Rust or may actively dislike it) and the new Rust community trying to build in Rust support. To make the Rust parts work, there needs to be good communication and cooperation between them to ensure that the Rust stuff doesn't break.
On the Debian side, they have strict policies that conflict with how Rust development works. Rust has a dependency system called Cargo which hosts dependencies for Rust projects. This is different from C, C++ where there really isn't a centralized build system or dependency hoster, you actually install a lot of dependencies for these languages from your distro's repos. So if your Rust app is built against up to date libraries in Cargo, it's going to be difficult to package those apps in Debian when they ship stable, out of date libraries since Debian's policies don't like the idea of using outside dependencies from Cargo.
Triple buffering is only active if the GPU isn't keeping up with double buffering. So it will mainly only be active for lower powered devices, like older integrated GPUs.
Yup. I like their just in December approach too. I have a problem with distrohopping so I'm often re-setting up my system. Every time I do, Thunderbird pops up donation prompts both in the app and in my browser. I get why they do it, but it's annoying when that happens. KDE's approach avoids this pitfall.
Most package managers do not touch your home directory, so they will not delete user data. That needs to be done manually.
Snap and flatpak are exceptions, with an optional argument they will also delete the app's folder (~/snap/appName for snap, ~/.var/app/flatpakID for flatpak).
their insistent to theme libadwaita apps disregarding app developers wishes against supporting custom themes
Libadwaita theming is not enabled by default. It involves going into experimental settings and I believe there is a warning about enabling it. This does not conflict with Don't Theme My App, that initiative's problem is that it's a problem when distros do it, not individual users who know the downsides.
I wonder if this also affects native Wayland apps that use GTK for decorations, like Discord (with ozone flags set).
They did sponsor/donate to someone who got the Epic Games Launcher working through wine. Don’t remember the exact details and can’t find a link though.
Fedora Silverblue is great, it's my daily driver.