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

211–220 of 393 posts

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

#211

Post by vardump »

acdha wrote: post #203
vardump wrote: post #187

Earlier quoted context omitted.

As a long time Apple user, I really don't know where that's coming from. Endless issues with bluetooth over the years, including full system crashes. Curiously iOS bluetooth stack seems to be more stable than on macOS. Or maybe it's just hardware differences. Apple's stack does work great with Apples hardware, though.

How many hardware devices are you talking about? That's very different than what I've seen personally or peripheral to enterprise support.

Well, at least Magic Trackpad, Keyboard etc. work really well with a Mac. Never had any issues.

Bose bluetooth headphones, third party "high end" bluetooth devices... not so great. Lately it's been better, though.

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

#212

Post by blep-arsh »

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…

Hah, I've experienced the absolute/relative volume bug. Sony headphones sometimes end up connecting with independent (relative?) volume controls and then switching the volume control from independent to absolute when you use a track skip gesture. The volume goes to the max instantly as a result. One of the reasons I'm staying away from wireless Sony headphones.

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

#213

Post by Razengan »

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.

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

#214

Post by TinkersW »

johnnycerberus wrote: post #194
TinkersW wrote: post #183

Earlier quoted context omitted.

I use operator overloading in C++ all the time, you seem to be looking at it from a data science perspective, but other fields use math also, such as gamedev.

I would have imagined that in game dev you prototype first with a high level language and then you would write the math code. How much of game dev is actually math code, aside from critical components like rendering, physics, etc.?

No that is not how it is done, the math is written directly in C++.

If you have fast iterative build times, lots of assertions, and good debugger there is no reason to waste time writing it in another language first.

Almost every system uses basic vectors and matrices/quats, most gameplay code also uses them etc.

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

#215

Post by boromisp »

oriolid wrote: post #99
est31 wrote: post #83

Earlier quoted context omitted.

> The buying power that Apple has for designing in a particular chip is much bigger than any individual Android manufacturer (even Samsung) Why does Samsung have smaller buying power than Apple? Doesn't Samsung sell more phones than them? Or is it because while Samsung sells more phones in total, Apple still has the most successful single models?

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?

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

#217

Post by ModernMech »

cultyyy123 wrote: post #200
ModernMech wrote: post #173

Earlier quoted context omitted.

You still need to teach what the delete keyword is and how memory management works in C++. There's tons of code out there not written with smart pointers. And yes we use valgrind, but it's important not to overload students who are new to programming. Students tend to reach for withdrawal forms when you tell them "I see you are overwhelmed by this new tool you're learning. To solve this problem here's a new tool to l…

"new" and "delete" considered as bad practices. You claimed that you don't have to teach Manual Memory management in Rust so why not do the same for C++? "Rust makes all of this go away. They don't have to manage their memory manually" Both C++ and Rust has manual memory management but rarely needed. Both supports RAII where everything managed automatically.

> "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 codebases where manual memory management is an issue.

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

#218

Post by eecc »

parwan98 wrote: post #55
kevincox wrote: post #36

Earlier quoted context omitted.

Do you have any more info about ROM patch slots? I have never heard of this before. I assume this is a small amount of r/w memory that is somehow overlaid over specific locations in the ROM?

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…

So given these data points, isn’t it reasonable for Apple to refuse to play along this broken tune and just roll out their own dialect of a wireless protocol? Why, if not in the name of scarcely affirmed “standards”, drag suppliers through an endless contractual game, when you can direct your own capacity toward the quality standards that fit you?

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

#219

Post by dflock »

mschuster91 wrote: post #178
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 problem: There aren't that many suppliers left in the field, and Broadcom knows that their customers are pretty much locked in. The notable exception is once again Apple, they have proven that they can and will go and…

> go and implement the technology on their own

Samsung could obviously do this too, but as you say, they lack the will - and motivation.

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

#220

Post by qbasic_forever »

Waterluvian wrote: post #169
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.

Google's involvement in any kind of hardware is already a distraction from their core product line. Making their own chips is a distraction on a distraction. Distraction might not be the right word but I can't conjure up the right one. Hardware is one of the end goals for Apple, for example. For Google, Android hardware is not. It's just there to serve their goal of selling ads.

IMHO those dynamics are changing. Custom chips are becoming table stakes for new products. Look at Apple M1, W1, or Amazaon's Graviton2 chips. All of those are core parts of products and services which would not be possible without the custom silicon. The pool of talent and resources to build these things is extremely small, and there are geopolitical issues putting ever more pressure and scarcity on them (i.e. China pivoting to reduce dependency on Western designed chips and hoovering up as much chip design talent as possible). The TL;DR is amazing new hardware and services need custom silicon, but custom silicon is only getting more difficult and more challenging to build in the near future.
Post reply on HN