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

251–260 of 393 posts

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

#251

Post by 05 »

oriolid wrote: post #106
coob wrote: post #85

Earlier quoted context omitted.

Honestly sounds like faulty hardware or interference.

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.

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

#252

Post by gameswithgo »

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 won't dis-allow any correct programs, zig would compile faster, and zig does appear to be simpler even though in principle you could come across specific zig programs that aren't simple due to doing crazy metaprogramming.

If I imagine a world where Zig is 1.0, and has the same tooling/ecosystem as Rust, and I want to make a single player game from scratch, I would probably pick Zig over Rust, and Zig over C or C++.

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

#253

Post by andoriyu »

ttt0 wrote: post #138
nerpderp82 wrote: post #62

Earlier quoted context omitted.

And it doesn't have memory safety. Zig is really fun and it is excellent for small wasm modules, but until it gets memory safety it will never be a Rust alternative.

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?

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

#254

Post by gameswithgo »

geraneum wrote: post #241
gameswithgo wrote: post #54

Earlier quoted context omitted.

I think Zig could end up being much more popular for domains where Rust's safety and correctness features are less important. Something like a bluetooth stack is exactly where Rust is ideal though imho. Some for crypto libs.

I believe the number of domains which benefit from Rust’s safety features combined with its runtime performance are vast. IoT, hardware drivers, autonomous systems, embedded systems, (cars, drones) infrastructure, etc. I would choose Rust in these scenarios if I have choice. I understand that the language has a steeper learning curve but it’s an upfront cost compared to C (or Zig?) where you have to put even more eff…

I think of Zig as a quarter step between C and Rust. You don't get memory safety, but you DO get better handling of undefined behavior, and option types, and better protection from array bounds overruns.

So like a single player video game, it might be an easier overall choice, in a hypothetical world where ecosystems are similarly fleshed out.

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

#255

Post by ay »

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.

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.

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

#256

Post by Lammy »

Infinitesimus wrote: post #242
kungito wrote: post #226

Earlier quoted context omitted.

Google throws money at problems which don't generate revenue all the time. I feel like all it takes is someone inside Google with enough leverage to push it through without the thing having to make business sense

That could work but the other side of that coin is: if it stops making financial sense Google will do the responsible thing and end it. "Your BT hardware's software is no longer supported" will do more damage to the problem they're trying to solve here

I’ve already had Android phones that didn’t get more than a single major update where the BT/WiFi blobs were locked to some ancient kernel.

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

#257

Post by est31 »

cultyyy123 wrote: post #232
ModernMech wrote: post #217

Earlier quoted context omitted.

> "new" and "delete" considered as bad practices. Depending on what kind of work you do, you may not have a choice as to whether you get to you smart pointers or not. Our students go into work with decades-old codebases littered with new and delete. They need to know what they do. > You claimed that you don't have to teach Manual Memory management in Rust so why not do the same for C++? Because there are no old rust…

I have worked with decades old codebases. I use up-to-date compiler where you get to use smart pointers and all the Modern C++ features. It's your fault if you not teach them how to upgrade the compiler. There is zero risk when compiling C++98 with C++11. It's also student fault if he selects a company with C++98 codebase. The student shall do due diligence. It's my advice for you to teach the Modern C++ before drivi…

Have you coded on larger code bases not written by you? Usually most of the time you read code instead of writing it. Sure you can add new code that adds smart pointers, but you still have to understand the exant code, at least to some degree.

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

#258

Post by GeekyBear »

signal11 wrote: post #116
cogman10 wrote: post #92

Earlier quoted context omitted.

I'd imagine lots of reasons. Apple has the hardware guys to design whatever chip they need. They also have a mountain of reserve capital (Something like $1 trillion I believe?). Further, Apple's closed ecosystem means that if you want them to sell them your hardware you have to conform to their standards. With Samsung and android, it's a different story. There are many android vendors and the people producing the Blu…

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.

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

#259

Post by parwan98 »

ed25519FUUU wrote: post #149
parwan98 wrote: post #55

Earlier quoted context omitted.

Correct. It's a small table of: address1, 4 bytes overlay data address2, 4 bytes overlay data etc The data is overlayed over the specified addresses, in runtime. On some chips its 8 bytes instead of 4. On a typical Broadcom/Cypress chip you have 128 or 256 entries. By the time the chip is 2-3 years in the market and still getting firmware updates, ~98% of them are used by existing firmware, so there are only 5-10 fre…

> Case in point: the Broadcom/Cypress BCM43455 chip on the raspberry pi is almost out of patch entries. Broadcom have switched to their usual tactic of stalling for years on known, reproducible bug reports. And it's still really buggy. I had to write a service on the RPI and the only way to reliably connect was to restart bluetooth before every attempt. That kind of fix makes a person feel dirty.

Sadly that's common in the hardware world.

Step 1. Have a reliable hardware watchdog that restarts everytime there's a software problem.

Step 2. There is no step 2.

Post reply on HN