Live data from Hacker News

Fuchsia overview

fuchsia.dev

51–60 of 235 posts

Re: Fuchsia overview

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

Re: Fuchsia overview

#52

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

They aren't disagreeing. Parse what they said, and notice nothing contradicts the post they're replying to.

That's what I didn't want to say explicitly in my other comment: they made a long-winded comment that appeared to express a negative statement about what the poster said, while technically agreeing. To me, it's a perfect example of a lawyer's yes-that-sounds-like-no.

Edit: glad I didn't say this in the other comment. Shouldn't have jumped to conclusions.

Re: Fuchsia overview

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

A big reason why Fuchsia exists is governance — Google wants to make a kernel that it controls. Linux cannot provide that advantage unless Google forks it.

Re: Fuchsia overview

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

Re: Fuchsia overview

#56
post #42

Earlier quoted context omitted.

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.

Part of that has more to do with the fact that AOSP is not used nearly as much and updating the default AOSP apps is not a good use of time for Google. The AOSP browser was never [edit: not recently] competitive with Chrome and the AOSP mail app was never [edit: not recently] competitive with Gmail.

> The AOSP browser was never competitive with Chrome

That's really not true, and not how it worked. Chrome was very late to the mobile game (first released 2012, a year after Android 4.0 / ICS was released) and its first few attempts on Android sucked. It was incredibly slow & laggy when it first finally came to Android.

It's obviously not a good use of resources to make two webkit-based browsers both targeting the same market, but it was a complete swap out from one to the other over a relatively short time-frame. It's not like the mail vs. gmail situation where it was actually two "competing" apps for quite a long while.

Re: Fuchsia overview

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

sorry but that's just naive idealism, my wife has android flagship, a Samsung s10, she will receive one more year of updates, then she will be on her own, my daughter has iPhone 6S, this old device will receive iOS 14 soon.

my wife do not care about updates, she will not hesitate a second to get iPhone once she knows her social media or pictures is not safe on her android device, this is the issue Android have and Fuchsia have to fix.

Re: Fuchsia overview

#58
post #54

Please don't editorialize titles. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html . Lots of explanation here: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... (Submitted title was 'Fuchsia overview – “Fuchsia is not a science experiment”')

[deleted]

Re: Fuchsia overview

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

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.
Post reply on HN