>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…
Fuchsia overview
51–60 of 235 posts
Re: Fuchsia overview
#52Earlier 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”…
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>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…
Re: Fuchsia overview
#54(Submitted title was 'Fuchsia overview – “Fuchsia is not a science experiment”')
Re: Fuchsia overview
#55>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…
They have a lot more leverage than we FOSS supporters do.
Re: Fuchsia overview
#56Earlier 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.
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>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…
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
#58Please 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”')
Re: Fuchsia overview
#59Re: Fuchsia overview
#60>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…