61–70 of 334 posts
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?
I find it kind of hilarious how large a proportion of the roadmap is just migrations of various kinds. If the goal here was to encourage external contributions, I can't imagine a much worse sales pitch.
I see it as better way of developing a product. Or actually, a foundational system , if Fuchsia really ends up becoming something like that. You see, lots of things that today are fundamental were just "developed organically", and that is OK because people never tought that it would end up being what it is. Besides, a greater part of the cruft we have today is rooted in the development model companies adopt that is "…
Earlier quoted context omitted.
Well if I have the copyright I can straight up sell software based upon it without telling people you made it. Or I can release your code or derivatives of it under a different license while privately selling it under other licenses for profit. If these things don't bother you, then feel free to contribute. In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference,…
> In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference, then why would Google require the contribution in the first place? The difference isn't relevant 99% of the time, but it comes up if the maintainership of a work tries to re-license the work. Works without assigned ownership cannot practically be re-licensed, as you'd have to get individual consent from a…
Bingo! Google will relicense Fuchsia to OEMs etc. under new terms if they want to include Google services.
Earlier quoted context omitted.
As a principal software engineer that works on Fuchsia, I can assure you that the project does not exist solely to retain me. :)
Since you're here, "abarth", it took me several clicks to get to the OWNERS file and all I saw was a list of email addresses. Calling that "governance" is... could we at least get some names and maybe brief bios on these people?
Looks like you still cannot contribute without granting copyright ownership to Google. In turn, GOOG licenses it out under a BSD (or BSD-like) license. This is a big difference relative to Linux, and its part of why Linux works so well as a collaboration between competitors. The GPL's copyleft acts as a joint development agreement between equals. IMO, Fuchsia's model only works well for integration partners that are…
> 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
I've heard Fuchsia referred to as a "principal engineer retention project" at Google. I'd be curious to know if others have heard the same.
As a principal software engineer that works on Fuchsia, I can assure you that the project does not exist solely to retain me. :)
Earlier quoted context omitted.
Well if I have the copyright I can straight up sell software based upon it without telling people you made it. Or I can release your code or derivatives of it under a different license while privately selling it under other licenses for profit. If these things don't bother you, then feel free to contribute. In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference,…
> In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference, then why would Google require the contribution in the first place? The difference isn't relevant 99% of the time, but it comes up if the maintainership of a work tries to re-license the work. Works without assigned ownership cannot practically be re-licensed, as you'd have to get individual consent from a…
Yeah I understand this. Hence there _is_ a difference and maybe one I don't prefer. I understand why Google would want this, but maybe I view Google's inability to relicense my code as a feature and not a bug.
In any case, I think the people involved in this back and forth essentially understand the state of things. I only seems some of us disagree on whether we should care. If people want to sign CLA's with Google that's their prerogative. If they understand what they're doing, more power to them. I don't like that Google has special preference over other actors, but that's just me.
edit:
> This came up a lot when GPLv3 was introduced — many projects wanted to migrate from GPLv2 to GPLv3, but couldn't, because they never acquired legal ownership of contributed code, and so didn't have the right to re-license the contributors' code.
Sure there are a lot of people who didn't like that, but maybe those who contributed their code under the GPLv2 never would have done so if they knew it would change to GPLv3 (not that he's more important than others, but Torvalds seems to fall in this camp)? Their wishes should be respected. Besides in those specific cases the projects could have avoided it by only accepting code licensed as "GPLv2 or later" so a CLA wasn't really required in that case anyway (though obviously that only applies to this specific GPLv2 -> GPLv3 case and not more generally).
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.
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 capabilities are going to/from. An process can do nothing that is not provided by the capabilities it got during creation.
Of course, components might be buggy/malicious and leak capabilities. But the security holes bottleneck in this capability routing scheme, so even with buggy/malicious components, it's much easier to audit and fix. And from an attacker perspective, it's much harder to reach a component given the routing path of capabilities that it's received.