Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fuchsia overview

fuchsia.dev

Post reply on HN
Print view View original

61–70 of 235 posts

Re: Fuchsia overview

#61

Post by est31 »

CJefferson wrote: post #51
catern wrote: 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…

While I understand why you want open source drivers, the situation hasnt improved for 10 years, and this is one of the major reasons many phones end up not getting Android updates, which makes Google/Android look bad.

> the situation hasnt improved for 10 years

But it has.

* I remember having major issues with printer drivers on Linux 10 years ago. Nowadays thanks to IPP support I don't need any drivers any more. I had to help my dad with installing a windows driver while on my Linux laptop it just worked.

* My Laptop from 13 years ago didn't have free network drivers. I had to jump through hoops to install them. Now they are all free.

* AMD has started maintaining really good open source driver support for their GPUs

* Even for Android there is improvement, with e.g. free Mali drivers being built. It's slow and not enough, but improvement.

Re: Fuchsia overview

#62

Post by zozbot234 »

smnrchrds wrote: post #36
kick wrote: post #24

Earlier quoted context omitted.

'Animats didn't claim they were ever open. His claim was more along the lines of: Google Play Services has over time subsumed more and more of core functionality, enough to stop the creation of clones. Which is true.

Once upon a time, Android had a mail client that was part of the open source components. There was also GMail app that was closed source. Then a couple of versions later, the open source email app was discontinued and its functionality was incorporated into GMail. And the same thing has happened to many more apps and functionalities.

The F-Droid store provides compelling alternatives to essentially all of the old AOSP apps. (LineageOS also maintains varieties of them.) The one component where there's been a real issue for FLOSS apps is support for centralized push notifications, and that's reliant on 3rd-party services so "open" is not a very meaningful characterization anyway.

Re: Fuchsia overview

#63

Post by Godel_unicode »

plerpin wrote: post #20
gman83 wrote: post #9

Sounds like Google's version of Darwin.

You mean Mach?

Please see the below diagram from Wikipedia explaining the difference between Mach and Darwin. I agree with OP that Fuschia is much closer to Darwin than Mach.

https://en.m.wikipedia.org/wiki/File:Diagram_of_Mac_OS_X_arc...

Re: Fuchsia overview

#64

Post by zozbot234 »

snazz wrote: post #60
ptomato wrote: 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…

Plus, better isolation between driver code and other kernel code (which Fuchsia seems to bring; correct me if I'm wrong) would be good for everyone, since you can be relatively assured that running vendor-provided driver blobs is safe.

"Isolation" of driver code that can talk to on-SoC hardware is just not very meaningful. You can only have real driver isolation if it's enforced on the hardware side via some IOMMU mechanism (or by keeping the hardware isolated on the USB bus, etc.), otherwise you're just adding pointless overhead for no real benefit.

Re: Fuchsia overview

#65

Post by cycloptic »

ptomato wrote: post #50
catern wrote: 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…

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

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

Neither of those are good options because even in the second case, there are still vast swaths of code that upstream is not going to touch out of fear of breaking things, the end result being that you still get stuck with unfixable kernel and driver bugs.

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

The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.

Re: Fuchsia overview

#66

Post by jccalhoun »

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

Re: Fuchsia overview

#67

Post by cryptoz »

a3n wrote: post #23
cryptoz wrote: post #5

Earlier quoted context omitted.

I have a strong feeling that Fuchsia will not be abandoned. I can't put my finger on it, but Google's approach and tone around Fuchsia feels really different from how they talked about / marketed Reader, or even Wave, or other things they shut down. I'm an Android developer learning Flutter and Dart out of both curiosity and an gamble that it will likely be a faster-improving way to make cross-platform apps than othe…

> I can't put my finger on it, but Google's approach and tone around Fuchsia feels really different from how they talked about / marketed Reader, or even Wave, or other things they shut down. Different marketers?

Maybe - but are the marketers even in charge of the open source decisions? It's possible I guess. But to name an example, the open source code and developer-focused nature of the work just makes it seem completely different to me.

Re: Fuchsia overview

#68

Post by qmarchi »

jccalhoun wrote: post #66

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

Re: Fuchsia overview

#69

Post by skavi »

jccalhoun wrote: post #66

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

There’s a fairly heavy emphasis on graphics and UI throughout Fuchsia’s stack, so I doubt it’s meant to just sit on a server.

Re: Fuchsia overview

#70

Post by mbrukman »

ColanR wrote: post #33
mbrukman wrote: post #30

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…

>> If you submit code, you grant a license to Google to use it in non-proprietary [ sic , I assume] code. > it's a copyright license, not a copyright assignment >> So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. > you're welcome to fork it if you wish, or distribute proprietary, non-open-source versions of the code It sounds like…

Sorry for not making it more clear; I was responding to the statement:

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

The CLA does not change anything about the license, and does not prevent or make it possible (or easier) to make proprietary versions of the software (or your contributions) — all those conditions are in the license itself, the CLA does not override or amend any terms of the license.

In other words, you can make the same argument about any Apache, BSD, or MIT software, while the poster is claiming that it's the CLA that enables making future releases proprietary, which is why I pointed out that the Google CLA is the same as the ASF CLA.

If the argument is that Apache/BSD/MIT licenses are "not really open" because they allow incorporating them into proprietary software without releasing code, that's a different argument and is really a distinction between the "permissive" licenses like Apache/BSD/MIT and the "copyleft" licenses like GPL, but again, that has nothing to do with the CLA.

Post reply on HN