Live data from Hacker News

Expanding Fuchsia's open source model

opensource.googleblog.com

141–150 of 334 posts

Re: Expanding Fuchsia's open source model

#141

Earlier quoted context omitted.

You can't pseudonymously contribute to most OSes of note. Linux for example.

I'd just like to interject for moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but sure you can contribute to the Linux kernel pseudonymously. Think of a plausible name, "git commit --signoff", and you're good to go. There's no enforcement of slave names for kernel contributions, it's all just a min…

Slave names, really?

You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted". (https://www.kernel.org/doc/html/latest/process/1.Intro.html)

And since you mentioned GNU, would you be able to pull the same trick on a GNU project? Don't they require you to sign away your copyright, with paperwork? So you wouldn't be able to contribute to (some portions of) GNU/Linux pseudonymously.

Re: Expanding Fuchsia's open source model

#142

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

There is definitely room to innovate more fundamentally in operating system design. POSIX is effectively a 50-year old API, and there are definitely places where the API it provides is far from optimal. For something that interests me personally, the POSIX idea of ptrace and signals for debugging is a fundamentally broken and obtuse API that just don't work very well with how modern software is designed, and requires…

POSIX doesn't say anything about ptrace. And yeah, ptrace is somewhat horrible, but there's no reason you couldn't implement something better in existing systems; it's just that the amount of work necessary is so huge it's probably not worth it, but the same amount of work would be needed to write it from scratch.

Re: Expanding Fuchsia's open source model

#143

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

None of these are microkernels with a strict capabilities model. Open source isn’t the only desirable property of a kernel, and Unix is probably not the last word in advancements of general purpose OS APIs. One application they’re probably interested in is a sandbox/containerization system with a drastically smaller surface area than the Linux primitives. That’s what excites me, we may get to the point where things l…

Isn't seL4 a microkernel with a strict capabilities model?

Re: Expanding Fuchsia's open source model

#144

I'm still not clear on what fuchsia is trying to be - or more specifically, why is Google developing it. What is the end goal here, from a business perspective?

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.

Re: Expanding Fuchsia's open source model

#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 contributing to the project would benefit anyone but Google.

Re: Expanding Fuchsia's open source model

#146
post #23

Earlier quoted context omitted.

> Looks like you still cannot contribute without granting copyright ownership to Google That is not accurate. Fuchsia uses the standard Google CLA: "You do not surrender ownership of your contribution, and you do not give up any of your rights to use your contribution elsewhere." https://cla.developers.google.com/about

There's a big difference between licensing code to the world under the terms of Apache 2.0, and licensing code to Google under whatever terms they feel like now or at any time in the future.

I don't think it's an important difference. If you're doing open source at all, you're losing control over what's done with your code, including allowing it to be used by competitors and "bad guys" however you define that.

See (5) and (6) in the open source definition: no discrimination against persons or groups, and no discrimination against fields of endeavor.

If you're unwilling to relinquish control, no open source license is going to be good enough. At best you might scare some risk-adverse companies away from using it, but there are still going to be a lot of people you dislike who can use your software to nefarious ends.

Re: Expanding Fuchsia's open source model

#147
post #143

Earlier quoted context omitted.

None of these are microkernels with a strict capabilities model. Open source isn’t the only desirable property of a kernel, and Unix is probably not the last word in advancements of general purpose OS APIs. One application they’re probably interested in is a sandbox/containerization system with a drastically smaller surface area than the Linux primitives. That’s what excites me, we may get to the point where things l…

Isn't seL4 a microkernel with a strict capabilities model?

SeL4 currently doesn’t have shared memory concurrency, and is only the kernel part. It’s focused heavily on formal verification, and makes a number of other sacrifices (in particular to performance) to achieve that. I’m a big fan of formal verification, but seL4 levels of assurance are still too unwieldy with current tools for an application that doesn’t place a massive premium on it.

It’s also worth noting that the Fuchsia equivalent would be Zircon, which is a relatively small part of the Fuchsia project (and will only get smaller in proportion).

Re: Expanding Fuchsia's open source model

#148

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…

> there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against

AFAIK these are reverse-engineered. Do you sincerely believe that developers' time is best spent reverse engineering and maintaining play services alts to undo a blockade that Google put in, just to be able to get full freedom over their android derivative? Wouldn't it be better spent in playing with cool new tech (as Google engineers seem to be doing)?

Re: Expanding Fuchsia's open source model

#150
post #49

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.

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

FWIW, use of memory-safe languages doesn't preclude exploitability. It's "just" another way to reduce attack surface.

(disclosure: i work on fuchsia, big rust fanboy)

Post reply on HN