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.

But you see they can sell this! Can’t sell “fallow fields”…

Exactly. At the federal level the U.S. is an oligarchy completely controlled by the Epstein class.

Is it wrong to call out those complying in advance with fascism? I will agitate in any way that sparks debate and encourages people to be more aware of what is at stake. I gain absolutely nothing else, especially on Lemmy… maybe if this was Reddit you could accuse me of being some shill farming karma. But that shit culture doesn’t exist here.

Yes, the PR specifically calls out the laws as the reason for this change. The problem is BOTH the laws getting passed, and corporate interests complying in advance.

If the whole story was the addition of this change with no other context, I’d agree. But if you read the PR description you’ll see its more than that. The laws in question are specifically called out. This suggests that whether or not the legal interpretation of compliance changes (the law could require more than just DOB entry, aka DOB verification with government ID), systemd is planning to comply rather than join the legal battle against these invasive requirements.

https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/

Exactly. This is a massive overreach, and it is crazy that Poettering is even considering merging this.

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.

Of course, no question that with threat modeling you can arrive at /e/OS being an acceptable choice. However threat modeling is difficult and the devil is in the details, which is why I’m responding (mostly for the benefit of other readers of this thread) to provide the GrapheneOS side of things and avoid the impression that /e/OS offers unique or generally superior features in the areas we are discussing.

Here is GrapheneOS’s network location implementation details. https://grapheneos.org/features#network-location

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.

Bravo Michael for continuing to farm bullshit drama with clickbait headlines on the most inane topics like “how my DE handles pasting text”