Hacker News new | ask | show | jobs
by krylon 3098 days ago
I wish Google was more outspoken about their plans for Fuchsia. So far, all we have is a lot of speculation.
3 comments

I think they don't know themselves what will become of it. It's more a research project similarly to Midori.
I think there's a lot more going on than they are publicly letting on.

If the general public starts to believe that there is an Android successor in the works, many people will stop buying Android devices until further notice. This could be absolutely catastrophic for the Android device market.

If I were Google, I would bury the name Fuchsia, call the thing Android 10, and let it be known that it's years out.

>If the general public starts to believe that there is an Android successor in the works, many people will stop buying Android devices until further notice.

The bigger danger is the response by android developers. Will you invest in a soon-to-be-deprecated Android Native app written in a soon-to-be-deprecated API (because, at least according to the Internet rumors, Fuchsia will be using Dart instead of Java and will have a totally different API), rather than just write it in Xamarin, Cordova or React Native?

And once your apps aren't written in Android API, how hard is it to port to, say, Windows Phone?

This damages their moat.

>Fuchsia will be using Dart instead of Java

The current sysui is flutter/dart based, Flutter is google's newish mobile app sdk, the guys who started it have work on the chrome team, it's in alpha and has support android and ios.

https://github.com/fuchsia-mirror/sysui "Armadillo is currently the default system UI for Fuchsia. Armadillo is written in Flutter"

Here is an example of a rust programme, Xi editor, using flutter for the ui. https://github.com/fuchsia-mirror/xi

This is silly. No way they would launch such a thing without ART support. Even ChromeOS is running Android apps now.
From what I understand, with Dart/Flutter you can write apps for Fuchsia, iOS and Android with the same codebase. I think this could be interesting for devs. If making Fuchsia apps is easier and more pleasant than making Android apps, developers will respond positively.
Yes, this is more like it. Most likely it was someone's 20% project (if it still exists) and someone higher up the command saw some potential in it and gave them more resources. Google can afford it. At worst, it can fail, at best it can give Google a technologically superior OS. Plus, they can always use parts of it or lessons learned from it elsewhere.

There is also no reason they can't replace Linux underneath Chrome OS with new Foundations. After all Linux internals were never exposed to the consumers in Chrome OS. As long as they port Chrome, they should be able to do it at least theoretically. Same theory could apply to Android but that would be much harder to do I think.

Yes, and there are tons of research OSs. Most of them suffer from a lack of Hardware support. I'd be ready to switch to OpenBSD/Solaris/QNX/other fancy OS tomorrow if all my HW components were supported.

I doubt anything non-Linux based is ever becoming popular within the next 100 years. ;)

They don't need to replace Linux in one big event. They'll probably test and safely move some working ideas to their production OSes (similarly as Span was introduced in .NET from Midori).

There is also some effort in abstracting device drivers in Android (Project Treble) but how it could be used in Magenta is not clear.

Personally I'd be really interested in seeing this OS deployed in production. I like Linux but it's XXI century, we should be slowly adopting basic security principles in our OSes (capabilities, microkernels). But I fear that Magenta will look similar to Android, while it is open source Google will internally use a customized version that the customers will not be able to compile themselves.

Sure, it could be a process and Project Treble goes in the right direction.

However it's insane if you consider how many device drivers there are for Windows and Linux. The large majority of Linux kernel code is drivers. When you consider that Linux still has problems to run on certain hardware, then the problem becomes more obvious.

My bet is, in case this ever becomes a success, then only for a subset of vendors that are willing to cooperate closely with Google. (Oh yeah, and everybody needs to throw away the old hardware.)

I wished efforts would instead go into improving Linux Kernel. It reminds me of Google saying that JavaScript is a complete dead end and must be replaced. So they created Dart which surely has a great design but nobody uses it - and JS is now better than ever.

Moreover it's a bit of a lame excuse that vendors don't update their Android modifications. It already start that Google doesn't manage to get their Linux kernel modifications into the mainline Kernel - almost violating OpenSource principles...

If you're manufacturing the hardware as well as the software , this is less of an issue.

Getting a new OS to run on a new cellphone, or laptop is a surmountable task.

It’s entirely open source (including development and roadmap documents).

Do you mean their product vision? If so, why does it matter when it already exists?

It matters hugely. If Fuchsia is a research project, then I'd keep an eye on it for engineering inspiration. But if Google's leaders plan to promote it as a serious replacement for Chrome and Android, then businesses might want to invest in Fuchsia app development.
I think the strategy is to make Flutter an attractive tool to build mobile apps across Android, iOS and Fuchsia (it already runs on all three today). Even in an alpha stage, it is a really productive framework for mobile development.

So if Flutter hits 1.0 or beta sometime next year, you would have a way to develop mobile apps for today's platform which will require a smaller investment to run on an eventual Fuchsia platform.

More specifically Fuchsia driver development. That's where it substantially differs, e.g. video drivers run in user space rather than being kernel modules.

For Chrome and Android apps, that's just a bunch of user space APIs/ABIs so it doesn't really matter what the kernel is if the abstraction has been really rigorous from the outset (in Chrome and Android).

There probably are no intricate plans for the future on an executive level, besides having some smart people enjoy their work while building something that may or not be useful in the future, depending on a) how their effort, and b) the future turns out.