
Google’s not-so-secret new OS - techenthusiast
https://techspecs.blog/blog/2017/2/14/googles-not-so-secret-new-os
======
michaelmrose
It was unfortunately obvious that the writer had insufficient tech chops when
use the phrase

"a post-API programming model"

But pressing on how somehow manages to blame the lack of updates to android
phones on the modularity of the Linux kernel. The joke of course being that
linux is monolithic and googles new OS is a microkernel ergo more modular.

The quote is "...however. I also have to imagine the Android update problem (a
symptom of Linux’s modularity) will at last be solved by Andromeda"

Its hilarious that he can somehow defying all sanity ascribe androids update
issue to an imagined defect in Linux. Android phones don't get updated because
for the manufacturers ensuring their pile of hacks works with a newer version
of android would represent a non trivial amount of work for the oem whom
already has your money. The only way they can get more of your money is to
sell you a new phone which they hope to do between 1-2 years from now.

In short offering an update for your current hardware would simultaneously
annoy some users who fear change, add little to those who plan to upgrade to a
new model anyway, decrease the chance that a minority would upgrade, and cost
them money to implement.

Its not merely not a flaw in the underlying linux kernel its not a technical
issue at all.

~~~
pjmlp
> The only way they can get more of your money is to sell you a new phone
> which they hope to do between 1-2 years from now.

The thing is, this only works on countries similar to US where most people are
on contracts.

In the rest of the world, where people are on pre-paid, we use our phones
until they either die or get stolen, which is way more than just 1-2 years.

~~~
TeMPOraL
Bump it to 3-4 years then. Bloated manufacturer updates combine with bloat in
most popular applications and the regular web bloat to make the phone unusably
slow after few years.

Between that and fragility of smartphones (mechanical damage, water damage),
most people are bound to replace theirs every few years anyway.

~~~
pjmlp
> Bump it to 3-4 years then. Bloated manufacturer updates combine with bloat
> in most popular applications and the regular web bloat to make the phone
> unusably slow after few years.

My S3 is 4 years old now, and it is works perfectly fine.

When it dies, I will most likely adopt one of my Lumia devices as main one, or
will buy a 2nd hand Android device, instead of giving money to support bad
OEMs

~~~
TeMPOraL
My SO's S3 is of more-less the same age and it's so slow that it's barely
usable now. Still can't track down why - she is not a power user, she wasn't
installing apps beyond the few things I installed her and the OS updates. My
old S4, currently used by my brother, suffered the same fate, being slow even
after a factory reset. I wonder where this comes from?

~~~
pjmlp
I had some performance issues, but they got sorted out when swapped the
battery for a new one.

~~~
TeMPOraL
A _battery_? How would that help? Not doubting you, just honest question. I
feel like I'm missing something very important about how smartphones work.

~~~
the_af
Mmm... it also happened to me with my (now defunct) Galaxy S1. I can't explain
it, but at some point its battery developed the "bloated, about to explode"
look and the phone worked but it was very slow and crashed frequently. I
changed the battery and everything was ok. Later it died of unrelated causes.

------
MarkMc
It bothers me that Google does not seem particularly interested in doing the
one thing that would make their Android platform absolutely dominant: Allow
Chrome to run Android apps on Mac and Windows.

Google has already done 90% of the necessary work by adding Android apps to
ChromeOS. _Two and a half years ago_ it created "App Runtime for Chrome" which
demonstrated that Android apps could run on Windows and Mac in a limited,
buggy way [1]. If Google had put meaningful effort into developing such a
strategy we would by now have a relatively simple way to develop software
which runs on 99% of laptops and 85% of smartphones and tablets. Developers
would now be targeting 'Android first' instead of 'web app first then iOS then
maybe Android'.

Sundar, if you're reading this - do it!

[1] [https://arstechnica.com/gadgets/2014/09/hack-runs-android-
ap...](https://arstechnica.com/gadgets/2014/09/hack-runs-android-apps-on-
windows-mac-and-linux-computers/)

~~~
mark242
Sun tried that, back in the day. Maybe you heard about Java applets, maybe you
didn't. They were the slowest thing about the web, insecure even with a
sandbox, and just an overall pain. Short of having a jvm always running on
your machine, the performance of Android-via-Chrome will completely turn
people off the Android ecosystem.

~~~
josefx
I remember two issues with Java Applets:

* Java itself was slow for a long time

* The Browser would hang while loading an Applet

The first is no longer an issue. They can just use a modern just in time
compiler and it wont run slower than Java on Android. Chrome already has one
to deal with JavaScript powered Web 2.0 applications.

The second was as far as I can tell an API issue. Applets would block
everything by default until they were loaded. A really bad idea in a single
threaded environment when you had to send several MB over low bandwidth and
the JVM itself took long to start. Just making the load async with a
completion callback could have solved this issue and I remember a few Applets
that actually used an async download to reduce the hang.

~~~
username223
You missed the biggest issue: "write once, mediocre everywhere." Windows, Mac,
and X were all different, and Java Applets were necessarily bad at emulating
all of them. While there are fewer Unices today, there are more GUIs, and
cross-platform apps suck at least as much.

~~~
MarkMc
"Write once, mediocre everywhere" was a problem with Sun's implementation, not
with the concept of cross platform code. There are tons of webapps which are
very successful, despite being written 'once'.

In any case, Google doesn't need to be as strict as Sun was. It is free to
implement "write 90% of your code once and 10% customised for each platform".

~~~
flukus
> There are tons of webapps which are very successful, despite being written
> 'once'.

Actually they suffer from most of the same problems, only computers have
gotten faster (masking performance issues) and our expectations have lowered.
How many of these web apps obey the native OS themeing for instance?

~~~
mercer
1) The fact that webapps _can_ run relatively well strikes me as hopeful,
considering how much more inefficient using HTML/CSS/JS is compared to Java
applets. Or is the latter not the case (honest question)? 2) I'm not sure if
our expectations have lowered much. Perhaps it's more that _mobile_ interfaces
are generally simpler and thus easier to make 'native enough'?

