Honestly I’ve found the opposite of what you said, where on Debian based distros I commonly had to go to a project’s git repo and follow readme instructions to build when it wasn’t in an apt repository. Meanwhile on arch, the only thing you have to install manually is yay and then afterwards everything is in the AUR. Not saying that makes arch more user friendly than Debian (obviously), but that one aspect I do actually find easier on arch at least if you’re willing to use an AUR helper.

I don’t think I’d call it anything wrong, but the subvolumes definitely do make it different for installation purposes so that following ext4 instructions for bootloader configs or kernel arguments could put you on the wrong path

Some desktop environments (plasma 6 at least) support it when running in Wayland - my daily driver for months has been an HDR setup (with a nvidia gpu, even) and it’s been great. It’s not quite ready for non-technical users, but imo it’s not far off and I can’t wait for it to be more common.

Yea as opposed to the windows method of “just open regedit and navigate 8 folders below HKEY_CURRENT_USER to change some ambiguous system variable in hex” lmao

I’ll take editing a text file in /etc/ for my configuration any day

Never thought I’d have to give the Texas government credit for anything tbh, but I’m glad to be wrong. Now if they wanna keep this momentum going and repeal all the awful dehumanizing laws they’ve passed recently, maybe I’d even start to respect them lmao

Yes but like it or not, it’s a threeway with zuck

I remember being able to figure out a solution with the kwin docs and dfeet for introspection, but it was a while ago and my memory is less than stellar lol. I ended up running all my window-related logic in the kwin script (js) and just using python+dbus to see if the script had been injected and do it if not. If you go the same route (though the python is unnecessary this way if you aren’t using it for something else, like running one of the windows you wanna manipulate) the workspace global variable stores all windows in stackingOrder, so looping through that list (for (window of workspace.stackingOrder) {…}) is an easy way to check each window. I definitely remember docs on the workspace/windows part, but tbh I think I just introspected with the jsconsole.log and the log kwin prints it to (journalctl maybe?). Sorry I don’t remember more about the process, I got into the kwin scripting for all of an hour cuz of the Wayland regression of not being able to control your own window’s size/position in qt so it was a bit of a hack fix I haven’t had to think about since.

I’ve had good luck interfacing with KDE windows using dbus in python, although if I remember right the more granular control also required javascript (still passed thru dbus with python). The only python library I needed was Qt (for their dbus implementation because I was already using their event loop, but any other lightweight dbus package should work fine).

In Canada we have Kijiji, which is… not perfect for privacy, but at least it’s not facebook

Wow apparently I missed that whole launch, thank you for the correction

I don’t know how far down the line that upgrade might be, but I’ve recently used both a 1080 and the latest-gen (see reply below) an AMD igpu (7600x) and I gotta say the 1080 is still significantly more powerful. Maybe if the upgrade is soon hold off on selling the 1080 until you see if you’re satisfied with the igpu performance?

I ran it (bg3.exe) through the latest vanilla proton (9.0.1 I think?) earlier today and it had no issues. I used the experimental version for character creation and it had some fucked up textures (color banding mostly), but after switching it ran perfectly in the stable version. I’m running thru steam on a nvidia gpu, so hopefully on amd you’ll be fine if you try that.