I don’t use Bluetooth a whole lot on my Linux box (Arch Linux 20231128, MATE Desktop Environment, bluetoothd, pulseaudio). That said, I have blueman-manager in my system tray all the time, and it seems to do a decent job of managing two pairs of headphones (they’re there, and I use them occasionally, just not often). The thing that seems to work for me is to use pavucontrol (PulseAudio Volume Control) to set the parameters of the Bluetooth headphones while they’re active and associated, and those settings are stored for later. That way, when I’m wearing a pair of those headphones my laptop’s speakers are automatically muted, the Bluetooth headphones go back to where I had them before, and whatever I happen to be playing back through (Firefox, vlc, whatever) automatically cut over to them and away from the (now muted) speakers).
I guess I just did it one step at a time - get bluetooth turned on, get a pair of headphones associated with them, then turn off speakers, then… I iterated on it until I had something that worked.
Minimal risk for them. The state of monitoring as a whole is such that they can use such an 0-day for a couple of years before anybody notices it. It’s far more likely that the vulnerability is noticed and patched without anyone even realizing that it’s been actively exploited.
No, I don’t. My best informed guess is that the wifi connection’s state machine gets stuck once in a while, it misses a couple of packets, and then sits there doing nothing. So, by kicking it a little it doesn’t get a chance to freeze up.