Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

android.googlesource.com

Post reply on HN
Print view View original

301–310 of 393 posts

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#301

Post by vlang1dot0 »

fouric wrote: post #248
kllrnohj wrote: post #89

Earlier quoted context omitted.

Zig is too uninteresting to eclipse anything. It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D). It doesn't offer much to justify switching costs. If C++11 had never happened then maybe Zig would attract the…

> Zig is too uninteresting to eclipse anything. As someone who knows C and not Zig, Zig is very interesting. It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those. Also, as Python illustrated, a language doesn't have to be interesting to be popular. As Python a…

> It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those.

Rust has all of those except in place binary patching and fast compile times.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#302

Post by toast0 »

IshKebab wrote: post #299
toast0 wrote: post #108

Earlier quoted context omitted.

The third half is the bluetooth firmware on the other device. The fourth half is the other firmwares on the other device. The fifth half is the specification(s). The sixth half is the RF environment.

But those are the same for iOS, yet Bluetooth on iOS is far better than on Android.

A lot of people using Apple Bluetooth hosts use them with Apple Bluetooth devices (other hosts, mice, keyboard, headphones, etc)

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#303

Post by [deleted] »

mrpippy wrote: post #243
cptskippy wrote: post #229

Earlier quoted context omitted.

> Serious question, why doesn't Google build its own bluetooth & BLE chips? There is a lot of overlap between WiFi and Bluetooth & BLE such that you just have a Wireless chip that does both. In fact I think with Bluetooth 4 the file transfer profile just establishes an adhoc WiFi network. You don't have separate Bluetooth and WiFi chips anymore. Furthering that, in the mobile space the Wireless capabilities are usual…

> In fact I think with Bluetooth 4 the file transfer profile just establishes an adhoc WiFi network. This was a feature of Bluetooth 3.0, but almost nothing ever used it. I was once at a big BT testing company and asked about it, and they had like one device that could do it (a crazy feature-packed HTC WinMo device I think). And then Bluetooth 4.0 added BLE, and it seems like there hasn't been much development of cla…

[deleted]

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#304

Post by PragmaticPulp »

nahuel0x wrote: post #61

Fuchsia network stack is also being rewritten from Go to Rust [1] and it follows a functional core/imperative shell pattern, something very unusual in network stacks [2]: [1] https://fuchsia.dev/fuchsia-src/contribute/contributing_to_n... [2] https://cs.opensource.google/fuchsia/fuchsia/+/master:src/co...

> Fuchsia network stack is also being rewritten from Go to Rust

This Android Bluetooth stack is mostly in C++. Only part of it (about 4K lines) is written with Rust.

The headline is misleading.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#305

Post by GeekyBear »

signal11 wrote: post #269
GeekyBear wrote: post #258

Earlier quoted context omitted.

> If someone senior at Samsung said to their vendor "good Bluetooth or you lose the Samsung account", that would provoke some, um, intense conversations at the vendor between sales and engineering. The same thing could be said for Qualcomm's failure to support it's SOCs for more than a couple of years. Device makers could force their hand.

> support it's SOCs for more than a couple of years That works, even works well, as long as device makers feel that supporting SOCs for a limited period helps them sell more phones. Apple has changed the rules of the game by supporting its devices for longer -- and as phone upgrades become more infrequent due to plateauing technology, I think device makers will realize this. Samsung has already committed to supportin…

Any movement on the Android side is helpful and hopefully Samsung can shame Google into following suit.

However, if we're going to count years where you only got a security update, the iPhone 5s is currently on it's 8th supported year.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#306

Post by 05 »

oriolid wrote: post #267
05 wrote: post #251

Earlier quoted context omitted.

Doesn't kill it permanently; there's a fix involving connecting a CSR 2.0 dongle. There's also a workaround that sets an nvram var. Overall it's an absolute clusterfuck, though, because Apple still haven't fixed the problem.

The workaround with nvram doesn't work if you already made the mistake of plugging in the CSR dongle. I don't know about the fix with CSR 2.0 dongle, it seems that nobody's selling them any more. Could work, could be an urban legend like all the reported fixes with nvram and pram resets and restoring various files.

I can confirm the 2.0 BT dongle fix works because I had that exact issue and that's how I fixed it. Of course, I still made Apple replace the laptop (was less than 2 weeks old), but doesn't really seem like they've noticed seeing how it's still not patched almost a year later.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#307

Post by azernik »

eecc wrote: post #274
realityking wrote: post #238

Earlier quoted context omitted.

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.

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?

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 written with Rust

#308

Post by kllrnohj »

fouric wrote: post #248
kllrnohj wrote: post #89

Earlier quoted context omitted.

Zig is too uninteresting to eclipse anything. It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D). It doesn't offer much to justify switching costs. If C++11 had never happened then maybe Zig would attract the…

> Zig is too uninteresting to eclipse anything. As someone who knows C and not Zig, Zig is very interesting. It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those. Also, as Python illustrated, a language doesn't have to be interesting to be popular. As Python a…

> Also, as Python illustrated, a language doesn't have to be interesting to be popular.

Python was very interesting, or rather, Python is the thing in its interesting group that survived. Highly flexible scripting language with a "batteries included" library set is a very compelling sales pitch, even today. It was Perl but readable, and in this case simply being "readable" was interesting enough to cause it to win out (and also Perl's internal drama)

> As Python also illustrated, a language can be opinionated and popular.

Python's "style guide" is opinionated, but Python the language itself isn't that opinionated. Missing ++ & -- are about the only contentious "opinionated" aspects to it. You can fiddle with basically everything else however you want, though, and the language made adjustments to make that even more possible (eg, replacing the print keyword with the overridable print() function).

Critically Python's standard library didn't really get any special treatment from the language. When a language lets the standard library or builtins do things that you can't, that's when it gets really questionable.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#309

Post by mcshicks »

qbasic_forever wrote: post #161
mondoshawan wrote: post #37

Earlier quoted context omitted.

On Glass, we actually went to Broadcom and had them on the ropes for fixing parts of their firmware. Sadly, we couldn't bring those fixes out of the closed source world of hardware, so it's still up to the system integrator to fight those battles...

Serious question, why doesn't Google build its own bluetooth & BLE chips? Please put some competition on Broadcoam and the like and either push them entirely out of the market (good riddance), or force them to step up their game.

Getting good yield/performance on the radio is non trivial. Aside from having domain experts you have a pretty significant investment in equipment to do the testing. Broadcom and other semis split that cost over many customers.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#310

Post by conradev »

mondoshawan wrote: post #174
qbasic_forever wrote: post #161

Earlier quoted context omitted.

Serious question, why doesn't Google build its own bluetooth & BLE chips? Please put some competition on Broadcoam and the like and either push them entirely out of the market (good riddance), or force them to step up their game.

I can't speak to this directly because of numerous reasons, chiefly among them being that I don't get to make those decisions. Standard disclaimer follows: I rejoined in the last two years, what follows are my opinions, these opinions are my own, blah blah. Android has never been about driving the hardware narrative -- it's always been about building a phone with mostly open contributions and driving the start of a w…

> Android has never been about driving the hardware narrative

Apple has been building its own hardware from the beginning, but still also uses Broadcom chips.

Post reply on HN