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

201–210 of 334 posts

Re: Expanding Fuchsia's open source model

#201

Post by Jnr »

rhn_mk1 wrote: post #126
snazz wrote: post #108

Earlier quoted context omitted.

I'm guessing that most of these pseudonymous developers—of which there can't possibly be too many—would distrust Google enough not to contribute even if it were easier to do so without a Google Account.

As a pseudonymous developer, I fail to see any harm in contributing to projects run by Google in general. Fuchsia is not a monopolist way to exert control over the market (not today at least), it doesn't seem to be explicitly made for evil, and can be forked to let the community steer it.

I would not be surprised if Google account ToS has some point that complicates things for contributors or people forking the code. I haven't read Google ToS lately so I can't say there is something like this but that document is huge and keeps changing all the time.

If I was a pseudonymous developer, I would probably not go through that.

Re: Expanding Fuchsia's open source model

#202

Post by taneq »

zlynx wrote: post #180
Andrew_nenakhov wrote: post #157

Earlier quoted context omitted.

You can easily sideload an app, sure. But recent version of Android restricted background running of the apps, making developers dependent on push notifications, and FCM notifications won't work without Google services.

On the first hand, I really appreciate the 30 - 40 hours of battery runtime my Pixel 5 has now. Restricting background apps is a big part of this.

If only there were some way to let the phone's owner decide what apps were allowed to run in the background, we could all be happy.

Re: Expanding Fuchsia's open source model

#203

Post by yegle »

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…

For more context, if I recall correctly, phh is the first person outside of Google to figure out this Generic System Image thing, and has been tinkering around Project Treble ever since.

(And I just learned about the GSI image for Pixel 1/2, thanks for that!)

Re: Expanding Fuchsia's open source model

#204

Post by PaulDavisThe1st »

gpm wrote: post #170
PaulDavisThe1st wrote: post #91

Earlier quoted context omitted.

> If I want to distribute derivative works of the Linux kernel, I need to release those works to all. This is false. The GPL does not require you to make source code available to anybody who asks, only those you distribute the software too (in source or binary form). If you modify a GPL'ed application and then distribute that to 3 friends, those friends have the right to ask for the (modified) source code. Nobody els…

Incorrect, under GPLv3 if you do not distribute the source with the object, anyone with a copy of the object code is entitled to request the source code if you do not distribute the object code with the source code. I.e. if those friends give it to someone else your obligation to provide source follows the object to someone else. (This is a short and incomplete summary of section 6). GPLv2 is even more stringent, if…

I was not commenting on GPLv3. But even so, your first paragraph does not contradict what I wrote. You're also incorrect: there is no transitivity to providing source. Section 6 makes clear that if your offer of source relies on someone else's server (i.e. you are redistributing the work but do not control the location where the source is available): "Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements". These clauses in the GPL cover you the person distributing a copy of the work, not "them" (the people who gave you a copy of the work).

You're incorrect about GPLv2. Section 3 states that if you distribute the work "in object code or executable form", you have to do one of 3 possible things:

  1. accompany the object/executable with machine readable code
  2. accompany the object/executable with a written offer of access to machine readable code
  3. accompany the object/executable with the same information you received with the object/executable. (This option is only available for non-commercial distribution)
So you're simply completely wrong about this.

Re: Expanding Fuchsia's open source model

#205

Post by TACIXAT »

anp wrote: post #150
TACIXAT wrote: 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.

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)

I think you are implying this by putting just in scare quotes, but it is one of the most impactful things we can do for the security of native code.

Re: Expanding Fuchsia's open source model

#206

Post by phh »

yegle wrote: post #203
phh wrote: post #156

Earlier quoted context omitted.

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…

For more context, if I recall correctly, phh is the first person outside of Google to figure out this Generic System Image thing, and has been tinkering around Project Treble ever since. (And I just learned about the GSI image for Pixel 1/2, thanks for that!)

Thx

GSI isn't specifically for Pixel 1 and 2, but they can use those, just like every other device whose OEM have abandonned them, since it is a generic image.

Re: Expanding Fuchsia's open source model

#207

Post by owaislone »

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.

Re: Expanding Fuchsia's open source model

#208

Post by jasonvorhe »

schappim wrote: post #51
jtsiskin wrote: post #38

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.

Just for clarification, is Fuchsia running on Google home in production (I.e. on public devices)?

I think I remember reading that Home/Nest Hubs run on their Chromecast Linux platform instead of Android Things.

Re: Expanding Fuchsia's open source model

#209

Post by gpm »

PaulDavisThe1st wrote: post #204
gpm wrote: post #170

Earlier quoted context omitted.

Incorrect, under GPLv3 if you do not distribute the source with the object, anyone with a copy of the object code is entitled to request the source code if you do not distribute the object code with the source code. I.e. if those friends give it to someone else your obligation to provide source follows the object to someone else. (This is a short and incomplete summary of section 6). GPLv2 is even more stringent, if…

I was not commenting on GPLv3. But even so, your first paragraph does not contradict what I wrote. You're also incorrect: there is no transitivity to providing source. Section 6 makes clear that if your offer of source relies on someone else's server (i.e. you are redistributing the work but do not control the location where the source is available): "Regardless of what server hosts the Corresponding Source, you rema…

So we agree we're talking about the second option in GPLv2 then right? Here is the relevant text with the relevant portion emphasized (in italics since hn doesn't have bold).

> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

GPLv3 has transitivity not GPLv2, but GPLv2 doesn't need it because it already specified any 3rd party.

Edit: Reread what you wrote, GPLv3 b (i.e. written offers) has transitivity, I do think that GPLv3 d does not (but does distribute the source simultaneously with the binary in some sense).

Re: Expanding Fuchsia's open source model

#210

Post by mlinksva »

snvzz wrote: post #177
twh270 wrote: post #149

Is there any comparison between Fuchsia and the Genode OS, which is also capability-based? I'm wondering what one has/does that the other doesn't?

Fuchsia is an OS. Genode's a framework for creating operating systems. It's not comparable. What's interesting imho is to compare seL4 with zircon. The former is a third generation microkernel. The latter is still a first generation microkernel or, according to google, not a microkernel at all. It's thus not very interesting from a computer science perspective. In practical terms, I'm sure it'll be better than Linux…

How about an OS using the Genode framework, Sculpt OS https://genode.org/download/sculpt IIUC, compared to Fuchsia? Apart from their kernels, which you've addressed.
Post reply on HN