Although I think there's more going on in regards to 2. I was never bothered
so much by the UI of a java applet looking different. What bothered me was
that even very fundamental stuff like input fields and scrolling felt both
alien and shittier than native. And while it's certainly possible to make a
web app just as shitty, if you rely on 'stock' html elements, a lot of the
subtle native behavior carries over.

Just a few weeks ago, for example, I built a web-app for mobile devices. It
felt off immediately because the scrolling didn't feel right. All I had to do
was turn on the momentum scrolling (with a line of ios-specific css), and the
scrolling suddenly felt native. Had I used a hypothetical Java applet
equivalent, I might've had to either go for a non-native-feeling scroll or
build it myself.

While I of course can't prove any of this, I think what people care about is
that things _feel_ native, not the 'skin' used to display it.

~~~
flukus
> considering how much more inefficient using HTML/CSS/JS is compared to Java
> applets. Or is the latter not the case (honest question)?

It's a really interesting question actually because it's so hard to compare
the two. On any objective measure, today's web apps are much better than
applets in terms of responsiveness, etc. But then again, an applet could run
on machines with 16MB of RAM total. I think you'd be hard pressed to get plain
html page in a modern browser to run on a machine like that. Either way, in
both cases we had a much better solution in native apps.

> 2\. I was never bothered so much by the UI of a java applet looking
> different. What bothered me was that even very fundamental stuff like input
> fields and scrolling felt both alien and shittier than native.

Modern web apps can score better here, but quite often they don't. The more
complex the become the less native they get, scrolling, text input, etc are
generally OK (unless your an arshole that overrides scroll behaviour), but
html still doesn't have an equivalent for native table views and the goodies
(navigation, resizing, performance) that comes with them.

For me the skinning does matter though, I have a beautiful, consistent desktop
that browsers (not even electron apps) shit all over. When something doesn't
look quite right from the second you open it it magnifies all the other
differences.

~~~
mercer
> Modern web apps can score better here, but quite often they don't. The more
> complex the become the less native they get, scrolling, text input, etc are
> generally OK (unless your an arshole that overrides scroll behaviour), but
> html still doesn't have an equivalent for native table views and the goodies
> (navigation, resizing, performance) that comes with them.

Oh yeah, complex UI stuff is definitely a good reason to avoid web apps.

But for many, probably even most apps it's precisely scrolling, text input,
and other 'basic' stuff that matters, and in those cases a web app's 'default'
will be more native.

> For me the skinning does matter though, I have a beautiful, consistent
> desktop that browsers (not even electron apps) shit all over. When something
> doesn't look quite right from the second you open it it magnifies all the
> other differences.

I agree on a personal level, but I suspect we're outliers. Can't substantiate
that at the moment though, so I might be wrong.

------
vii
It's awesome that Google is doing this and in public too
[https://fuchsia.googlesource.com/](https://fuchsia.googlesource.com/)

Unfortunately, the hard part of an operating system isn't in a cool API and a
rendering demo. It's in integrating the fickle whims of myriad hardware
devices with amazingly high expectations of reliability and performance
consistency under diverse workloads. People don't like dropped frames when
they plug in USB :) Writing device drivers for demanding hardware is much
harder than saving registers and switching process context. The Linux kernel
has an incredible agglomeration of years of effort and experience behind it -
and the social ability to scale to support diverse contributors with different
agendas.

