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.
Even then, not so much. I’ve been tugging on those particular wires, and the overall response seems to be, send a reply once, then ghost you until you’ve forgotten that you asked them. They do nothing during that time, and will probably continue to do nothing well after we forget.
I agree. Some of the Linux servers I used to run at work in the early 00’s were 12 to 16 core monsters (for the time) and the kernel didn’t even blink.
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.