61–70 of 393 posts
[1] https://fuchsia.dev/fuchsia-src/contribute/contributing_to_n...
[2] https://cs.opensource.google/fuchsia/fuchsia/+/master:src/co...
It seems like Rust is really catching on. To be honest, I didn't pay much attention to it for a while -- it felt like it might have simply been that day's "flavor of the day", destined to sink once then next flavor became popular. Now, there's a real problem to be solved. But I thought a simpler approach would be needed (e.g., Zig or something like it). I guess that may still happen, but seems more and more like Rust…
Zig isn’t quite production ready.
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…
It seems like Rust is really catching on. To be honest, I didn't pay much attention to it for a while -- it felt like it might have simply been that day's "flavor of the day", destined to sink once then next flavor became popular. Now, there's a real problem to be solved. But I thought a simpler approach would be needed (e.g., Zig or something like it). I guess that may still happen, but seems more and more like Rust…
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.
I think that while the language is a little complicated, this is tempered by how nice the tooling is. I consider the borrow checker to be my TA, as it actually helps the student write code that is structured better. When they go on to write C and C++ in later courses, their code is actually more memory safe due to having their habits having been shaped by Rust.
Earlier quoted context omitted.
Zig isn’t quite production ready.
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.
Discussion from 9 days ago: https://news.ycombinator.com/item?id=26537693
Earlier quoted context omitted.
Any insight into why Apple seems to have a much better bluetooth stack? I do a lot of BLE development that has to work cross platform, and we see constant GATT connection issues on android compared to almost none on ios.
My guess would be that they can apply much more pressure to the Bluetooth chip vendor. The buying power that Apple has for designing in a particular chip is much bigger than any individual Android manufacturer (even Samsung). That gets them the leverage to get the chip vendor to do what they want.
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!
Any insight into why Apple seems to have a much better bluetooth stack? I do a lot of BLE development that has to work cross platform, and we see constant GATT connection issues on android compared to almost none on ios.
Earlier quoted context omitted.
Could it be because they only have a handful of hardware variants to support, vs hundreds on Android? Presumably, the stack itself is somewhat sane on both sides, but the hardware's bugs, poorly specified or undefined behavior is constantly throwing wrenches in the machinery - Apple managed to fix most of them for the hardware they support, but Android has no chance as they have to support hundreds of different chips…
Possibly, but half the guys on the dev/qa team have google pixel devices and even they throw connection errors fairly regularly.
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…
- volume stuck low or high (on headphones :/) - "fixed" with a quick bluetooth off/on cycle
- volume okay but not responsive to changes in system volume
I've become used to these issues but I'd love a new driver that made them go away!
Since Android is Linux, will this become available to all Linux users?
Everything else, including drivers post Treble, doesn't have anything to do with Linux.