News for hackers. Stuff that matters.
Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by realityking on Wednesday March 31, 2021 @02:47PM (#26651337)
I don’t follow the leap. The grandparent’s point was about the quality and terrible lack of long term support of Broadcom chips. How does that translate to issues of the standard itself?

Nobody would complaining about Apple creating their own radio chips (which they seem to plan for 5G/6G). Apple creating their own standard protocols is an issue though.

Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by eecc on Wednesday March 31, 2021 @04:19PM (#26652582)
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?

Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by azernik on Wednesday March 31, 2021 @06:08PM (#26653774)
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.

Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by eecc on Thursday April 01, 2021 @07:24AM (#26659054)
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?
Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by azernik on Thursday April 01, 2021 @04:53PM (#26665879)
"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.

Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by eecc on Friday April 02, 2021 @01:51PM (#26673860)
Fine, but you're rationalizing living with poor execution. I'm rationalizing with deep (perhaps goldplating) correctness.
Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by azernik on Friday April 02, 2021 @09:14PM (#26677583)
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?