Live data from Hacker News

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

android.googlesource.com

221–230 of 393 posts

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

#221
post #20

Why not BlueZ, that everyone else uses? Android feels like the land of Not Invented Here sometimes, to me. There might be good reasons, but often it feels like it's just Google trying to insure Android is as incompatible / different as possible from everything else that runs Linux. It doesn't help that almost none of the ChromeOS / Android subsystems or tools have not made it to any mainstream / regular Linux. They r…

GPL is the problem. Hardware vendors won't touch it with a 10k foot pole because of the requirement to redistribute patches. There's a history of wanting BSD licenses at Android's inception. If the BSD distributions hadn't run into problems relating to legal battles at the time, Android would be built on Mach with a BSD userland rather than Linux. Additionally, there was more vendor support and drivers for the Linux…

> Sadly, for the fledgeling enterprise that was Android, it was better to start from Linux, and use Apache/BSD style licensing and write their own userland.

Curious about your take on this. Why do you think it would be better if Android were mach kernel + BSD userland akin to Mac/IOS instead of Linux?

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

#222
post #105

Earlier quoted context omitted.

Python is way too ad-hoc to be a good teaching language in a professional context. It's designed to teach kids and first-time coders, as an alternative to BASIC.

I think that wholly depends on the context. Python is a great teaching language IMHO if the goal is to teach how to get things done. It's not a good language if you're teaching how things do work under the hood. To me it's the difference between programming and computer science.

[deleted]

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

#223

I know the guy that heads up the team that did this work -- he and I spent 2+ years fighting Broadcom's old, god-awful bluetooth code. Our whole team used to play what-if games about replacing the thing while massive code dumps came in from vendors, making the task ever larger. Zach, if you're reading this, HUGE kudos to holding the line in replacing that, and double kudos for doing it in a verifiable, sane language!

Can you shed some light on what we’re actually looking at here? I see some Rust but most of the actual BT stack looks to be C++ code. Is the HN headline accurate?

Did you miss this on the main page?

> We are missing Rust support in our GN toolchain so we currently build the Rust libraries as a staticlib and link in C++.

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

#224
I have no opinion on this, but a data point:

I had been sticking with an old USB wireless headset for a long time because it Just Worked (tm), but even with a new battery the life wasn't really up to the modern work from home. So I chanced it with a bluetooth noise cancelling headset.

My first experience using bluetooth under Linux in probably a decade. It has been super reliable. I used the CLI tools "bluetooth_ctl", I didn't have a button to click in my i3 setup.

Not saying this rewrite isn't needed, to be clear. But I've been surprised how reliable it's been.

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

#225
post #7

Earlier quoted context omitted.

I really hope it will fare better than NewBlue and BlueDroid... https://www.androidpolice.com/2020/09/14/the-rise-and-fall-o...

NewBlue died because I quit Google. I started that project and was its main motive force.

> NewBlue died because I quit Google. I started that project and was its main motive force.

Unclear why you're being downvoted here -- I seem to remember you, and I definitely remember hearing about NewBlue while we were working on Bluedroid. At the time it wasn't clear what happened. When did you leave?

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

#226

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…

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

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

#227

Earlier quoted context omitted.

NewBlue died because I quit Google. I started that project and was its main motive force.

> NewBlue died because I quit Google. I started that project and was its main motive force. Unclear why you're being downvoted here -- I seem to remember you, and I definitely remember hearing about NewBlue while we were working on Bluedroid. At the time it wasn't clear what happened. When did you leave?

I am also not sure about the downvotes, but c'est la vie. I was dmitrygr@, i left apr 2019

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

#228

Earlier quoted context omitted.

I still find it buggy on my iPhone 12 Pro, as a user at least. Often says 'connected' to my headphones (Sony WH-100XM3's) when it's not, connecting to Alexa devices to stream audio often fails and requires a reboot to connect properly. I can't believe Bluetooth is still such a pain in the bum in 2021.

Buggy Bluetooth on the other end... Alexa is running Linux, and the Sony is probably some custom bluetooth stack. Once you move to all Apple bluetooth, things really smooth out. It seems that Apple does way more testing/validating of their Bluetooth stack.

Eh, I’m still having weird connection issues between my iPhone and OG AirPods. Less than with my old headphones, but more than I’d like

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

#229

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.

> 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 usually integrated into the mobile SoC. So you don't even have separate chips for CPU and Wireless.

About the only time you see a separate Wireless chip is when a new technology is emerging like 5G and it's usually only an external chip for a generation or two until it can be integrated into the SoC.

So, if you were to design your own Bluetooth chip today you would also be designing a WiFi chip and then you'd probably just roll all that into a SoC with a CPU. No small feat.

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

#230
post #176

Earlier quoted context omitted.

Zigs lack of operator overloading means math code will be illegibly gibberish, which kills any possible interest I had in it.

Why would you need operator overloading in a low-level language? It's not like you are gonna write Jupyter notebooks with it. Zig is not meant to replace MATLAB, Python or Julia. I would use it instead to build the backbone of such a data science platform.

How is adding `Duration` to `DateTime` related to jupyter notebook? I use that much more often than element-wise matrix multiplication.
Post reply on HN