Live data from Hacker News

Fuchsia overview

fuchsia.dev

81–90 of 235 posts

Re: Fuchsia overview

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

I think we should lower the entry threshold first. The open source and free GPU project was the first thing that came to my mind when I saw http://llhd.io/. After all, one of the main problems with OpenHardware projects is the closed FPGA ecosystem.

Re: Fuchsia overview

#82
post #76

Earlier quoted context omitted.

I'm pretty sure Qualcomm not giving a shit about supporting their SoC is why my Android watches were practically EOL'd within months.

Not sure how Fuchsia is supposed to solve this. If you can port those Qualcomm SoC drivers to the fixed Fuchsia interface, you could just as easily port them to the mainline Linux kernel and submit them upstream.

"Easily"? Some things can only be shipped as binary blobs. For example, you won't get open source audio drivers that support patent-encumbered codecs like Dolby Atmos.

Windows has a stable binary ABI which means that my drivers don't go stale when Microsoft pushes out a minor rev to the NT kernel. Windows does its updates and my peripherals [mostly] work just fine.

Re: Fuchsia overview

#83
post #2

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

> Another Google project that will end up being abandoned

This one however will give Google full control of the devices it runs on (no more Linux kernel related obligations), so they have zero incentives to kill it, unless they write something else that does the same things. Google will rather abandon Android a few years after Fuchsia is launched.

Re: Fuchsia overview

#84
everything in userspace == high security. programs, software won't clash like they do on *nix, windows due to isolation. same benefits of snaps | flatpaks. but now you've a microkernel which is 1. fast 2. easy to patch 3. stable ABI something Linux doesn't have.

Re: Fuchsia overview

#86

Earlier quoted context omitted.

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…

The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler. What the CLA does not prohibit is proprietary use—- your lengthy answer. The OP makes the point that Google will find a way to use public contributions for Google’s own profit. The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer”…

I've responded to the CLA / licensing issues in a separate sibling comment (https://news.ycombinator.com/item?id=23365535); this comment is to respond to the rest of your post as it's a separate topic that's important in its own right.

> The OP makes the point that Google will find a way to use public contributions for Google’s own profit.

That's an opinion on motivations, not a statement of fact, so I am not agreeing or disagreeing with that. My comment was only about CLAs and open-source licensing, and what each of them enables you to do (or not) with someone else's source code, and how your contributions may be used by others after you submit them, not a statement or response to their opinion.

> The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer” which is what has alienated so many people from Google. The problem I’ve repeatedly experienced in Google open source and as a Google Cloud customer (contract with Google FDEs on-site) is that Googlers just don’t listen. You can’t trample the customer with your own narrative no matter how correct and elegant it is.

I'm sorry you've had negative experiences in the past, and I'm sorry to read that my response on the distinction between CLA & open-source licenses came across as not listening or talking past the customer — that was not the intent at all.

If you're open to it, I'm happy to chat with you separately (you can easily find me on Twitter or LinkedIn and send me a message) whether you want to discuss this topic, or your other experiences with Google open-source projects, or Google Cloud, and I can try to help, or just listen. If not, that's fine, no worries.

> You can disagree, but you can’t deny the feelings of others. It just doesn’t work that way.

I'm sorry that came across as not listening; my comment was only to clarify the notion of CLAs and how they relate to open-source licenses, without delving into business goals and future roadmaps (which I have no visibility into, nor control of, in this case).

Everyone is entitled to their opinions or feelings on how a company might or might not use open-source software or their motivations for open-sourcing (or not) of a project, and I'm not here to debate, explain or defend any company's decision in that regard. Again, my comment was limited to the scope of what a CLA brings to an open-source license of a project.

Re: Fuchsia overview

#87
post #50

Earlier quoted context omitted.

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

I would not say that is a fundamental reason. They have been willing to do it when the proper incentives are there. The incentive to keeping it closed source is primarily part of a strategy to sabotage their competitors, which I hope is not a behavior that anyone here is complicit in. Please don't work for hardware companies that do this, there are plenty of companies out there that know how to spend their money in o…

That is an assumption. I think the simpler case is it's more work and exposes potential security vulnerabilities they don't care to patch or maintain. Function > all.

Re: Fuchsia overview

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

Apart from the unfortunate sounding name, for this to be relevant on android phones or watches, it needs to simply work with the 2+ million apps out there. Just posix compatibility is insufficient - apps rely on Linux implementation behavior.

Re: Fuchsia overview

#90
post #79
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…

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 nice or ugly, but if they are there I want to control them).

Even enterpriseish devices, like Lenovo's X1 laptops, that are CERTIFIED by both Red Hat and Ubuntu, have limited hardware support at best. Fingerprint scanners on 3 year old models are still not recognized, and there seems to be zero will from synaptic to ever support it. Sleep states were terrible for a long long time, finally fixed in a fashion that requires different firmware for optimal sleep performance on Windows or another one for Linux.

So no, my experience is that still hardware vendors are not giving me as a Linux user the support and value for the good money I pay for their products. Obviously they don't deliver the expected level of support any reasonable consumer would expect, and most probably won't deliver it in the future either, since they get away with it so easily.

Post reply on HN