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

Expanding Fuchsia's open source model

opensource.googleblog.com

Post reply on HN
Print view View original

211–220 of 334 posts

Re: Expanding Fuchsia's open source model

#211

Post by pmontra »

jasonvorhe wrote: post #123

I don't understand the cynicism here. Android's fragmentation was the original sin that lead to fragmentation and the new that we've seen for years, until Google semi-fixed the mess with a) Play Services (short term) and b) Project Treble. Google were so convinced of the value of open source that they didn't anticipate that almost all OEM's would rather ship their Android forks than to stay close to upstream. If they…

I more or less agree with everything except

> that developers didn't lose interest in the platform in favor of iOS.

Developers go where users are. Some developers sell their apps on the store, others get hired to build apps that are distributed for free to make people use services they buy outside the store. Banking, business apps, etc. It's impossible to lose interest in Android. It's too big. Compare it with Windows phone which died for lack of users.

Re: Expanding Fuchsia's open source model

#212

Post by dhodell »

olladecarne wrote: post #195
barnacled wrote: post #167

I am a Linux kernel contributor and former golang and chromium contributor and to be honest the latter experiences makes me leary about contributing to another Google project. There generally tends to be an insular 'cathedral' rather than 'bazaar' approach to Google projects where those working for the company get considerably more say and control than outside contributors. The whole issue I have with it is that they…

> those working for the company get considerably more say and control than outside contributors As someone who knows little about open source politics, I'm genuinely curious about how people expect this should work. What are the large open source projects that have the gold standard for this that I can learn about? My initial reaction is that if a company contributes considerably more to a project, shouldn't they hav…

Without intending to either minimize or represent OP's opinion, my thought is the cases people get frustrated about are really unfortunate. In these cases, community opinions have been solicited -- sometimes committees are even formed -- and folks put in significant effort.

The oft-cited case with Go (and I'm paraphrasing heavily, so this account is likely unfair to everyone involved) was when Peter Bourgon formed a committee to design a Go packaging system, there were a bunch of meetings held that included core team members, and Russ apparently surprisingly came out with the Go modules proposal. The core team decided to adopt Russ' work. The team's perspective is it solved their problems simply and cleanly, and it came with an implementation. The community perspective was that the core team was now a sort of cabal.

I think the issue here isn't that the community's project was rejected, it's that there is a perception that folks were let to waste their time. It seems that sometimes people want this idealized model where an open project has a community that is on equal footing with the project owners, but I rarely see this to be the case in practice. Ultimately some individual or group holds a "voting share" that outweighs the community.

We have a documented process for system changes in Fuchsia that we have already been following internally. I've seen various proposals rejected; I've had proposals of my own rejected. It's always disappointing to have work rejected, because no matter what, it takes effort to come up, submit, and socialize work proposals. It's easy to feel slighted, especially when you're contributing for free while the folks making the decisions... well, it's their job.

I think I can say that it is nobody's goal on Fuchsia to waste folks' time. But I think it would be naive to think this kind situation couldn't or won't occur in the future. I just hope our transparency about our process and our availability to communicate with the community through lists will help mitigate negative feelings when a proposal representing a non-trivial effort is rejected.

Re: Expanding Fuchsia's open source model

#213

Post by pier25 »

owaislone wrote: post #207

Fuchsia will e to Android and ChromeOS what Servo is/was to Firefox. Eventually the guts of Android and ChromeOS will be replaced with Fuchsia while end users won't see a radical change. It might feel like moving from XP to Vista or OS 9 to OS X.

Hopefully not to Vista :)

Re: Expanding Fuchsia's open source model

#214

Post by vbezhenar »

outworlder wrote: post #110

> Fuchsia is a long-term project to create a general-purpose, open source operating system Why do we need this? We have Linux. It works. It is open-source, general purpose. It needs more support to become more mainstream (like what Valve has done with Proton). Don't like Linux? Start with one of the BSDs. Heck, start with Haiku. Any of these projects are lightyears ahead of anything that's just starting. The most lik…

Linux considers stable driver API as a nonsense. SoC manufacturers don't want to open source their drivers, they prefer to ship blobs and they prefer not to support those blobs for a future kernel updates. Those facts means that you can't upgrade your kernel. When you can't upgrade your kernel, you can't upgrade your userspace which depends on new kernel features. So basically your software is stuck and eventually obsolete.

There are two ways out of this situation. You can either replace Linux with another kernel with stable driver API or you can replace SoC manufacturers with those willing to upstream their drivers. Probably it's easier to go to the first route.

Re: Expanding Fuchsia's open source model

#215

Post by bestorworse »

TACIXAT wrote: post #199
bestorworse wrote: post #69

Earlier quoted context omitted.

> for malicious software you’re just looking for a process handing out high privilege handles In the end, that is true. But the thing is the way Fuchsia's implementation of the 'capability security model' is done. The capabilities a process (or, a 'component' in Fuchsia's model) use/consume are explicitly given to it. And this scheme is implemented in a way that is easy to see and account for where/from these capabil…

I expect it will be very much the same as drivers we have today, where you have some game anti-cheat rootkit that has a bug in it. In Fuschia's case it will be like that but the exploitation either gives you access to that driver's capabilities, or simply that driver is giving out handles with permissions insufficiently removed from them. It will be cool to see a full system audit of capabilities, but I don't think t…

> In Fuschia's case it will be like that but the exploitation either gives you access to that driver's capabilities, or simply that driver is giving out handles with permissions insufficiently removed from them

Yes, and then you would have to own a component in some route that received the driver exposed capability. Either way, the tight sandoxing and compartmentalization of functionality make things difficult.

There's an example of analysis here: https://blog.quarkslab.com/playing-around-with-the-fuchsia-o...

