4 ms·

Well, if the implementations of the standard are such a garbage fire what's the point chasing them? Just to check the box "standards compliant" and likely provi

by eecc 6y ago

Well, if the implementations of the standard are such a garbage fire what's the point chasing them? Just to check the box "standards compliant" and likely providing an abysmal UX and poor interoperability? I fixated on Apple because they're often picked on for taking the highway, but on the other hand what's the point doing otherwise? What's a common ground if it's just a pipe dream?

azernik 6y ago
Just because a chip is shitty doesn't mean it's worthless. In practice, Bluetooth is quite interoperable, and reliable enough for many use cases (especially the common, better-tested ones). Breaking compatibility with that ecosystem out of spite is not conducive to getting adoption for a better product.
- eecc 6y ago
  Well, the original posts report some frankly tragic scenarios - so bad that they “reboot to initialize” just to keep sane - in what are some pretty ubiquitous devices. Or not?
  - azernik 6y ago
    "Reboot to initialize" is ugly as hell and very brittle, but it's good enough for most I/O devices like keyboards or headphones. If the kernel is able to properly reinitialize the chip with all of its old association information, it might even be indistinguishable from a few hundred ms of interference. (Rebooting on errors is in fact quite common for all kinds of hardware in high-radiation environments, and is a pretty standard kernel technique for working around buggy hardware.) Now, of course, multiple nines of uptime would be very nice to have (and open up new use-cases), but 2-3 nines is still a lot better than 0.
    - eecc 6y ago
      Fine, but you're rationalizing living with poor execution. I'm rationalizing with deep (perhaps goldplating) correctness.
      - azernik 6y ago
        I'm not "rationalizing", and neither are you. You're arguing that it's not enough to make a correct implementation, but that it's also important to break compatibility with incorrect implementations. I'm arguing that a better implementation that is compatible with current protocols is strictly better than a better implementation that is not Bluetooth-compatible. If you make a piece of hardware that is good (e.g. doesn't randomly crash and need to be rebooted by the kernel), why is it a bad thing for it to try to connect to some flaky BT headset?

by eecc 6y ago

azernik 6y ago

Just because a chip is shitty doesn't mean it's worthless. In practice, Bluetooth is quite interoperable, and reliable enough for many use cases (especially the common, better-tested ones). Breaking compatibility with that ecosystem out of spite is not conducive to getting adoption for a better product.

eecc 6y ago
Well, the original posts report some frankly tragic scenarios - so bad that they “reboot to initialize” just to keep sane - in what are some pretty ubiquitous devices. Or not?
- azernik 6y ago
  "Reboot to initialize" is ugly as hell and very brittle, but it's good enough for most I/O devices like keyboards or headphones. If the kernel is able to properly reinitialize the chip with all of its old association information, it might even be indistinguishable from a few hundred ms of interference. (Rebooting on errors is in fact quite common for all kinds of hardware in high-radiation environments, and is a pretty standard kernel technique for working around buggy hardware.) Now, of course, multiple nines of uptime would be very nice to have (and open up new use-cases), but 2-3 nines is still a lot better than 0.
  - eecc 6y ago
    Fine, but you're rationalizing living with poor execution. I'm rationalizing with deep (perhaps goldplating) correctness.
    - azernik 6y ago
      I'm not "rationalizing", and neither are you. You're arguing that it's not enough to make a correct implementation, but that it's also important to break compatibility with incorrect implementations. I'm arguing that a better implementation that is compatible with current protocols is strictly better than a better implementation that is not Bluetooth-compatible. If you make a piece of hardware that is good (e.g. doesn't randomly crash and need to be rebooted by the kernel), why is it a bad thing for it to try to connect to some flaky BT headset?