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

371–380 of 393 posts

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

#371

Post by pw201 »

rkangel wrote: post #140
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?

I didn't realise that Samsung actually sold more phones than Apple (I've just looked at the numbers and you're right). Apple's smaller set of devices does help them a little but there isn't a lot to choose there. I think my overall point is still valid because I have had Samsung phones for a while and have found their Bluetooth to be pretty good. This is not surprising as Samsung actually bought one of the biggest Bl…

Samsung bought what was advertised as mobile handset business after CSR failed to spot that combo BT/Wifi chips were the future and threw away their lead. Qualcomm got the rest a few years later.

("what was advertised as" because there wasn't really a differentiation in the R&D bits, so there was a somewhat arbitrary split and hasty redacting of repos given to Samsung to avoid names of other customers in comments).

Samsung's phone division and electronic parts division aren't the same thing, so there was no guarantee that the phones would buy the Bluetooth/Wifi from their new acquisition, although I hear they did eventually.

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

#372

Post by dblohm7 »

adkadskhj wrote: post #141
dblohm7 wrote: post #30

Earlier quoted context omitted.

This is a big f'n deal for Android, IMHO

In the "big deal" sense, i'm always curious in what way. Eg is it a source of constant problems? Where not only a rewrite, but specifically a rewrite in Rust, would prevent a lot of issues? Or is it more of a "What if" thing? Ie there's not many problems currently, but the liability is a huge deal? to be clear i work in Rust, use it for all my projects, etc - i'm a fanboy, but i also recognize there's a lot of hype.…

Binder has been the source of a number of Android security vulnerabilities.

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

#373

Post by tedmielczarek »

kllrnohj wrote: post #89
fouric wrote: post #31

Earlier quoted context omitted.

I suspect that Zig will still end up eclipsing Rust - not because it's a "more powerful" language, but because it's much easier to learn. Lower barriers of entry seem to matter more than mere "power" - see Common Lisp's multi-decade feature lead being ignored, and Python leapfrogging other more capable languages (Common Lisp) or equally capable ones that came first (Ruby) due to ease-of-use.

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…

I think Zig is really interesting and has a lot of great ideas, some of which I hope Rust takes inspiration from. They've also done some difficult engineering work to make parts of the development experience feel amazing, like bundling clang and libc implementations for a variety of platforms so that cross-compiling works out-of-the-box. The Zig cross-compiling story is the best I've ever seen of any language, bar none.

That being said, I do think Rust's memory safety story is a game-changer for systems programming. We seem to be in a programming language boom, with lots of new and interesting languages being developed. I hope some of them iterate on the concepts that Rust has developed so we can do even better in the future! I don't think anyone involved in Rust would claim that it's the best we can do, or it solves every problem perfectly.

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

#374

Post by asddubs »

mondoshawan wrote: post #370
asddubs wrote: post #366

Earlier quoted context omitted.

too bad more and more of android was moved into play services over time

It wasn't. Play services is just add on features that proxy app permissions and centralize push notifications -- no actual Android features moved into Play services that I know of. Ie: auto filling SMS OTP codes. It feels like Android is being sucked up that way, but that's because there are a lot of really nice features in there, like push notifications, geofencing, etc. You can still run Android without GMS core an…

one example i can think of without having to look things up is that the music player used to be part of AOSP and then got replaced with a google play variant

e: here's an article from 2018 with some more examples:

https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...

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

#375

Post by oriolid »

iopq wrote: post #363
oriolid wrote: post #162

Earlier quoted context omitted.

> Samsung is in the market of selling cheap hardware I'm not sure about this. There are people who pay >1000€ for their flagship phones and believe them to be premium products, but they are just as buggy as the cheap ones. Huge amount of CPU power and impressive camera specs, though.

I've never had one, can you expound more on this topic? The S21 Ultra seems like a very good purchase from reviews. QHD screen with dynamically adjusted 120Hz seems really like the best spec.

IIRC that model doesn't give apps audio route change notifications when Bluetooth is disconnected, which screws up audio timing. Or something similar, each model has different bugs. But yeah, it doesn't spontaneously catch fire, so on Samsung scale it's good. Reviewers generally don't know about this stuff, because app developers have already worked around it.

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

#376

Post by azernik »

eecc wrote: post #364
azernik wrote: post #307

Earlier quoted context omitted.

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.

Well, the original posts report some frankly tragic scenarios - so bad that they “reboot to initialize” just to keep sane - in what are some pretty ubiquitous devices. Or not?

"Reboot to initialize" is ugly as hell and very brittle, but it's good enough for most I/O devices like keyboards or headphones. If the kernel is able to properly reinitialize the chip with all of its old association information, it might even be indistinguishable from a few hundred ms of interference. (Rebooting on errors is in fact quite common for all kinds of hardware in high-radiation environments, and is a pretty standard kernel technique for working around buggy hardware.)

Now, of course, multiple nines of uptime would be very nice to have (and open up new use-cases), but 2-3 nines is still a lot better than 0.

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

#377

Post by fouric »

pjmlp wrote: post #281
fouric wrote: post #248

Earlier quoted context omitted.

> 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…

Incremental compilation, edit-and-continue are available in Visual C and C++. REPLs do exist for C and C++. Zig security story is hardly much better than using something like Free Pascal, with even less libraries.

> Incremental compilation, edit-and-continue are available in Visual C and C++.

In a particular toolchain not available cross-platform - not comparable to Zig having it available in the reference implementation, which is open-source and cross-platform.

> REPLs do exist for C and C++.

Hacky, nonstandard ones with limitations and altered semantics that aren't included in any of the major IDE's. Not remotely comparable to what's provided with SLIME.

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

#378

Post by fouric »

vlang1dot0 wrote: post #301
fouric wrote: post #248

Earlier quoted context omitted.

> 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.

Rust's "compile-time code execution" is a horrendously complex joke, and it's compile times are so atrociously long that the lack of those two things you mentioned is even worse than in a language like C (with somewhat-sane compilation speed).

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

#379

Post by exikyut »

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…

The real brokenness here seems to be that the chips are not engineered with say ten times the patch capacity.

And the root of the brokenness is that there isn't the end-to-end awareness and acceptance that ten times the capacity is obviously needed.

Owww.

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

#380

Post by exikyut »

mondoshawan wrote: post #370
asddubs wrote: post #366

Earlier quoted context omitted.

too bad more and more of android was moved into play services over time

It wasn't. Play services is just add on features that proxy app permissions and centralize push notifications -- no actual Android features moved into Play services that I know of. Ie: auto filling SMS OTP codes. It feels like Android is being sucked up that way, but that's because there are a lot of really nice features in there, like push notifications, geofencing, etc. You can still run Android without GMS core an…

What would get open-source mapping out of this "1990s GPS model"?
Post reply on HN