Project Fuchsia: Google Is Quietly Working on a Successor to Android • Hacker News Board

Re: Project Fuchsia: Google Is Quietly Working on a Successor to Android

#211

Post by jacksmith21006 » Sun, Jul 22, 2018, 6:14 PM UTC

ahartmetz wrote: post #77

jokoon wrote: post #25

Apparently it uses a micro kernel, zircon. I'm curious about this kernel, honestly making something new from the ground up doesn't seem like a good idea. I wonder how much of an advantage it was for android to use linux as a kernel, but I guess it was a gigantic advantage, which let them focus on what mattered in the development of android. Other question: any kernel/OS developer here to explain if a micro kernel mak…

I'd like to know how Zircon compares to L4 (implementations). When I asked Tanenbaum at FOSDEM why he didn't pick L4 for Minix 3, he just got annoyed and seemed to think I was asking why he didn't just use the L4 OS (which doesn't exist) instead of creating Minix 3 - or something. In any case I didn't get a good answer. He could have created his own implementation if he wanted, L4 is just a specification with a few e…

L4 is not capabilities based. Probably the biggest reason was not used.

Google is looking at using the capability using a handle to remove some marchalling usually required by the kerrnel to improve IPC improvement beyond L4. L4 has done an excellent job with improving IPC performance but Google looks to take it even further.

Re: Project Fuchsia: Google Is Quietly Working on a Successor to Android

#212

Post by ashelmire » Mon, Jul 23, 2018, 11:55 AM UTC

fyi_see_fyi wrote: post #179

ashelmire wrote: post #174

Earlier quoted context omitted.

Glassdoor has avg total comp for senior swes at google at 193k...

I am very surprised if that's the case. For what it's worth, I just started at Google as a Senior SWE this summer. My base is in the 180s. With an average annual bonus, my moving/starting bonus, and stock grant (ignoring stock price movements), my first four years should be 400ish...very high 300s really. BTW, https://www.levels.fyi/ is another source of data which might prove useful 190 total comp is more in line wi…

That's a pretty great package... brb applying to work at Google.

Re: Project Fuchsia: Google Is Quietly Working on a Successor to Android

#213

Post by forgot-my-pw » Mon, Jul 23, 2018, 7:16 PM UTC

puzzle wrote: post #166

nostrademons wrote: post #127

Earlier quoted context omitted.

> Have you worked for a FAANG? I was at Google for 5.5 years and was the beneficiary of an engineer-retention project for a year of that. I'm now working on a startup. Think of it from the company's perspective: they have an engineer who has already been "paid off" in the sense of having generated more revenue for the company than they are likely to get in salary during a lifetime, and is likely independently wealthy…

There's more: Cos and the open source Vanadium, John Hanke and Ingress/FieldTrip, Niniane and Lively, Hartmut and the quantum lab, Craig N-M and google.org, etc. But you left out the largest retention side project: Jeff Dean and Brain.

Google Brain has been pretty awesome for academia: https://ai.google/research/pubs/?team=brain

Re: Project Fuchsia: Google Is Quietly Working on a Successor to Android

#214

Post by on_and_off » Mon, Jul 23, 2018, 11:10 PM UTC

Analemma_ wrote: post #129

menckenjr wrote: post #99

Earlier quoted context omitted.

Then, of course, there's this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

I would argue there's a difference between "rewriting the project" and "building something new based on additional decades of experience in the domain". Taken too literally, your comment suggests we should never e.g. write a new filesystem. Should Apple have taken Joel's advice and stuck with HFS+ forever? Sometimes the world changes enough that you can't keep grafting onto the old system, and need a new one. I don't…

So much this.

IF you consider that there are some fundamental flaws in the Android Framework at the surface level, either oversights or just based on what the landscape looked like 10 years ago, then we have to reach a tipping point where it makes more sense to do a full rewrite than to continue building on this codebase.

FWIW, there are major incremental improvements made at each release, most of them with very few changes to the high level APIs.

The VM itself evolves at each release and has even been completely replaced from Dalvik to ART. The permission system has moved from install time (designed by engineers .. ) to iOS-like incremental runtime permissions.

Not everything can be updated that way though. So it might be worth redesigning the OS with better assumption about its usage and by totally rewriting the APIs from scratch in order to avoid the mistakes made by Android (of course Fuchsia will also make some mistakes in its APIs .. all immense projects do, it does not mean that it can't improve on Android)

And I don't think the OP article applies very neatly here. Android is still being worked on and is constantly improved. We are not in a situation where Android's development is going to freeze for 5 years while Fuchsia is being worked on. Completely different teams work on the 2 projects.

If anything, Fuchsia has a lot of pressure in order to catch up with Android. And it might want to start supporting kotlin so that the dev experience gap is not too wide and to add an Android VM for retrocompat before starting to consider competing with Android.