I do not know of any such dongle, but I'd like to ask you a question if you don't mind: are you looking for a dongle with open-source firmware, or would a dongle that has its (proprietary) firmware stored in some onboard memory be acceptable?
The second option wouldn't require you to install any proprietary firmware on your computer, but you'd still rely on the proprietary firmware for the device to run. And it might also exist, unlike a dongle with FOSS firmware.
Maybe developers will finally start implementing predictive back now that it's not hidden behind developer options. It's kinda nice when you can just peek at where the app wants to take you when you go back, and it currently ironically tends to be implemented only by apps that already have decently made navigation.
Also private space seems nice, finally a way to use the work profile sandbox natively without having to install third party apps that pretend to be work profile managers.
Not familiar with the API, and I'm not entirely sure if it's not just a bug in Eternity (fork of Infinity), but lemmy.one doesn't have downvotes and I don't get the option to downvote anywhere.
How is it open source?
How is it not? Open source doesn't mean you have to accept other people's code. And it is perfectly valid to only dump code for every release, even some GNU projects (like GCC) used to work that way. Hell, there's even a book about the two different approaches in open source.
So whatever benefit you were hoping to get from Nvidia's kernel modules being open source probably is not there.
It allowed the actual in-tree nouveau kernel module to take the code for interacting with the GSP firmware to allow changing GPU clock speed - in other words no more being stuck on the lowest possible frequency like with the GTX 10 series cards. Seems like a pretty decent benefit to me.
xrandr is Xorg only, it doesn't work with Wayland. You should be able to make SDDM use your Plasma display configuration - https://wiki.archlinux.org/title/SDDM#Match_Plasma_display_configuration
No clue if that's going to fix your issues, but at least it's supposed to work with Wayland.
Also, the Arch repos are pretty much just an "AUR with binaries" - they contain the same PKGBUILD files used by AUR packages, because that's how Arch packages are built. So you can just download an Arch package PKGBUILD, modify it however you wish, and then build and install it.
If it is an Arch-based distro (sorry, I don't recognize the package manager), then this might just be the recent Wine update that made it 700 MB smaller (which would mean the rest of your system grew 300 MB)
I made a post here about it: this one
Btw, is there a way to link to a post in a way that resolves on everyone's separate instance instead of hard coding it to my instance?
Ah, thank you, I didn't realize there is a package archive I could check for size history
See? Hidden in an image, clearly that's steganography! /s
Oh sorry, I understood your comment as saying that you couldn't get weather info with GadgetBridge because of its somewhat unique architecture. If you're using a different companion app then apps for GadgetBridge probably won't work.
Also I'm not familiar with Pebble, I'm just assuming it works similarly to other GadgetBridge-supported watches / bands like the Mi Band I use.
GadgetBridge is not really against supporting online-only functions, it just can't be part of the main app. Weather Providers is what you're looking for.
Yeah, that same website says there are 4.8k "new" users here, so it doesn't add up.
*removed externally hosted image*
Not really - report your issue on their issue tracker if you can and feel like spending your time on it, then move on (and maybe check back in some time). Flatpak are meant to fix dependency issues, there's not much you can do if they got it wrong for whatever reason.
If it's a Flatpak, then installing anything with APT shouldn't help you at all - it is possible to build a Flatpak that accesses host libraries, but it would defeat the point of using Flatpak in the first place. So your xapp issues are moot anyway.
As to the meaning of the output of apt policy: it says that the most up to date libxapp1 is from Linux Mint repos, and that there's also an older version in Ubuntu repos. That means that Linux Mint doesn't provide a xapp package at all, and the only one you could install is the old one from Ubuntu (which conflicts with the newer libxapp1 from LM)
The APT error is most likely a result of using PPAs - some PPA you use (probably the one with simple64) provides libxapp1 2.8, but doesn't provide happy at all, so you end up falling back to the much older version from your distro's repositories. But xapp needs an exact version of libxapp1, so you get this error.
That said, if the simple64 PPA doesn't provide the xapp package, then it perhaps isn't required and the module should be provided by libxapp1 (and the problem is something different). Or maybe it comes from a completely different PPA - I believe apt policy libxapp1 should tell you where it's coming from.
To be fair, giving a company that's been failing to get themed icons to work on Android for almost four years now less than a month to make a significant change to a core part of their software is... quite weird?
Like, the EU usually gives companies at least half a year to comply with smaller demands than this, because companies with such a huge bureaucracy load wouldn't even be able to change an app logo in such a short amount of time.