Microsoft, with its dominant position on the desktop, famously changed the
'preferred' APIs for UI development on a regular cadence. Only Microsoft
applications kept up and looked up to date. Now Google has such a commanding
share of the phone market - Android is over 80% and growing
[http://www.idc.com/promo/smartphone-market-
share/os](http://www.idc.com/promo/smartphone-market-share/os) \- they have a
huge temptation to follow suit. Each time that Microsoft introduced a new
technology (e.g.
[https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio...](https://en.wikipedia.org/wiki/Windows_Presentation_Foundation)
WPF) they had to skirt a fine line between making it simple and making sure
that it would be hard for competitors to produce emulation layers for.
Otherwise, you could run those apps on your Mac :)

There are many things to improve (and simplify) in the Android APIs. It would
be delightful to add first class support for C++ and Python, etc. A project
this large will be a monster to ship so hopefully we'll soon (a few years) see
the main bits integrated into more mainstream platforms like Android/Linux -
hopefully without too much ecosystem churn

~~~
npsimons
> It's in integrating the fickle whims of myriad hardware devices with
> amazingly high expectations of reliability and performance consistency under
> diverse workloads.

So much this; Linux Plumbers conference years ago was bitching about how every
gorram vendor wanted to be a special snowflake, so even though the
architecture was ARM, you basically had to port the kernel all over again to
every new phone. I haven't kept up with it, but I can't imagine it's gotten
better. The problems they're listing as reasons to move to a new kernel aren't
caused by Linux and they won't go away until you slap the vendors and slap
them _hard_ for the bullshit they pull, both on developers and users.

As for kernel ABI, this has been rehashed to death: just release your fucking
driver as open source code, and it will be integrated and updated in mainline
_forever_ :
[http://www.kroah.com/log/linux/free_drivers.html](http://www.kroah.com/log/linux/free_drivers.html)

~~~
bjackman
Overall I agree with your sentiment but it's not just a case of "releasing
your drivers" but also of getting it accepted by maintainers. If you don't
have an awareness of this process from the beginning of your development cycle
then it can be a massive amount of work.

------
conradev
The drivers-wifi repository contains a stub for a Qualcomm QCA6174 driver[1]
which is found in the Nexus 5X[2], OnePlus 2[3] and meant for smartphones[4].
The drivers-gpu-msd-intel-gen repository contains drivers for Intel 8th and
9th gen integrated graphics[5]. I think it's fair to propose that Google plans
on running Fuchsia on both smartphones and laptops…

[1] [https://github.com/fuchsia-mirror/drivers-
wifi/blob/master/q...](https://github.com/fuchsia-mirror/drivers-
wifi/blob/master/qualcomm/driver.cc)

[2]
[https://www.ifixit.com/Teardown/Nexus+5X+Teardown/51318#s112...](https://www.ifixit.com/Teardown/Nexus+5X+Teardown/51318#s112148)

[3]
[https://www.ifixit.com/Teardown/OnePlus+2+Teardown/45352#s10...](https://www.ifixit.com/Teardown/OnePlus+2+Teardown/45352#s100455)

[4] [http://www.anandtech.com/show/7921/qualcomm-announces-
mumimo...](http://www.anandtech.com/show/7921/qualcomm-announces-
mumimo-80211ac-family-increasing-the-efficiency-of-80211ac-networks)

[5] [https://github.com/fuchsia-mirror/drivers-gpu-msd-intel-
gen/...](https://github.com/fuchsia-mirror/drivers-gpu-msd-intel-
gen/blob/master/src/device_id.h)

------
resoluteteeth
Is this an actual plan of Google as a company, or is this some sort of
Microsoft-style war between divisions where the Chrome team has just decided
on its own that the future is based on Chrome and Dart?

Also, considering the way that the ARC runtime for Chromebooks was a failure
and had to be replaced by a system that apparently essentially runs Android in
a container, will it really be possible for a completely different OS to
provide reasonable backward compatibility?

~~~
throwawaydbfif
I would say that Google is trying to replace JavaScript with dart in any way
they possibly can. The reason is simple, JavaScript is an open standard, dart
is owned by google.

Their reasons that "dart is better" is the typical google koolaid before they
attempt a market takeover. As we've seen over and over with Android, chrome,
and AMP especially. Google loves to make glass house open source projects you
can't touch. You're free to look at how great it is, feel it's well refined
curves and admire the finish, but God help you if you don't like how the
project is going and want to fork it for yourself.

Don't bother trying to commit a new feature to any of Google's software that
they don't agree with. It will languish forever. Don't bother forking either,
because they'll build a small proprietary bit into it that grows like a tumor
until it's impossible to run the "open source" code without it.

Fuck dart, I don't care how great it is. Microsoft is being the good one in
this case by extending js with typescript, google is trying to upend it into
something that they control

~~~
isoos
Looks like alternative facts have reached the tech world too?

You can take as hard look at Google as you would like, but choosing Microsoft
over Google (one for-profit company over another), while not caring how the
technology, the licensing or the workflow compares is a bit hypocrite.
(e.g.they are both open, and they both have rules of commits).

I'm wondering, why do you need a throwaway for such heavily invested FUD? Your
other comments here are in similar tone, and I'm surprised to see such hatred
without any obvious trigger. Maybe if you would come forward with your story,
it would be easier to discuss it?

disclaimer: ex-Googler, worked with Dart for 4+ years, I think it is way ahead
of the JS/TS stack in many regards.

~~~
logicchains
>I think it is way ahead of the JS/TS stack in many regards.

In what ways do you consider it ahead of Typescript? Personally as someone
who's particularly fond of static type systems (Haskell and the like),
Typescript's type system seems way more advanced and powerful than Dart's
(union and intersection types, in particular, and non-nullable types). Map
types (introduced in Typescript 2.1) also seem pretty interesting.

~~~
isoos
Some of my earlier notes are in this thread (it is more about the day-to-day
feature I actually use and like, and less about the fine details of the type
system)
[https://news.ycombinator.com/item?id=13371009](https://news.ycombinator.com/item?id=13371009)

Personally I don't get the hype around union types: at the point where you
need to check which type you are working with, you may as well use a generic
object (and maybe an assert if you are pedantic).

Intersection types may be a nice subtlety in an API, but I haven't encountered
any need for it yet. Definitely not a game-changer.

I longed for non-nullable types, but as soon as Dart had the Elvis-operator
(e.g. a?.b?.c evaluates null if any of them is null), it is easy to work with
nulls. Also, there is a lot of talk about them (either as an annotation for
the dart analyzer or as a language feature), so it may happen.

Mapped types are interesting indeed. In certain cases it really helps if you
are operating with immutable objects, and mapping helps with that (although
does not entirely solves it, because the underlying runtimes does allow
changes to the object).

~~~
throwawaydbfif
I agree about union types. They can quickly result in insane variable
declaration statements that are hard to understand.

I dislike nulls though, I always wish people would just use a flag or error
handling when objects are undefined, instead of "hey this object is the flag
and sometimes it's not actually an object!"

You'd think language designers would learn after dealing with null pointers :)

------
maheart
How credible is this source?

I don't understand half the decisions outlined in the article.

> I also have to imagine the Android update problem (a symptom of Linux’s
> modularity)

I seriously doubt the Linux kernel is anything but a minor contributor to
Android's update problem. Handset developers make their money by selling
physical phones. In two years, your average consumer probably doesn't care if
their device is still receiving software updates. They'll jump onto a new
phone plan, with a fresh, cool new mobile, with a better screen, newer
software (features!), and a refreshed battery.

Maintaining existing software for customers costs handset manufacturers $$$,
and disincentives consumers purchasing new phones (their cash cow). The money
is probably better spent (from their POV) on new features, and a marketing
budget.

~~~
felixge
> In two years, your average consumer probably doesn't care if their device is
> still receiving software updates. They'll jump onto a new phone plan, with a
> fresh, cool new mobile, with a better screen, newer software (features!),
> and a refreshed battery.

This might be true for the US, where 75% of subscribers are on post-paid
(contracts). It's not true for the rest of the world.

* Europe: < 50% post-paid

* Rest of the world: < 22% post-paid

I'd also argue that Android users will be more likely to be pre-paid than
post-paid customers (compared to iPhone users) in all of these regions, but I
have no data to back it up.

Anyway, I agree that it's probably not very profitable, if at all, for android
handset makers to support their devices for > 2 years. But I think many
customers would benefit from it ...

[1] [http://www.globalrewardsolutions.com/wp-
content/uploads/GRS-...](http://www.globalrewardsolutions.com/wp-
content/uploads/GRS-Mobile-Top-up_Wireless-Market-Statistics-2015.pdf)

~~~
ianai
I think the "post paid" connection leading to a 2 year lifecycle is suspect.
There's a big after market repair industry in the US. Many people have a
singular cell phone as their internet device - and it's often ancient by IT
terms. 2+ year old hardware needs to be getting software/OS upgrades.

~~~
majewsky
I favor the proposal of requiring a prominent "Best Before" date for new
devices, indicating how long the manufacturer will guarantee the availability
of security updates.

~~~
ianai
That's an SLA and we should all b getting them.

------
untog
If nothing else comes out of this, I hope we end up with an Android OS that
works better than the current one.

I've been running Android since the Nexus One so I'm no newbie to the
platform, but the ease with which iOS manages to get all UI interactions at
~unnoticable FPS and outstanding battery life is staggering when you're used
to Android. It feels like some really fundamental choices were made badly on
the platform that make it incredibly inconsistent and unreliable. A fresh
start would be fantastic.

~~~
Inconel
As a fellow Nexus user, I've owned the Nexus One, 5, and currently use a 6P,
how much of this is due to the OS versus hardware? Will Google ever be able to
achieve Apple level battery life or overall UI smoothness, not to mention
update support, without having their own custom SoC?

I was very happy with the 5, even with the intermittent lags, especially
considering it's price at release. I suppose I'm not a very heavy phone user,
and I never play mobile games, but I've been very happy with the 6P on Android
6.0-7.1. Battery life could definitely be better, and it does get fairly warm
at times, but overall it's been a very good experience for me considering the
Snapdragon 810 it's using is generally poorly regarded.

~~~
scott_karana
Apple has had fluid UIs since the start, despite off-the-shelf, low resource
Samsung SoCs. They only started making custom ones after with the 4S, as I
recall.

~~~
fixermark
Yep. Out of the starting gate, Apple forced tight constraints on background
and multi-threaded processing---so tight that the first versions of the iPhone
OS couldn't support some types of application that the Android OSs could
unless Apple wrote the program and could take advantage of the private APIs in
the OS. But the advantage to that B&D approach was responsiveness and battery
life, relative to an Android OS where any developer could write an app that
would spawn an ill-behaved background thread and suck your battery.

------
mncharity
> I don’t see the average garbage-collected language using a virtual machine
> allowing for a target higher than 60fps realistically.

But... " _average_ garbage-collected language using a virtual machine" doesn't
describe _any_ of C/C++, Dart, Go, Java, Python, or Rust. Nor Javascript.

I get greater than 60 fps with my existing Vive three.js WebVR-ish
electron/chromium linux stack. Even on an old laptop with integrated graphics
(for very simple scenes). Recent chromium claims 90 fps WebVR, and I've no
reason to doubt it. So 60 fps "up to 120fps" seems completely plausible, even
on mobile.

~~~
saghm
> But... "average garbage-collected language using a virtual machine" doesn't
> describe any of C/C++, Dart, Go, Java, Python, or Rust.

I'm curious; what would be an example of something you would describe as an
"average garbage collected language using a virtual machine"? Java would
certainly be the first language I'd think of for that description.

~~~
munificent
> I'm curious; what would be an example of something you would describe as an
> "average garbage collected language using a virtual machine"?

Ruby 1.8, Lua, or CPython.

~~~
saghm
Python was included in the list of things considered not to be in this
category; I probably agree with you on that one, but the idea behind my
question was that the languages listed as not "average garbage-collected
language using a virtual machine" included several that I'd include in that
category.

What do you think makes Ruby and Lua more "average" than Java?

------
grizzles
Since Fuscia is a new kernel, that means it will probably only support Google
hardware.

The status quo right now among android hardware vendors is to violate the GPL,
and they have faced few if any repercussions for doing so. I wonder if Fuscia
is sort of viewed as the way forward to addressing that.

Anyone care to speculate why there isn't a community version of chromium os?
I'd donate to it for sure. It sounds like getting android apps working on it
would be pretty easy:
[https://groups.google.com/a/chromium.org/forum/?hl=en#!topic...](https://groups.google.com/a/chromium.org/forum/?hl=en#!topic/chromium-
os-discuss/OfBln-hl7ug)

~~~
bitmapbrother
>The status quo right now among android hardware vendors is to violate the GPL

No it's not the status quo. The major OEM's do release their code. Yes, there
are some Chinese OEM violators, but that's typical of China.

~~~
grizzles
You can release code and still violate the GPL in other ways. For example,
there are binary blobs out there and the GPL is pretty unequivocal on this
point: "The source code for a work means the preferred form of the work for
making modifications to it."

~~~
simonh
It depends whether the binary blob is a derived work or not.

[http://yarchive.net/comp/linux/gpl_modules.html](http://yarchive.net/comp/linux/gpl_modules.html)

------
bitL
Seems like Free Software that propelled early Internet pioneers served its
purpose and those companies are turning their backs on it - first with Apple,
GCC->LLVM, now with Google, Linux->Fuchsia :( I am getting afraid of another
dark age on the horizon... I guess it's going to be inevitable as 90% of SW
developers will find themselves redundant when inferring AI capable of
composing code blocks and listening to/reading speech/specifications arrives
in upcoming decade, making creation of typical web/mobile apps trivial.

~~~
bashtoni
I think Google is probably the most Free Software friendly of the the new big
three (Amazon, Google, Microsoft). They haven't disappointed with Fuschia
which appears to be entirely copyleft:

[https://fuchsia.googlesource.com/magenta/+/master/LICENSE](https://fuchsia.googlesource.com/magenta/+/master/LICENSE)
[https://fuchsia.googlesource.com/fonts/+/master/LICENSE](https://fuchsia.googlesource.com/fonts/+/master/LICENSE)

~~~
Asooka
That's BSD-license though, which doesn't force companies to respect your
freedoms. Parent was talking exactly about GPL being dropped in favour of
licenses that allow vendor lock-in. It means a philosophical departure from
user-first towards corporation-first and the Free Software world the FSF
envisioned getting trampled.

The zeitgeist is moving towards conservatism in general, so it doesn't
surprise me, but it's still sad.

------
techenthusiast
Article author here. Posted this in the notes, but possibly too buried:

For anyone interested, I intend to write quite often about consumer technology
on this blog. Topics will include hardware, software, design, and more. You
can follow via RSS or Twitter, and possibly through other platforms soon.
Sorry for the self promotion!

Thanks for reading. Please do send any corrections or explanations.

~~~
jm_l
Hiroshi Lockheimer has publicly stated several times that there is no merger
of Chrome OS and Android.

[https://chromeunboxed.com/some-andromeda-perspective-
hiroshi...](https://chromeunboxed.com/some-andromeda-perspective-hiroshi-
lockheimer-emphatic-on-separate-oss-moving-forward/)

I think you alluded to this, "cue endless debates over the semantics of that,
and what it all entails," but it might be worthwhile to add the official
statement.

~~~
ktta
But there are frequent commits to multiple repositories on the fuchsia code
base[1]. I don't really see where Google is going with this, if it's neither
meant to replace chrome OS or Android.

Maybe a long term project? I think Google is at a position where they can
write a great OS from scratch, learning from the mistakes of others, and it
has a chance of becoming the greatest OS that ever was.

With the talent of it's engineers, they can bring new ideas that can be better
implemented, from scratch on a new OS. They already have a bunch of languages,
web frameworks, and so many more technologies from Google that can be well
integrated in this.

And looks like the project is mostly BSD licensed, which is great! I'm excited
for just that alone.

[1]:[https://github.com/fuchsia-mirror](https://github.com/fuchsia-mirror)

------
thinkloop
Why can't the pure web replace apps and programs? All the pieces are almost
there: hardware acceleration, service workers, notifications, responsive
design...

I currently "add to home screen" for most things. I edit my images online, and
develop code using cloud9 ide, etc. There are few things I need apps/programs
for right now, and that's improving day by day.

iPhone is dropping heavily in world wide market share, but they still have a
lot of the wealthy users. There is a non-zero chance they get niched out of
prominence by Android (aka every other manufacturer in the world), at which
point network effects start encouraging Android-first or Android-only
development. There might be a point where Apple needs to double down on the
web, and/or maybe kill off apps, like they did flash, to still have the latest
"apps".

~~~
Sanddancer
I take photos miles from where there's cell signal. I write code on the bus
while heading to doctors appointments. The web is about as far from a panacea
as you can get. It's slow, it's bloated, falls apart when you don't have a
connection, useful applications die when the company dies. Were some of the
midi devices I use for music "web-based" they'd have probably become doorstops
decades ago. A web-based IDE would be horrible for trying to develop code with
an intermittent connection. The web is not a good time.

~~~
fauigerzigerk
The intermittency issues can be fixed but I agree that the dependency on web
app providers and their fickle business models is scary.

The way it works is to funnel all the profits into a few huge conglomerates
that benefit from exclusive access to all personal data and train users to
never depend on anything that isn't a core product of one of these
conglomerates.

Using their 80% margins they can afford to at least give us some time before
scrapping software that doesn't look it's ever going to reach 4bn consumers.

The result is stability. Until they all get toppled by the next technology
revolution. Years later, regulators will crack down hard on some of the side
issues of their former dominance and once again miss the currently relevant
issues :)

------
therealmarv
This blogpost has waaaay too much assumptions. When reading about this it
seems easy to rip out Kernels, OS & Software and put it like a layer on a cake
on top of a new OS. Even for Google this is crazy complicated. It will not be
that easy. For sure not... and I also see no clear strategy WHY somebody
should do that. It's like baking the cake with too much ingredients. ;)

~~~
djsumdog
I can see the kernel thing happening. Just the licensing and breaking ABI is
one of the biggest factors in not being able to have an easily upgradable
android.

I only see this as a good thing if this ensures an easier upgrade path than in
Android; and if vendor ROMs can easily be replaced by a stock OS (like on
Windows).

~~~
therealmarv
I definitely can not see the Kernel thing happen. Ever thought of power
management and keeping the whole system fluent? This are all not easy problems
which you solve in 1 or 2 years. It may only work for very specialized
hardware... speaking of hardware. Hardware driver support is also something
most other Kernels suffer from in comparison to e.g. Linux.

~~~
Roy0
> Hardware driver support is also something most other Kernels suffer from in
> comparison to e.g. Linux.

So?

Google doesn't have to support all hardware, they can pick to support only the
hardware they want. That's what they already do with ChromeOS. Installing
ChromiumOS on unsupported hardware can have its issues. The reverse is true
too, installing not-ChromeOS Linux or another OS on Chromebook does not always
work well, although it's fine on some specific models.

Android is like that too, and in a much worse way than for Chromebooks. We're
not talking about stellar linux kernel support for all the custom ARM SOC that
are out there. All manufacturers write their own closed source hardware
support for android and this is how android ends up having issues with
updating, since whenever Google updates the linux kernel it breaks the ABI and
all the support manufacturers wrote for the previous version, and
manufacturers do not want to spend so much time on needless busywork such as
keeping up with kernel API churn that exists just to satisfy the dev team
sense of perfection.

------
Insanity
> IDEs written in Java are wildly slow…

My favourite IDE to use today is IntelliJ, and I prefer it over my experience
with Visual Studio (though to be fair, I did not use VS intensively in the
past 3-4 years).

I don't experience IntelliJ as "slow". It launches faster than VS did when I
used it, and once it is running I keep it open pretty much the entire work-
week without any issues.

~~~
pjmlp
Other than Netbeans and Eclipse being faster and don't turn my dual core into
airplane mode like Android Studio does, which forced me to enable laptop mode
on it.

~~~
Insanity
I don't really understand what you are trying to say, sorry :/

------
iainmerrick
"Fuchsia" and "magenta" are pretty gutsy names to choose, given how similar it
sound to Apple's vaporware "Pink" OS from the 90s (AKA Taligent, AKA Copland).
Somebody has a sense of humor!

It's really hard to tell if this is actually something that will ship, or yet
another Google boondoggle to be swiftly discarded (like the first attempt at
ChromeOS for tablets). Google under Larry Page built and discarded a lot of
stuff; I wonder if it's the same under Sundar Pichai.

[https://en.wikipedia.org/wiki/Taligent](https://en.wikipedia.org/wiki/Taligent)

~~~
JustSomeNobody
Sounds like a stretch having to go all the way back to the 90's to get a
similar color code name.

~~~
iainmerrick
It was the first thing those unusual names made me think of. But I'm a long-
time Mac developer, so probably pink and purple colors as OS names won't have
the same connotations for other people.

------
camdenlock
This could be the first time Apple needs to truly worry about Google. The one
massive lead Apple still has over Google (and the other major players) is the
incredible OS they inherited back in 1997 and continue to extend and maintain
today.

Neither Android nor Windows nor Chrome OS nor your favorite Linux distro have
ever been able to truly compete with the NeXT legacy as it lives on in Apple.

Google is smart enough as a whole to see this, and so it's not surprising that
they're attempting to shore up their platform's competence in this particular
area. What IS surprising is that it has taken them this long.

Perhaps what's truly surprising is just how much mileage Apple has gotten out
of NeXT. It's astounding, and I know Apple realizes this, but I question
whether or not they know how to take the next step, whatever that may be. And
if Google manages to finally catch up...

~~~
jcranmer
> Neither Android nor Windows nor Chrome OS nor your favorite Linux distro
> have ever been able to truly compete with the NeXT legacy as it lives on in
> Apple.

I find this a funny statement. Apple has not seen runaway success in terms of
market share, not on desktop platforms (where the top OSes are various
versions of Windows), not on mobile platforms (where it is a distant second to
Android in the worldwide market), not on server or supercomputer platforms
(where it's effectively nonexistent).

Nor is it influential in terms of operating system paradigms. The only thing I
can see people citing as a Darwin innovation is libdispatch. Solaris, for
example, introduced ZFS and DTrace, as well as adopting containers well before
most other OSes did (although FreeBSD is I think the first OS to create the
concept with BSD jails)--note that Darwin still lacks an analogue.

~~~
glasz
it's not about market share. it's about profit share. android/ios may be 80/20
on market. but they are 20/80 on profit.

market share won't feed nobody. that's all apple needs to care about. just
look at their market cap and p/e ratio.

------
wapz
I'm a minority I know but I don't like material design because it's terrible
at "scaling." It looks great, it's beautiful, but you lose too much damn
functionality. When I had to redo apps to material design we had to completely
remove multiple buttons due to them not fitting material design standards. I
really hope they have some way to alleviate this problem without using 50px
icons for all the extra buttons.

~~~
manmal
Why not bend the rules a bit before omitting vital components?

~~~
wapz
They weren't _vital_ components but useful for the user. We moved most of the
"excess" buttons to the top bar and overflow menu but still had to remove a
button here and there completely (we still had the functionality in a
different part of the app it was just more tedious to use from our testing).

------
Nypro
So Google is going with a DartVM on this one. Dart is cool and all, but why
DartVM? It's the same restrictive model we have with Android (dalvikVM) where
you can only develop with languages that can compile down to Java bytecode. In
this case, however, we will be using languages that can transpile to Dart
source instead! Why not JavaScript engine? With the current movement with
WebAssembly, I see a lot potential use cases. The biggest point being the
ability to code in any language that compiles to wasm. The engine could be
exposed to communicate with the OS directly or sth. If they are going to
consider V8 alongside DartVM, then that would be cool. I truly hope they don't
repeat old mistakes.

~~~
thwd
Dart can compile to JS, so that edge is covered. Dart bytecode is arguably an
easier target for other language compilers than, say, assembly. The DartVM's
byte code is fully specified, there is some adoption, it's openly accessible,
and there's a bold, production-ready reference implementation. For wasm, only
half of that is true.

~~~
sp332
Compiling Dart to JS is a very different problem than compiling JS or other
languages to Dart.

~~~
thwd
I understand what you mean and agree. But then, you don't need to compile JS
into Dart. Rather, JS into DartVM byte code.

------
endorphone
Conjecture is fun, but the linked piece takes some enormous liberties with
crossing massive chasms effortlessly. Not only is Fushia _not_ Andromeda (a
project), the needs of IoT is massively different from the needs of Android.
And the net investment in Android is absolutely colossal, and making some new
APIs or a microkernel does not a replacement make.

------
sametmax
Google could have taken firefox and improve it to make it better, but they
created something new.

Now instead of improving the linux stack and the gnu stack (the kernel,
wayland, the buses, the drivers), they rewrite everything.

They put millions into this. Imagine what could have been done with it on
existing software.

They say they are good citizen in the FOSS world, but eventually they just use
the label to promote their product. They don't want free software, they want
their software, that they control, and let you freely work on it.

~~~
lossolo
Isn't Google paying to Mozilla for Google searches from inside search bar in
Firefox ? Isn't like main money flow for Mozilla? More people use Chrome, more
money Google saves. It's all about the data, making Firefox better didn't
benefit Google as good as creating new browser. Now they do not have to pay so
much for all their users searches to other companies and they have so much
more data that they can use internally for other products.

~~~
teddyh
No, that ended in 2014. Google no longer gives Mozilla anything.

------
mcguire
" _The pitch will clearly be that developers can write a Flutter app once and
have it run on Andromeda, Android, and iOS with minimal extra work, in
theory._ "

How's that going to work? iOS, specifically? Is Dart a supported language?

~~~
afsina
This may answer your question:

[https://flutter.io/faq/#how-does-flutter-run-my-code-on-
ios](https://flutter.io/faq/#how-does-flutter-run-my-code-on-ios)

and

[https://flutter.io/faq/#can-i-interop-with-my-mobile-
platfor...](https://flutter.io/faq/#can-i-interop-with-my-mobile-platforms-
default-programming-language)

~~~
mcguire
From the first link:

" _The engine’s C /C++ code is compiled with LLVM, and any Dart code is AOT-
compiled into native code. The app runs using the native instruction set (no
interpreter is involved)._"

Thanks!

------
brianon99
Google is just afraid of GPL I think.

~~~
ekianjo
So their strategy is to go full-blown closed source?

~~~
sreenadh
Open sourcing the product will help the competition to catch up quickly, all
they have to do is take googles product and change its look. The next half is
infrastructure, which companies like Microsoft, facebook, amazon, alibaba all
have. Plus services like AWS will help future version of dropbox & netflix.

A good example of that is Visual code. I am sure some at github (atom's
paprent) is pissed.

~~~
jryan49
Wikipedia says it's not a fork of atom but based on electron. Does that make a
difference?

------
dep_b
So in the near future billions of devices will no longer be running Linux
anymore? That would be quite a blow to the OS in terms of chances of
dominating operating systems that are being used by end users. Or will they
simply fork it and strip it down until only the parts they really like will
remain?

~~~
atoponce
This is also a concern of mine. What will this mean for rooting devices? Will
it still be root, or will it be "root" as it an iOS jailbreak?

------
yen223
Rust as a first-class language?

~~~
mastax
I believe the article over-sells Fuchsia's use of Rust. Raph Levien wrote some
bindings to the OS runtime, and he does work at Google, but his Rust work is
not-official.

(or that's the story as I remember it)

~~~
sametmax
Which is a shame, they are missing an opportunity to ditch C/C++ in favor of a
safer language and set a precedent in OS history.

Imagine how easier contribution would be if you could write the OS parts with
less lines, guarantied to no introduce most security and concurrency bugs we
know about.

------
Flenser
ANDROid + chROME + DArt = ANDROMEDA?

------
skybrian
re: "Flutter was [...]"

A bit weird to use the past tense here since it's not reached 1.0 yet. You can
try it out today (tech preview) to create apps in Dart that run on Android and
iOS:

[https://flutter.io/](https://flutter.io/)

(Googler, not on the Flutter team itself, but working on related developer
tools.)

~~~
techenthusiast
Fair point! Just fixed that, thanks. I had only meant that Flutter was not
originally intended for Andromeda, as far as I can tell :)

------
bsaul
Trying to see the other side of the coin : what economical reason is there for
this project ?

A company the side of Google, with all its internal politics, doesn't work as
a startup. Starting a third operating system project and hoping it to replace
two major ones means convincing people inside the company to loose part of
their influence. Now it may happen if chrome or android were failing, but
they're clearly not.

------
techenthusiast
I updated the article with the following clarification at the top:

I use Andromeda equivalently with Fuchsia in this article. Andromeda could
refer to combining Android and Chrome OS in general, but it's all the same OS
for phones, laptops, etc. - Fuchsia. I make no claims about what the final
marketing names will be. Andromeda could simply be the first version of
Fuchsia, and conveniently starts with "A." Google could also market the PC OS
with a different name than for the mobile OS, or any number of alternatives. I
have no idea. We'll see.

------
mankash666
I hope the userland is POSIX/Linux compliant. There's a TON of useful software
reliant on this compliance that will go to waste if it isn't compliant out-of-
the-box.

~~~
pjmlp
It doesn't seem to affect ChromeOS, iOS or Android.

------
shams93
As a sound/music app person the inclusion of ASIO for audio is exciting,
Google's new is should be on par with iOS for sound with ASIO audio drivers at
the core.

------
lenkite
AFAIK the flutter UI framework is a react-like framework written in Dart (with
C++ as OS glue) including the UI -> graphics rendering layer. It builds upon
Skia and Blink. I am not sure how that will allow compatibility with other
languages. The only language for UI apps looks to be Dart. Which isn't bad -
its a pretty well designed language, but I don't see how apps can be written
in a wide variety of language as the author suggests.

------
akmittal
>the main UI API is based on, yes, Dart

Won't the Dart's single thread nature be bad to take advantage of Murli core
processors? Or they are embracing web workers?

~~~
bitmapbrother
Dart, in the context of Fuchsia, isn't really a web based language. So yes,
it'll take advantage of multi-core processors.

------
bitmapbrother
The author calls it Andromeda OS, but is this really the Andromeda OS we've
been hearing about? I'm not so sure about that. What we do know right now is
that the OS is currently code named Fuchsia.

Fuchsia repository:
[https://fuchsia.googlesource.com/?format=HTML](https://fuchsia.googlesource.com/?format=HTML)

~~~
techenthusiast
There has been other reporting about this going back to last fall. I don't
think Fuchsia is the marketing name.

------
antoncohen
Link to the source code:

[https://fuchsia.googlesource.com/](https://fuchsia.googlesource.com/)

------
MichaelMoser123
The article says it's a microkernel, I wonder if it will be a more secure
general purpose OS, well windows NT started as microkernel but they changed
that wit NT 4,let's see if it will be different. I also wonder about driver
support and battery consumption. Good luck to Google.

------
sjtgraham
> The pitch will clearly be that developers can write a Flutter app once and
> have it run on Andromeda, Android, and iOS with minimal extra work, in
> theory.

This is worrying for Apple. I can see the following playing out

\- Apple continues releasing machines like the TB MBP, much to exasperated
developer dismay.

\- Other x86 laptop industrial design and build quality continue to improve.

\- Fuchsia/Andromeda itself becomes a compelling development environment

\- Developers begin switching away from Mac OS to Fuchsia, Linux and Windows

\- Google delivers on the promise of a WORA runtime and the biggest objective
reason not to abandon Mac OS, i.e. writing apps for iOS, disappears.

\- Apps start to look the same on iOS and Android. iOS becomes less
compelling.

\- iOS devices sales begin to hurt.

Granted that the App Store submission requires Mac OS (Application Loader) and
the license agreement requires you only use Apple software to submit apps to
the App Store and not write your own, but it seems flimsy to rely on that.

------
conradev
Here is a link to the documentation:

[https://fuchsia.googlesource.com/magenta/+/master/docs](https://fuchsia.googlesource.com/magenta/+/master/docs)

------
avmich
I didn't see in the article explanations why those decisions were taken and
not others. On the surface it feels like this is an OS insufficiently
different from others to justify switching to.

------
pier25
We definitely need a universal OS for all our devices and I really believe
Google is in a great position to get us there.

It would really surprise me if Apple got there first. Tim lacks vision and
will keep on milking iOS even if the iPad Pro is a failure as a laptop
replacement.

Windows is still king in the desktop space, at least as far a user base goes,
but it's terrible on tablets and phones. MS has all the tech in place with
UWP, but it's still pretty far in the race in terms of simplicity and
usability.

Chrome OS ticks all the right boxes, and is experiencing a huge growth, but
it's not universal. If Andromeda is real, and it's able to become a universal
OS that merges Chrome OS and Android it might be the best thing since sliced
bread.

~~~
thewhitetulip
Yes, we do. I want my phone and my laptop to be in total sync, I want to be
able to write code on my mobile which I can just continue on my laptop without
any hindrance, currently I have a mac and an android phone, I do have Go and
Python installed on my mobile, but it isn't that great to code on my mobile, I
have to host the repo on an internal version of gogs to get the code synced up
and I still have to manually push the code around.

All hail Universal OS!!

~~~
vlunkr
You could always develop remotely, use your phone to ssh into a more powerful
machine. Use tmux or screen and pick up right where you were on a laptop or
desktop. This is far more compelling IMHO.

~~~
mcguire
Tmux or screen? Wouldn't it be nice if there were a graphics-over-the-network
system?

~~~
lliamander
I remember the glee of the first time I got an X-Window application to run
over the network. I was so confused though because the "x-server" is the
software you run on your client machine.

~~~
mcguire
You and the _Unix Hater 's Handbook_ authors.

There is a small terminology issue here: a "server" is a program that offers
services to remote "client" programs. The clients make requests and the server
responds to them. A client program will make a request like "allocate me a
chunk of the screen and put these here bits in it", or "let me know about any
of these events that happen". The server manages the screen and notifies the
clients about things they're interested in.

 _IT MAKES PERFECT SENSE, DAMMIT!_

~~~
lliamander
This made me laugh (in a good way).

I agree, it actually does make total sense - but that doesn't mean I won't get
confused :).

My only prior exposure to "GUIs over the network" were web applications, where
the roles are essentially reversed. That is, the part responsible for
accepting user input and rendering the UI is the client (the browser), and the
part that performs the application logic is the server.

I naively assumed that X would work the same way, but it wasn't too hard to
unlearn that misconception.

------
gillianlish
guys i hate to tell you this, but it's Feb 15 here in New Zealand, and Google
has cancelled Andromeda.

~~~
solidsnack9000
[http://platypusplatypus.com/news/google-andromeda-isnt-
happe...](http://platypusplatypus.com/news/google-andromeda-isnt-happening/)

------
ungzd
I think it's intended for entertainment and content consumption just like
Android and Chrome OS. And Apple is trying the same with merging iOS and
desktop. How long it will take until all computers will be set-top boxes where
you can only netflix and chill and if you want, for example, to draw
something, you have to buy Professional Grade Computer for $50000?

------
am185
wow! it supports Golang, since it has glsl, this will have nice UI.

[https://fuchsia-
review.googlesource.com/#/q/project:third_pa...](https://fuchsia-
review.googlesource.com/#/q/project:third_party/go)

------
kzrdude
Does anyone have a more detailed explanation of the component called
“modular”?

------
xtat
Honestly I'd rather keep the linux and ditch the JVM

------
BrailleHunting
NIH syndrome plus large organization people looking for job security, and
rough, fat FLOSS full of maintenance and security vulns hell equals "Emperor's
new clothes."

------
HiroP55
The comment about Java based IDEs being slow is not entirely objective and
fact based. I'd say it's more of an emotional argument.

------
em3rgent0rdr
[https://imgs.xkcd.com/comics/standards.png](https://imgs.xkcd.com/comics/standards.png)

------
diebir
Quote: "I am not a programmer, so if anything stated above is incorrect,
please, please send me corrections. I would also greatly appreciate any
clarifying comments, which were one of my primary motivations for writing this
piece." Essentially a bunch of nonsense, in other words.

------
chatman
Microsoft is opening up more and more, and Google is closing down more and
more.

------
mtgx
It would be a real shame if Google wasted this once in a decade or perhaps
once in multiple decades opportunity to not have an OS written in a language
other than C++.

Also, it would be mind-boggling if they didn't actually fix the update problem
this time, and if it wasn't a top 3 priority for the new OS.

~~~
frozenport
It's written in C.

There is little beyond syntax that a different language can offer because a
modern OS cannot afford features like garbage collection. Indeed, this was one
of the research aims of MS's Singularity project.

~~~
sametmax
They could have written it in Rust. No garbage collection, more security
guaranties. Easier to contribute to the code properly.

~~~
frozenport
Rust performed 3x slower and hacking around the language made it somewhat of a
mess [1]. Much like Singularity, this is hardly a success story. Although
Singularity was interesting from a research perspective nobody doubted that an
OS could be written in Rust.

[https://scialex.github.io/reenix.pdf](https://scialex.github.io/reenix.pdf)

~~~
steveklabnik
That paper is very old, before Rust 1.0. There was also a lot of discussions
about ways that they could have used Rust better at the time, IIRC.

Today, there is no reason Rust should ever be 3x slower, especially in an
OSdev context, where you currently have to use nightly.

