Live data from Hacker News

Fuchsia overview

fuchsia.dev

91–100 of 235 posts

Re: Fuchsia overview

#91
post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

It's a negotiation, and the hardware vendors seem to be 100% happy stepping away from the table and letting old hardware suffer. They have a lot more leverage than we FOSS supporters do.

What this is really about is Qualcomm. They have inadequate competition and that allows them to abuse everybody else.

In a competitive market, open source drivers win. Look at the desktop market -- nearly everything is open source, and the biggest holdout is nVidia, because for a while there nobody was challenging them on performance. Now that AMD has competitive GPUs again, not only does that provide a competitive option with open source drivers, nVidia is now losing market share to them.

OEMs don't really like proprietary drivers. They're a pain. Whenever new driver versions come out, it becomes the OEM's problem to test and distribute them instead of having the Linux kernel team deal with that hassle. The open source drivers also generally have fewer bugs (because anybody can fix them), which leads to fewer support calls and more satisfied customers who make repeat purchases.

And customers naturally prefer hardware with longer hardware support, when it's available.

What we need is more competition for Qualcomm. Google could do that if they wanted to -- throw some money at making competing phone chips. Apple does it, why can't they? And then publish open source drivers and sell the chips to anybody.

We also have AMD as a dark horse now. The Ryzen 4000 series goes down to 10 watts -- it's so power efficient you could squeeze it into an Android tablet as-is (and then be a lot faster than most tablets), and it wouldn't take much on AMD's part to do something that could work in a phone. Android is an open source system with apps that run on the JVM, so the architectural difference shouldn't matter much.

Or we could get the antitrust authorities to stop letting Qualcomm buy every competitor that springs up, which they've been doing for years.

But you solve the competition problem and you get open source drivers. Along with all the other benefits of real competition.

Re: Fuchsia overview

#92
post #2

Another Google project that will end up being abandoned. Flutter, Dart, messaging, etc. They need to just fix Android.

Maybe they will fix Android by replacing it with Fuchsia :P I think the problems with Android run so deep, it can't just be "fixed".

Well, the touchstone is audio.

If Fuchsia manages to have audio performance like iOS, then they definitely rearchitected rather than just slapped lipstick on a different pig.

Re: Fuchsia overview

#93
I can't help but think that if microkernel architectures were such a good idea, that would explain why every popular OS is a microkernel architecture (oh wait...). Snark aside, this is a serious debate since the inception of Linux [1].

It's important to look at Fuchsia through the lens of what problems it solves in Android/Linux because that tells you a lot.

As we know, receiving updates in Android is, well, a clusterfark. There are two key problems:

1. Phone manufacturers need to write or update drivers essentially with each Android release; and

2. Those drivers are by nature of Linux being a monolithic kernel, written in kernel space. Kernel space code by third-parties is going to be inherently more unstable to your device than if they were written in user space.

So when Google talks about Fuchsia having a stable binary ABI for drivers, they're talking about solving both of these problems (at least as they see them).

So the question I've always had about the justifications for pouring billions of dollars into Fuchsia (I mean that quite literally) is: could this really not have been solved in Linux, even if it's just the limited context of Android?

I'm not a driver or Linux expert by any stretch of the imagination. I'm sure there are people here who are so this is my question to you: could you have created a system for ideally user space drivers with a stable ABI in Linux and avoided all the costs of completely reinventing that wheel?

My other question about Fuchsia is: does Google foresee themselves adopting the same vertically integrated solution that, say, Apple does? It's worth noting that Apple by not providing iOS to third parties is somewhat paradoxically immune to antitrust investigations (I mean really... how does that work?).

Evidence against Google adopting the Apple model is the fact that Fuchsia is open source, which is a curious decision. This seems to imply that Google either wants to maintain an Android-like ecosystem or they simply see it as their only viable option.

