Same here. I have three models of Zebra printers and they were all pretty much plug and play with Linux.

+1 to this. Lots of talk in this thread about drivers, but the only driver involved here is the Bluetooth driver. Half of the point of Bluetooth is that peripherals don’t need their own drivers, they just provide various profiles which are standardized so the Bluetooth service can consume those profiles from any device.

Not an expert in this area but I believe the implementation of most of those profiles is user space, so the proper place to be debugging is the Bluetooth service or in pulsesudio. So start your Bluetooth service logs they might give you some idea as to what is going on. Try to get a list of what profiles are supported by your OS and what profiles are supported by the device, maybe the device only supports some newer lossless profile that hasn’t been implemented in Linux yet.

Even with https if you aren’t on TLS 1.3 the SNI (server name indicator) is not encrypted so the hostname you are trying to access would be visible to your ISP.

Forcing your browser to only use TLS1.3 would fix that but who knows how many sites it would break.

The problem is that on top of the pins occasionally not making good contact on these new connectors, Nvidia has been cheaping out on how power is delivered to the card.

They used to have three shunt resistors that the card could use to measure voltage drop. That meant that the six power pins were split into pairs and if any pair did make contact the card could detect it and prevent the card from powering up.

There could be a single pin in each of those pairs not making contact meaning that the remaining pins are being forced to handle double their rated power. It is unlikely that you would lose one pin on each pair so that is an unlikely worst case, but a single pin in a single pair failing could be fairly common.

But on the 40 series they dropped to two shunt resistors. So instead of three pairs, they can only monitor 2x bundles of three wires. Meaning the card can only detect that the plug isn’t plugged in correctly if all three wires in the same bundle are disconnected.

You could theoretically have only two out of six power pins plugged in and the card would think everything is fine. Each of those two remaining pins being forced to handle three times their normal current.

And on the 5090 FE they dropped down to one shunt resistor… So five of the six pins can be disconnected and the card thinks everything is fine, forcing six times the current down a single wire.

https://www.youtube.com/watch?v=kb5YzMoVQyw

So the point of these fused cables is to work around a lack of power monitoring on the card itself with cables that destroy themselves instead of melting the connector on your $2000 GPU.

All of the “snooping” is self contained. You run the network controller either locally on a PC, or on one of their dedicated pieces of hardware (dream machine/cloud key).

All of the devices connect directly to your network controller, no cloud connections. You can have devices outside of your network connected to your network controller (layer 3 adoption), but that requires port forwarding so again it is a direct connection to you.

You can enable cloud access to your network controller’s admin interface which appears to be some sort of reverse tunnel (no port forwarding needed), but it is not required. It does come in handy though.

As far as what “snooping” there is, there is basic client tracking (what IP/mac/hostnames) to show what is connected to your network. The firewall can track basics like bandwidth/throughout, and you can enable deep packet inspection which classifies internet destinations (streaming/Amazon/Netflix sort of categories). I don’t think that classification reaches out to the internet but that probably needs to be confirmed.

All of their devices have an SSH service which you can login to and you have pretty wide access to look around the system. Who knows what the binaries are doing though.

I know some of their WISP (AirMAX) hardware for long distance links has automatic crash reporting built in which is opt out. There is a pop up to let you know when you first login. No mention of that on the normal Unifi hardware, but they might have it running in the background.

I really like their APs and having your entire network in the network controller is really nice for visibility but my preference is to build my own firewall that I have more control over and then Unifi APs for wireless. If I were concerned about the APs giving out data, I know I could cut that off at the firewall easily.

A lot of the Unifi APs can have OpenWRT flashed on them, but the latest Wifi7 APs might be too locked down.