Hahahaha NO
rotopenguin
joined 2 years ago
The hard part is finding a stable identifier, instead of "this interface is know as sink 48 at this exact instant. It will be a completely different number tomorrow. It might even be a potato emoji, who knows?"
Might as well go for Win11, you're going to have to deal with it next year anyways.
Windows doesn't do minimal, it does whatever the hell it wants. There are some OOBE tricks to get a local account working.
I have used the privacy.sexy app to strip down some of the most obnoxious Win11 bits - be warned that you have to disable defender to have it work. Is it doing bad things? Is MS doing incredibly shady shit with their detections? Who's to say? When I turn on Defender afterwards, everything seems "fine".
There's no need to get rid of grub, or play games with different boot drives. Get to know how EFI works. Look at efibootmgr's output - that's pretty much all that the firmware knows. The firmware has multiple entries consisting of a drive (magic device number), a program path (EFI\grub\grub_x64.efi), and maybe a string to pass along. There is a priority list (0003,0001,0002) which MS occasionally likes to re-arrange.
Power management on "the most boring Intel chip imaginable" is still touch-and-go at times.
"Except when something breaks after an odd update once or twice per year"
You don't need snapshots, except for the moments when you do. The point of snapshots is that they're so cheap that you can let them roll on their own and only care about them the day your system breaks.
It's not like they're stuck on some outdated proprietary engine like RPG Maker. Minetest is under active development, with a small list of dependencies that are also under active development. It is under no particular rush to get off of X11/Xwayland.
Do you have pci-e slots? An nvme to pcie card is cheap - it's pretty much just passing from one connector shape to another.
And there's a separate effort called Mineclonia.
I made a systemd script that fires when going to / waking up from sleep - it checks how long the sleep was and if it was just a few seconds, it puts the computer back to sleep.
In hindsight, I think the thing that made it work was bluetooth was somehow responsible for the initial failed suspend. The second shot at sleep happened before bluetooth came back up, so it succeeded.
The memory requirements for virtualization is not negligible.
I've had some suspend adventures too, but my experience is just on Intel laptops.
About a month ago, Debian Trixie had a regression that made my laptop wake up right after a suspend attempt. Afaict, it was not directly a kernel change, something in userland changed and triggered problems. This pm_async thing fixed it. Frankly, I don't know why "async" power management is a thing anybody would want. Taking a whole extra millisecond to suspend in a more reliable way seems like a no-brainer.
echo 1 > /sys/power/pm_debug_messages # why would you ever want to not syslog it??
echo 0 > /sys/power/pm_async
Cat /sys/power/pm_wakeup_irq may tell you something about whomst is responsible for sleep failure. Anyways, suspend is the worst thing to diagnose good luck.
The simplest way to opt out is to "install any other OS instead".