Live data from Hacker News

Expanding Fuchsia's open source model

opensource.googleblog.com

191–200 of 334 posts

Re: Expanding Fuchsia's open source model

#191

Google and Opensource a joke of century. Chrome -> Make chromium opensource but add spyware that phones home on every second and with new manifest v3 make sure extensions like ublock origin don't work Andriod -> Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it. And make sure there is no way to block ads on youtube for andriod. Fuchsia -> Initial Stage make p…

I think we should still give them credit for being the most open among their peers. MacOS, iOS, Safari and Windows are not open source at all. Edge is of course just another Chromium based browser.

Re: Expanding Fuchsia's open source model

#192
post #144

Earlier quoted context omitted.

It’s already running on some of their embedded devices, such as google home. A capability based OS with a micro kernel sounds great to me. Things like the networking stack can run in user space, and be written in memory safe languages like Rust. An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult.

It's not really a microkernel.

Indeed: https://fuchsia.dev/fuchsia-src/concepts/principles/pragmati...

Re: Expanding Fuchsia's open source model

#193

Earlier quoted context omitted.

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…

The real question is, moving forward, if somebody submits a proposal, properly tested, described and discussed with the community that makes a fundamental or deeper change whether that is likely to be accepted or not. The bazaar certainly exists for the Linux kernel insomuch that this can and does happen (partly as a result of the fact many companies contribute but none control it). For go it does not, for chromium i…

I understand the concern. I spent the vast majority of my career not at Google while also involved in open source communities, and I can empathize with this. I think one place we have a leg up here is that we do have documented processes for performing this type of work. It's certainly possible that the outcome of a proposal is rejection, but the hope would be the process does that quickly. We're all human and we don't want to waste anyone's time.

One of the cases that people cite for Go rejecting the community outright is the modules work. My perspective is that could've been handled better, but I didn't have a stake in that. But then I look at the error handling proposals, all rejected, including the ones originating from Googlers. And the iteration on generics, which has been reworked several times due to dissatisfaction expressed by community members of all experience levels. I think it's fair to say that even though there are deciders of what happens, they hold themselves to the same standard.

I hope you'll consider at least taking a look as a hobbyist. It's a large system, so both lots of opportunity for contribution and lots to learn. I think many of us are very eager to work with people outside the team, especially as many strive for more social interaction in general, and I know many of us are individually looking forward to welcoming external contributions. Certainly we can never find out if the process works if no one tries.

edit: redundancies

Re: Expanding Fuchsia's open source model

#194
post #188
post #64

Earlier quoted context omitted.

I understand where you're coming from, but that ends up being an inclusion issue in the project. I'm comfortable having my name and bio "out there" on the Internet, but I recognize that's a privilege. Not everyone who contributes to the project will be comfortable doing that.

The Eng Council is 5 people in a position of governance, not everyone who contributes.

Ah, I didn't realize the comment above was about the Eng Council. I'll raise the issue at our next meeting. Thanks!

Re: Expanding Fuchsia's open source model

#195

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 have considerable more say? For example if they have 20 full time engineers working on it and have contributed 95% of the code, then if I come along and make a few changes should I have equal say and control over the project?

Re: Expanding Fuchsia's open source model

#196

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

Because Linux isn't perfect. It can be improved upon.

* All code in the kernel including all drivers is 100% trusted. This is very bad for security.

* No stable driver ABI, so writing out-of-tree device drivers is very difficult.

* GUI is an afterthought, which means it is very difficult to do things like graphical secure attention keys, and frankly graphics/display support on Linux is very janky as a result.

* Many of its features are firmly stuck in the 80s.

Re: Expanding Fuchsia's open source model

#197
post #33

Earlier quoted context omitted.

You may want to browse it using https://cs.opensource.google/fuchsia . Much nicer interface. (disclosure: I work on Fuchsia at Google)

Wow! That's so fast it feels good :) I'd actually prefer that as a default for GitHub. Is it based on a public tool? Does it render server-side?

It is based on our Code Search tool, that is also used internally to index and browse most of Google's source code: https://developers.google.com/code-search

The best part is the cross-references: try clicking on any identifier in https://cs.opensource.google/fuchsia/fuchsia/+/master:src/li... for instance.

I'm not sure how rendering works, I'm only a happy user :-)

Re: Expanding Fuchsia's open source model

#198

Earlier quoted context omitted.

> I've heard Fuchsia referred to as a "principal engineer retention project" at Google. No rational company is going to create useless projects just to retain expensive engineers. What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI?

> No rational company is going to create useless projects just to retain expensive engineers. What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI? (Short) story time! Windows on ARM was a solo pet project of a high level engineer at Microsoft! There are some engineers who are so valuable that letting them spend non-trivial amounts of time on whatever they…

I don't think it's fair to call Windows on ARM an "engineer retention project". They actually released Windows RT and tried very hard to make it work. They still have it going with the Surface Pro X, and they just announced an emulation layer to get x64 applications working on ARM, which if it works well would solve RT's biggest problem, a lack of legacy applications: https://www.neowin.net/news/it039s-official-x64-emulation-is...

Re: Expanding Fuchsia's open source model

#199
post #49

Earlier quoted context omitted.

>An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult. I don’t think these claims hold. It is still written in a memory unsafe language, so exploitation is totally possible. As well, for malicious software you’re just looking for a process handing out high privilege handles.

> 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 that analysis exists yet.

Re: Expanding Fuchsia's open source model

#200

Earlier quoted context omitted.

Google uses GitHub for a bunch of things, I suspect it is more that the people working on it want to use Google's internal tooling as much as possible, and public user experience is considered less important than that.

This is the right answer. Google has tons of internal tooling and libraries and frameworks that are all just internal to Google.

That may be true for Google in general, and internal code in particular, but that's definitely not the case for Fuchsia. We use the tools and interfaces available to the public to work on the code base: code search to browse the code, gerrit for reviews and monorail for tracking bugs.
Post reply on HN