Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust • Hacker News Board

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

#281

Post by pjmlp » Wed, Mar 31, 2021, 8:44 PM UTC

fouric wrote: post #248

kllrnohj wrote: post #89

Earlier quoted context omitted.

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…

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

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

#282

Post by mandelken » Wed, Mar 31, 2021, 8:46 PM UTC

londons_explore wrote: post #167

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.

Building radio ASICs is a world rife with patents. Pretty much nobody new can enter the market.

Care to expand? Is that why Software Define Radio is still so much a niche and expensive?

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

#283

Post by pjmlp » Wed, Mar 31, 2021, 8:50 PM UTC

ampdepolymerase wrote: post #124

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.

Common Lisp had itself and its community to blame. Their dependency managers were decades behind other scripting languages. Poor defaults for build tooling. Even now building a statically-linked binary is an exercise in frustration. Despite being an ANSI specified language, the most popular libraries focuses only on SBCL. CL is like Lua where most interpreters never achieve 100% compatibility with each other. The lac…

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

- Guy Steele, Java spec co-author

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

#284

Post by pjmlp » Wed, Mar 31, 2021, 8:56 PM UTC

est31 wrote: post #245

steveklabnik wrote: post #129

Earlier quoted context omitted.

So, I dug into this a bit more, and you're right! https://www.fluentcpp.com/2017/06/13/the-real-difference-bet... Maybe it was the era that I learned C++ (which was in the 98 days), but I was taught something closer to this convention, and didn't realize until just now there was such little difference by the book. Just bundling some data together? Use a struct. Doing more? Use a class. I still think this distinction…

C++ has to have structs because it wants to be (mostly) backwards compatible with C. I think that's the main reason they exist in C++.

That is correct.

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

#285

Post by edent » Wed, Mar 31, 2021, 8:58 PM UTC

mondoshawan wrote: post #174

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.

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…

> Prior to Android, all we had were closed source low powered feature phones and Blackberries.

Symbian was open source, ran on millions of smartphones - most of which had app stores and web browsers. Some of which had touchscreens, GPS, augmented reality features etc.

Don't get me wrong - Android has been brilliant. But let's not completely rewrite history, eh?

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

#286

Post by gecko » Wed, Mar 31, 2021, 8:58 PM UTC

mondoshawan wrote: post #174

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.

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…

    Prior to Android, all we had were closed source low 
    powered feature phones and Blackberries.

I...what? Even if we want to ignore the iPhone for whatever reason, the Palm Treo, Nokia N900, and Windows Phone were firmly established by the time Android started getting demoed--and that was the variant that was very much reminiscent of Windows Phone, with a strong emphasis on the cursor keys over a touchscreen.

The rest of your comment makes sense, but the cognitive dissonance of that sentence was so extreme I had to respond.

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

#287

Post by londons_explore » Wed, Mar 31, 2021, 8:58 PM UTC

mandelken wrote: post #282

londons_explore wrote: post #167

Earlier quoted context omitted.

Building radio ASICs is a world rife with patents. Pretty much nobody new can enter the market.

Care to expand? Is that why Software Define Radio is still so much a niche and expensive?

Nearly all modern radio chipsets are mostly software defined. That includes WiFi, LTE and GPS.

The radio frontend is typically a downmixer and then straight into digital.

Some of the typically "software" bits like FFT's, various encodings, checksums, clock recovery etc. are frequently done in digital hardware acceleration blocks for performance, and saving power. If you were writing the firmware of the device, you needn't use them though.

With enough human years of effort, you could take almost any radio hardware for sale today and repurpose it to speak nearly any other radio protocol in similar frequency bands. Performance will probably be terrible though!

It's rare people do this though - all the chips don't have their firmware documented (again mostly to avoid publishing documentation that proves they are violating someone elses patents), and many have various cryptographic elements that makes reverse engineering hard.

The one exception to this is WiFi chips used in the Nexus 5 by Broadcom, which has had a reasonable amount of reverse engineering because Broadcom accidentally published the source code because the firmware code was in part shared with published Linux kernel driver source code.

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

#288

Post by maxcanada » Wed, Mar 31, 2021, 9:01 PM UTC

Neat

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

#289

Post by londons_explore » Wed, Mar 31, 2021, 9:01 PM UTC

mandelken wrote: post #282

londons_explore wrote: post #167

Earlier quoted context omitted.

Building radio ASICs is a world rife with patents. Pretty much nobody new can enter the market.

Care to expand? Is that why Software Define Radio is still so much a niche and expensive?

There are a gazillion patents on radio related stuff. Nearly all standards have associated patents.

Companies already in the industry typically have cross-licensing agreements - ie. I can use your patents if you can use mine. Either that or they just violate each others patents knowing that a patent war would be mutual destruction and in neither companies interests.

But a newcomer has nothing to offer - the minute they release any product, every incumbent company will go through their patent portfolio and sue them out of the water.

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

#290

Post by jillesvangurp » Wed, Mar 31, 2021, 9:02 PM UTC

yjftsjthsd-h wrote: post #235

jillesvangurp wrote: post #120

Earlier quoted context omitted.

Interesting; makes you wonder about the potential for code sharing between that and Android or even linux as well. The Linux kernel developers are open to allowing some Rust usage for things like drivers at this point. So the time seems right for this kind of thing. I guess there is also some decent code from e.g. redox os that might be adapted. Licensing (MIT) should not be an obstacle for this as far as I understan…

> I imagine e.g. Samsung might have some hesitations about being even more dependent on Google as a supplier. Does it make them more dependent? Google is effectively the only upstream for Android, and Fuchsia is open source, so it seems like it should be the same?

One of them is based on mobile linux; which Samsung also uses for things like Bada and which has a lot of hardware vendors supporting it with drivers; including Samsung itself of course. Bada actually originated out of Nokia's Meego and Maemo mobile OS. That predates Android and early Android versions ran pretty much the same Linux kernels. The first devices running Android were actually Nokia N800s before they did the first Nexus.

Fuchsia is open source but closed source friendly (because of the license). I suspect that's actually the main non technical argument for Google to be doing this: Android is too open and they've been trying to fix that for years. Apple has a similar benefit with the BSD internals of IOS and OSX. Still OSS in part but mostly not and Apple has not bothered with supporting separate Darwin releases for a long time.

So, like with Android, I'd expect a fair amount of closed source secret sauce is going to be needed to run Fuchsia. More rather than less. I doubt Google free versions of Fuchsia are going to be a thing like it is a thing with Android. Google is doing this to take more control of the end user experience. Just like Apple does with IOS. Letting Samsung (or anyone) bastardize that is not really what they want here.

I'm guessing, Samsung actually wants less of that Google secret sauce at this point rather than more. They are trying to differentiate with exclusive features, their own UX, their own apps, and services, etc. I'm expecting a lot of OEMs are going to have a similar mindset. Especially the Chinese ones currently shipping flavors of Android without a Google license for the play services on the wrong side of the current trade wars (like Huawei). Google has got their work cut out there trying to get OEMs like that to swallow Fuchsia. I think, Google is going to end up supporting Android for a long time because of this even if they eventually launch Fuchsia (which in my opinion is not a certainty yet). The simple reason for this is that the alternative would be walking away from a chunk of the mobile market that they currently exploit via their play store. I don't see them surrendering that and I don't think they would want third parties to continue releasing Android without Google either. So, the only way to prevent that would be a long term Android development strategy regardless of whether they actually release Fuchsia or not.

So, reusing code across Android and Fuchsia makes a lot of sense.