I'm a bit surprised to see that you disagreed with the "NixOS is hard to configure" bit, but then also listed some of the reasons why it can be hard to configure as cons.
By "configure", they probably didn't mean just setting up say, user accounts, which is definitely easy to set up in Nix.
The problems start to arise when you want to use something that isn't in Nixpkgs, or even something that is out of date in Nixpkgs, or using a package from Nixpkgs that then has plugins but said plugin(s) that you want aren't in Nixpkgs.
From my experience with NixOS, I had two software packages break on me that are in Nixpkgs - one of them being critical for work, and I had no clue where to even begin trying to fix the Nixpkg derivation because of how disorganized Nix's docs can be.
Speaking of docs inconsistencies you still have the problem of most users saying you should go with Flakes these days, but it's still technically an experimental feature and so the docs still assume you're not using Flakes...
I was also working on a very simple Rust script, and couldn't get it to properly build due to some problem with the OpenSSL library that one of the dependent crates of my project used.
That was my experience with NixOS after a couple of months. The concept of Nix[OS] is fantastic, but it comes with a heavy cost depending on what you're wanting to do. The community is also great, but even I saw someone who heavily contributes to Nixpkgs mention that a big issue is only a handful of people know how Nixpkgs is properly organized, and that they run behind on PRs / code reviews of Nixpkgs because of it.
I'd still like to try NixOS on say, a server where I could expect it to work better because everything is declarative such as docker containers - but it's going to be a while before I try it on my PC again.
Realistically, a lot of relationships are "situational" (especially at that age) - but that doesn't erase the fact that they existed in the first place.
Correct on all accounts. Just to be more precise, I'm not placing any blame on the players in my prior comments - the blame goes to GFN and Activision since the player expects to be able to play a game that they've paid for, on a service that they have paid for.
Right, I didn't mean to imply that playing on GFN was cheating by any means - I probably should've worded that a bit better.
I meant more of "If Call of Duty explicitly allowed GFN to add the game, then players who play via GFN shouldn't have a chance to be banned just for playing through it"
Doesn't the publisher of the game have to approve for a game to be put on GeForce Now?
I mean, don't get me wrong - I know anti cheat detection has never been perfect, but you'd think this would be something they heavily try to make sure they get right.
No VPN, it's strange because I haven't had a problem with any other services that use IP geolocation (which I assume is what KDE uses) - even Gnome's auto location tool seems to work fine.
Yep, I modded my switch, dumped the keys and my games and went "Now what?" and after playing via Yuzu on my PC I realized this was the only way I really wanted to play the few Switch games I enjoy.
Every now and then I'll boot into the stock firmware to play Mario Kart with some friends when they want to play, and that's it.
Yeah that's what I'm unsure about unfortunately. I'd be very surprised if that disabled Wayland. At one point, there was some remote desktop software that disabled Wayland silently, to get around the security restrictions of Wayland... But this project wouldn't be bound by any Wayland restrictions as far as I can tell.
Hmm, so as long as you have 510 or above on the Nvidia driver you should not be getting blocked by that. I'm unfortunately not sure then.
Perhaps you could try installing sddm which is KDE's display manager (the equivalent of GDM) and see if it shows the Wayland option?
Pretty sure it doesn't require the whole KDE suite, once it's installed run:
sudo systemctl disable gdm && sudo systemctl enable sddm and reboot, then you should get SDDM and can try to change the session type at the bottom left.
Note that when using SDDM, you can't lock your screen in Gnome since that is tied to GDM - you'll get a notification saying that the screen lock isn't available.
If SDDM doesn't show it either, then somehow I think you'd be missing the actual session entry files? Not sure how that would happen though.
Oh wow, I didn't know about Kandalf and KDE valley, that's awesome!
They might've done so out of necessity. I don't know if the dev(s) of the Simple Tools apps were working on it full time, but if they were and just not enough contributions were coming in from it... Well everyone has to eat.
As the saying goes, "everyone has their price". It's easy to condemn the developers for their choice until you're in the exact same scenario as they were. Whether that's because they were starving, or even just offered enough money to make their lives a lot easier - not too many people would turn it down.