Re: Expanding Fuchsia's open source model

#216

Post by ajanicij »

dhodell wrote: post #181
barnacled wrote: post #167

I am a Linux kernel contributor and former golang and chromium contributor and to be honest the latter experiences makes me leary about contributing to another Google project. There generally tends to be an insular 'cathedral' rather than 'bazaar' approach to Google projects where those working for the company get considerably more say and control than outside contributors. The whole issue I have with it is that they…

It's kind of unfortunate because existing developers have the privilege of experience with the systems and where they're going that external contributors simply don't have, and it will take a non-trivial amount time for interested parties to develop that knowledge. At the same time, it is an active project with active development that are informed by goals and processes not all of which are open. And really, while th…

> However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion.

I am aware of one, but an important one: ZeroMQ. Thanks to the late Pieter Hintjens, this project has C4 model. I have not seen any other project where I submitted a PR and maintainer accepted it less than half-hour later, no questions asked. And it works wonderfully; ZeroMQ is live and well.

Re: Expanding Fuchsia's open source model

#218

Post by coddle-hark »

olladecarne wrote: post #195
barnacled wrote: post #167

I am a Linux kernel contributor and former golang and chromium contributor and to be honest the latter experiences makes me leary about contributing to another Google project. There generally tends to be an insular 'cathedral' rather than 'bazaar' approach to Google projects where those working for the company get considerably more say and control than outside contributors. The whole issue I have with it is that they…

> those working for the company get considerably more say and control than outside contributors As someone who knows little about open source politics, I'm genuinely curious about how people expect this should work. What are the large open source projects that have the gold standard for this that I can learn about? My initial reaction is that if a company contributes considerably more to a project, shouldn't they hav…

I think the problem is that Google doesn’t really want or need outside collaboration in their open source projects. They have project managers that steer the ship and more than enough smart people to write code. What do they need you for?

I think that’s often the (subconscious?) attitude Google has towards its open source projects at least. Which would be fine if they didn’t try to make it seem like their OS projects are a welcome place where anyone can contribute ideas and code and move the project forward.

As an example: Angular is open source but it’s very much a Google project. Rails is also open source but it’s a broad collaboration, certainly not a “37signals project”. Most people would rather spend their time contributing to the second kind of project.

Re: Expanding Fuchsia's open source model

#219

Post by rhencke »

rhencke wrote: post #159
peey wrote: post #145

AOSP is an open source project, which is impractical for any business to run because of apps' reliance on proprietary google play services. Chromium is an open source project, but proprietary chrome has the largest browser market share and they like to abuse their position to not play well with standards bodies. Google can develop Fuchsia. It'll even be cool piece of tech, but I do not for a second believe that contr…

Chromium, as built in many open-source distributions, uses a per-distribution Google API key for service access. [1] [2] [3] If built without API keys, Chromium warns 'Google API keys are missing. Some functionality of Google Chrome will be disabled.' [4] [5] The APIs used include [6]: * Calendar API * Contacts API * Drive API (Optional) * Chrome Remote Desktop API * Chrome Spelling API * Chrome Suggest API * Chrome…

To elaborate, the following distributions of Chromium are violating the Google API terms of service [1] [2] by publishing the API secret key publicly in the build source code responsible for building Chromium:

* Alpine Linux (community port) - https://git.alpinelinux.org/aports/tree/community/chromium/A...

* Arch Linux (svntogit, AUR) - https://github.com/archlinux/svntogit-packages/blob/1e8f3fe7... - https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chrom...

* Fedora Linux - https://src.fedoraproject.org/rpms/chromium/blob/e78656ce58d...

* Gentoo - https://github.com/gentoo/gentoo/blob/9acf51b665b6f4b5b97edb...

* OpenSuSE - https://build.opensuse.org/package/view_file/openSUSE:Factor...

* Slackware - http://www.slackware.com/~alien/slackbuilds/chromium/build/c...

* Ubuntu, Linux Mint (Canonincal Chromium Snap) - https://git.launchpad.net/~chromium-team/chromium-browser/+g...

[1] https://developers.google.com/terms (specifically: "You will only access (or attempt to access) an API by the means described in the documentation of that API. If Google assigns you developer credentials (e.g. client IDs), you must use them with the applicable APIs. You will not misrepresent or mask either your identity or your API Client's identity when using the APIs or developer accounts." and "Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.")

[2] https://www.chromium.org/developers/how-tos/api-keys (specifically: "Note that the keys you have now acquired are not for distribution purposes and must not be shared with other users.")

Re: Expanding Fuchsia's open source model

#220

Post by Inhibit »

phh wrote: post #156
jasonvorhe wrote: post #123

I don't understand the cynicism here. Android's fragmentation was the original sin that lead to fragmentation and the new that we've seen for years, until Google semi-fixed the mess with a) Play Services (short term) and b) Project Treble. Google were so convinced of the value of open source that they didn't anticipate that almost all OEM's would rather ship their Android forks than to stay close to upstream. If they…

Project Treble didn't fix anything (I'm very happy with Project Treble, because it lets me hack stuff I couldn't begin to imagine with 4 yrs ago, but that's just hack). It didn't even fix Nexus/Pixels that still have the same upgrade track record as a Samsung 100$ device. (Pixel 1 and Pixel 2 users, feel free to come and use my Generic System Image, I'll keep upgrading you as long as I can with my bare hands!) ATM OE…

Ah, then nothing's changed (re the messiness) since Android 2/4/5. Sounds like they're still moving toward locking down everyone's hardware to ensure their ad platform revenue.

The couple of devices I've broken down a release for and rebuilt just to clean out Trojans included in the firmware were devilishly difficult. And does it ever piss me off that there's nothing generic and updated to run on them.

Post reply on HN