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

261–270 of 393 posts

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

#261

Post by est31 »

PragmaticPulp wrote: post #128
stagger87 wrote: post #27

If you go into the parent directory, what appears to be the main Gabeldorsh directory, most of the implementation appears to be written in C++. Is the project being slowly rewritten in Rust? Or are only parts of it written in Rust?

I’m not finding much Rust BlueTooth Stack code in the link. There are only about 4K lines of Rust in here. Am I missing something? Or is the headline exaggerated?

The headline is technically correct. "rewrite with Rust" means there is Rust inside, but it doesn't mean that it's all (or mostly) Rust. But given the way one commonly understands the headline, it's definitely misleading.

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

#262

Post by parwan98 »

ay wrote: post #255
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.

Tangential - in the BLE land nrf52832 and friends are pretty neat, and there is an ongoing work on the rust stack: https://github.com/jonas-schievink/rubble I tried it and it can do a few basic things, though it’s in the early stages, apparently.

Nrf52 are great BLE chips, however the full bluetooth spec (classic+BLE) is orders of magnitude more complex...

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

#263

Post by kristoff_it »

kllrnohj wrote: post #244
nicoburns wrote: post #118

Earlier quoted context omitted.

> It's not better-enough to motivate switching away from C in places where C is still used I suspect zig will eventually fill this niche. Proper arrays and strings and better compile time execution support while still being a small, simple, explicit language are quite significant improvements on C.

But why wouldn't I use Rust in those scenarios, which gives me even more safety & compile-time bug checking? Zig isn't actually a small or simple language, after all, that's just marketing bullshit. Manual, mostly unassisted memory management isn't simple, and compile time evaluation & reflection isn't small. It keeps making claims about being simpler because it doesn't have macros or metaprogramming, but that's incr…

> Zig isn't actually a small or simple language, after all, that's just marketing bullshit. Manual, mostly unassisted memory management isn't simple, and compile time evaluation & reflection isn't small. It keeps making claims about being simpler because it doesn't have macros or metaprogramming, but that's incredibly deceptive at best since it does have compile-time code generation (aka, metaprogramming).

As VP of marketing bullshit I recommend you double check your source of information as we never claimed that Zig has no metaprogramming, in fact comptime is mentioned on the front page of the official Zig website and the codesample on the right of it shows comptime metaprogramming too.

That said, is you need something stable today, then Rust is undoubtedly the better choice.

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

#264

Post by reader_mode »

kllrnohj wrote: post #234
reader_mode wrote: post #185

Earlier quoted context omitted.

> 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). I've been interested in D since the early days (back when it had two competing standard libraries) - I think you're kind of misrepresenting why D never ca…

> If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction. D themselves did that, that's what I was referring to: https://dlang.org/spec/betterc.html

This happened recently (in D timeframe) and is still a hack that basically creates a different language that's a subset of D - which is the dirtiest way to fix an initial design mistake. If D came out as betterc from the go I guarantee you the adoption would have been much better - this way you're stuck with legacy decisions of a language that was never really that popular to begin with (unlike C - C++ story).

Also back when it launched LLVM wasn't really a thing (GCC was probably the closest thing to having a portable backend but it wasn't nearly as clear cut especially with the licensing and all that anti-extensibility attitude), and D having it's own custom backend was also an issue.

I applaud the effort but at this point I think it will never get mainstream popularity like Rust. I'm sure it's useful to people but it had it's time in the spotlight, I don't see how they get the momentum shift.

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

#265

Post by Daho0n »

Razengan wrote: post #213
akersten wrote: post #18

This is great news. Hopefully it fixes a lot of the jank that I've always experienced with Android Bluetooth. I don't think I've ever had a smooth experience - even with a supposedly flagship device (Pixel 4a!) I've encountered all of the following problems: * Devices getting stuck at max volume (thankfully not headphones) * Devices getting stuck at really low volumes * Devices randomly switching between absolute vol…

Shit like that is why I always wondered where all the claims of Android being superior to iOS came from.

One isn't better than the other. This thread itself is full of people saying the same shit about both android and iOS.

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

#266

Post by V-2 »

boromisp wrote: post #215
oriolid wrote: post #99

Earlier quoted context omitted.

It's because Samsung can get away with selling total garbage. I work on an audio-related app, and a huge majority of the hacks in the app to work around bugs in phones are for different Samsung models. Still more than half of our users keep buying them.

Are Samsung devices buggier than other android brands, or just so much more popular within your userbase, that more bugs surface?

My impression as an Android developer (not backed by any systemic research, just personal experience) is that Samsung feels less bound by the platform standards because - due to their large market share - they can simply get away with it.

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

#267

Post by oriolid »

05 wrote: post #251
oriolid wrote: post #106

Earlier quoted context omitted.

There's something odd about the 2019 MBP Bluetooth hardware. The most interesting part is that just plugging in a Cambridge Silicon -based USB dongle can kill it permanently: https://discussions.apple.com/thread/250944058

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.

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

#268

Post by oriolid »

boromisp wrote: post #215
oriolid wrote: post #99

Earlier quoted context omitted.

It's because Samsung can get away with selling total garbage. I work on an audio-related app, and a huge majority of the hacks in the app to work around bugs in phones are for different Samsung models. Still more than half of our users keep buying them.

Are Samsung devices buggier than other android brands, or just so much more popular within your userbase, that more bugs surface?

It's something like 50% of user base and >75% of device-specific bugs.

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

#269

Post by signal11 »

GeekyBear wrote: post #258
signal11 wrote: post #116

Earlier quoted context omitted.

I get what you're saying, but Samsung is also huge and Bluetooth is used in lots of electronics that Samsung sells -- including laptops, tablets, smart watches, TVs... or conceivably could sell, like future IoT products. 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. Inc…

> 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 supporting recent Galaxy devices for at least 4 years -- at least with security updates[1]. I suspect this was also because they found that their extremely short-sighted prior policy re security updates encouraged corporate phone procurers to ditch Samsung and go with Apple.

[1] https://www.theverge.com/2021/2/22/22295639/samsung-galaxy-d...

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

#270

Post by ttt0 »

andoriyu wrote: post #253
ttt0 wrote: post #138

Earlier quoted context omitted.

C++ doesn't have "memory safety" and it is a Rust alternative. Stop being pretentious, not every language has to have Rust's borrow checker or whatever its called.

But C++ does have opt-in memory safety via smart pointers and RAII. It's not preventing all the bug types hat rust will, but it is. There is also tons of code written without it, but you get the idea. Zig misses a lot of futures that modern C++ has without offering anything in return. Yeah, it's easy to learn compared to C++ and Rust, but what the point of learning it if doesn't offer anything new?

I agree, but nothing short of borrow checker is considered memory safety to Rust advocates and they probably think that we segfault at least 10 times an hour with use-after-free's, double-free's and buffer overflows.

I don't think Zig is meant to replace C++. It's a cool language on its own.

By the way, you've been shadowbanned if you haven't noticed it yet.

Post reply on HN