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.

It looks like sometimes folks post the Tumbleweed Monthly update, but its not consistent. You can find it here when it is published https://news.opensuse.org/, and feel free to post it here if you read it 👍

That is correct! Here are some helpful articles

1. More about zypper DUP: https://en.opensuse.org/SDB:Upgrade_Tumbleweed
2. Mention on how to disable KDE plasma updates, although you might want to more thoroughly google for this: https://en.opensuse.org/System_Updates

Also with Tumbleweed there is always the chance of hiccups when upgrading, given that it is bleeding edge. Make sure you know how to use Snapper, and its good to check the openSUSE Matrix channel and forums before upgrading just in case there are any issues; often issues are resolved quickly, so if you see folks discussing an issue just don't update, and wait until the next safe snapshot is released!

Great! I assume that the issue was blacklisting the nouveau driver then. Glad to hear everything worked out, after initial setup I find Tumbleweed to be the most reliable experience with NVIDIA drivers.

Please note if you are new to Tumbleweed that you should always update with zypper dup, nothing else. This also means you should disable automatic updates in gnome (via packagekit) or KDE, as Tumbelweed is most reliable if the entire system "rolls" forward together to the next OS release. Not sure why they aren't configured to be disabled by default, but that's the way it is...

Install the correct "nvidia-compute-utils" package, and then try again. We need to know whether the gpu driver is properly installed, and nvidia-smi is the way to do that

What is the output of nvidia-smi?

https://docs.cryptpad.org/en/admin_guide/index.html

Spent 4 hours on Sunday debugging "SW microcode error" iwlwifi crashes... eventually found some random shit on the Arch forums where you turn a bunch of shit off and it fixes it

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

This is bullshit lmao