271–280 of 393 posts
Earlier quoted context omitted.
> 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.
So why should Samsung invest more than the bare minimum when they can't get anything measurable in return?
Earlier quoted context omitted.
From what I know from having worked at Nokia, it's simply the result of design by committee where the committee was made up of mutually very hostile hardware (mostly) companies not particularly good at software (that's how Nokia failed in a nutshell), telcos, chipset manufacturers, hardware manufacturers, etc. And I mean hostile as in looking to squeeze each other for patent licensing, competing for the same customer…
> pple did Facetime instead and in the process also strangled SMS and cut out the middlemen I'm personally really glad for this decision. iMessage is many times better than SMS. SMS security is a nightmare by design. I just wish there was something better between Google and Apple, like a universal iMessage.
Earlier quoted context omitted.
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?
I don’t follow the leap. The grandparent’s point was about the quality and terrible lack of long term support of Broadcom chips. How does that translate to issues of the standard itself? Nobody would complaining about Apple creating their own radio chips (which they seem to plan for 5G/6G). Apple creating their own standard protocols is an issue though.
I fixated on Apple because they're often picked on for taking the highway, but on the other hand what's the point doing otherwise? What's a common ground if it's just a pipe dream?
Earlier quoted context omitted.
I wouldn't be surprised if Apple write their own firmware for things like bluetooth chips.
I would be surprised if they didn't. They advertise their own Bluetooth chips H1 and W1 in AirPods and some Beats products. These chips definitely have their own firmware and it would be rather ridiculous not to also have their own firmware on the host side, maybe even re-using code.
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…
Personally I don't find it necessary, but the proposal for REPL has been accepted: https://github.com/ziglang/zig/issues/596
Earlier quoted context omitted.
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…
> 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. What legal battles were there? Wikipedia puts Android being started in 2003 [0] and then only legal battle I recall with BSD having settled in 1994 [1]. [0] https://en.wikipedia.org/wiki/Android_version_history [1] https://en.wikipedia.org/wiki/UNIX_System_La…
That would be Google's second (at least!) bluetooth stack in Rust, the first one being in Fuchsia. https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master...
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.
That would be Google's second (at least!) bluetooth stack in Rust, the first one being in Fuchsia. https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master...
The headline is misleading. Most of this code is C++. They included some Rust, but the core isn’t Rust.