Take a look here, it explains more about the specific configuration, such as which subvolumes are automatically snapshotted and include in rollbacks, bootloader integration, etc https://doc.opensuse.org/documentation/tumbleweed/snapper/
Basically there are many details in the setup of btrfs that are needed to get to that level where you can be confident of being able to easily rollback to a previous state. After losing some data on a manually configured btrfs setup on Fedora I went to openSUSE specifically because they have already done all the hard work for you on the btrfs config
This is what openSUSE Tumbleweed is designed to do, although config files in /home require manual setup to include. It allows you to completely rollback if necessary after a system upgrade, allowing you to use a bleeding edge distro without fear of having an unusuable system. If an upgrade goes bad, usual procedure is to roll back to the last btrfs snapshot and just wait for the fix (which usually comes in a couple days to a week, as Tumbleweed advances rather quickly).
openSUSE has a specific btrfs subvolume setup and grub/systemd-boot integration to enable this, which is not too common even today, so it really is a bit special in that you can have this functionality without excessive time spent setting it up manually.
Exactly. At the federal level the U.S. is an oligarchy completely controlled by the Epstein class.
The approver of the pull request does...
Gonna be real with you, I'm not running a password checker tool over unencrypted http. Is this vibe coded?
Brother. You tried to run a repack that was likely developed and tested on Windows, and then got pissed when it didn't work. This is Linux, you downloaded it for free... there is no megacorp surveilling your system and trying to fix every single gaming edge case so that you stay happy while they shove ads in your face.
If you just want gaming and want to stick your head in the sand and stay completely unaware of how your OS works and what it is doing, absolutely stay on Windows. If you have the slightest care about your privacy, desire to learn about how a computer OS works, or are curious about free software, then join us... there are tons of people out there willing to help you.
And I'm sure there is a way to get that repack working... it may just take some research and actually asking questions in the community.
From the official GrapheneOS response to exactly this same debate, it seems that the issue is MicroG's reliance on having signature spoofing enabled. Which is a security hole that can be exploited by anyone, not just MicroG, as it allows anything to masquerade as Google Play Services to an app that wants to use it.
https://discuss.grapheneos.org/d/4290-sandboxed-microg/11
Yes, Google Play Services is closed source and contains functionality that would be considered "spying on the user", and "malicious". But that is the same for any closed source app; you can't prove it isn't trying to spy on you or compromise your device. What you can do is rely on the App sandboxing and fine grained permissions control that GrapheneOS allows to disable such functionality if it exists.
Of course, if even having a closed source app on your device is too much, then honestly you wouldn't even be using MicroG as you wouldn't want any apps using Google's proprietary libraries for accessing Firebase or other proprietary services anyways...
So, GrapheneOS offers the most sane approach in my opinion, without opening any security holes. By default the entire OS (not talking about pixel firmware blobs, just the os and kernel drivers) are open source and you can use only open source Apps via Fdroid, Accrescent, direct with Obtainium, etc. But for the average user enabling sandboxed Google play and managing its permissions is the best compromise between security and privacy.
Actually not bad advice if they are into you badly speaking their language to them at first 😂