I don't know how anyone can expect that Samsung is going to move to Fuchsia. Samsung already chafes under the yoke of their Google dependence with Android. They've tried to get out from under it (ie Tizen) but luckily for Google, Samsung is terrible at software (at anyone with Samsung crapware on their Galaxy can attest; Bixby anyone?).

Maybe Google thinks the insurance of Fuchsia being open source is necessary for third-party adoption to have any chance but still, the only way I see Samsung going along with this is that there's absolutely no other alternative.

[1]: https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...

Re: Fuchsia overview

#95
post #6

Earlier quoted context omitted.

Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. Like they did to Android with Google Play Services. [1] https://cla.developers.google.com/about/google-individual

Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a bit to open-source projects. Disclaimer: I'm not a lawyer, this is not legal advice, etc. I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change t…

You're talking out your ass, Google.

Everyone knows how much Google cares about open source and open platforms...

Re: Fuchsia overview

#96
> Fuchsia's goal is to power production devices and products used for business-critical applications. As such, Fuchsia is not a playground for experimental operating system concepts. Instead, the platform roadmap is driven by practical use cases arising from partner and product needs.

This is an interesting statement given how many relatively unpopular OS concepts it integrates. I am interested in seeing this succeed. I hope that Fuschia helps drive capability-based sandboxing of end-user software.

Re: Fuchsia overview

#97
post #50
post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

> For various reasons, but nothing fundamental. "Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason. Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to…

> The open source community is not, for example, going to make their own high performance gpus.

Of course it will.

Re: Fuchsia overview

#98
post #68

>Fuchsia's goal is to power production devices and products used for business-critical applications People have guessed that Fuchsia is some successor to Android or unification of Chrome OS and Android. However, this statement makes me wonder if it is meant to run their backend hardware and not consumer products.

Actually quite the opposite, Fuchsia already runs on production devices manufactured by Google. The (ridiculously long named) Google Nest Home Hub and Home Hub Max both can run Zircon and Fuchsia on device, although it's very much for development.

They probably cut it down from the original “Play Home Hub All Access by Nest by Google”.

Re: Fuchsia overview

#99
post #90
post #79

Earlier quoted context omitted.

Once upon a time, Linux had terrible support for laptop hardware. Remember ndiswrapper? That thing you used to get Windows wifi drivers working on Linux. Or how about when ATI (AMD) provided only the most buggy drivers. How about printers? These days Linux has better hardware support (imo) than Windows. Solving it for laptops was about creating the right incentives for hardware manufacturers. It can happen for mobile…

I wouldn't say Linux has better hardware support than Windows. When your hardware is properly recognized and supported by Linux than yeah, I do feel it operates much better, more stable and have more knobs. However, not all hardware works at all. For example, as of now, the hardware sensors on my x590 board are not recognized. LED control is not a thing, even on most old/established boards (you can argue if LEDs are…

3 year old hardware is still very new by Linux standards. Especially wrt. hardware classes for which a unified support framework has yet to be provided, including RGB LED's and fingerprint scanners. The sleep performance thing is an interesting example, since the whole issue was caused by hardware OEM's deprecating the old ACPI "sleep" state and deciding that OS's should manage standby states entirely on their own - this too will require a lot of really hard work to be supported properly across zillions of devices.

Re: Fuchsia overview

#100
post #6

Earlier quoted context omitted.

Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. Like they did to Android with Google Play Services. [1] https://cla.developers.google.com/about/google-individual

Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a bit to open-source projects. Disclaimer: I'm not a lawyer, this is not legal advice, etc. I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change t…

> And, naturally, anyone can fork it if they wish, or distribute proprietary, non-open-source versions of an Apache/BSD/MIT-licensed project, subject to appropriate attributions, if required, by the relevant licenses.

so, basically you submit free labor for the use by for-profit corporations, but you dont get those same freedoms to do so on your own devices, got it

personally, i wouldnt mind so much if users of submitted code were payed "dividends" for ones labor when used in propriatary for-profit services/products, but seing as that is not the case, well, i cannot abide...

Post reply on HN