Hacker News Reader

Comment by relics443 | Hacker News Reader

I find it hard to believe that 8+ years of APIs and OS level code would be abandoned just like that, especially given the scale of Android.

If this ever happens, it would probably be an extremely slow, well thought out (hopefully), well documented (also hopefully) rollout.

View on HN

They've already replaced Dalvik with ART for bytecode and it was mostly transparent from what I understood.

But popping up with a completely new platform API without any backwards compatibility would be very bold and risky. There would have to be a good compatibility story there.

Also there is talk in the article about a POSIX layer. Now that's easier said than done. But it is Google we are talking about so they certainly have the manpower and resources to try.

It isn't too hard to do Linux ABI emulation. The interface there has mostly been stable for the last several years. That would enable just using the same userspace as Linux distributions like Android.

A new runtime is very different then a new framework/API/OS. The former doesn't necessarily require code changes (dalvik -> ART did not), the latter requires new everything.

The Android API wouldn't be going anywhere. That's what I say in the article - Fuchsia would continue to support the Android API seamlessly.

They did not. ART is here on-device architecture-specific and version-specific; Dalvik bytecode is still the portable bytecode used in all APKs. If they had replaced it, we wouldn't still be dealing with the 65k methods limit for example.

Exactly. This sort of switch seems for me also a good way to increase the amount of bugs by a large scale. It may only work for very specific hardware I think.

Job security and Apple-ish custom OS may long-term reduce support burden because Linux is like OpenSSL: a giant refrigerator, stove, oven, typewriter, glass kiln, laundromat kitchen-sink. It will take a very long time to reinvent the wheel and also deliver a PG "quantum of improvement," but there are plenty of Alphabet employees to do it. Also, similar Apple, it's an OS they control so there's less rejection / ignorning of Google's desired direction as with FLOSS.

You grossly overestimate Googles ability to support an OS on multiple platforms. Do you remember the why Samsung Galaxy Nexus was abandoned?

Apple supports iOS on two platforms (32-bit and 64-bit A-series). Microsoft who has been in the OS business much longer than than Google only have resources to support Windows 10 Mobile on a handful of carefully chosen Qualcomm chips.

So basically the only way this could work is if Google would create their own SoC and mandate Android vendors to only use that SoC. I don't think Samsung would like that too much.

That's a given. Google also needs to control the hw platform to be successful. Open platform equals shoddy service/product because it would require adding a Microsoft-sized operation.

Allow me to disagree. Open platform works great when people collaborate.

Google has not collaborated with the Linux community.

I agree. Why throw out the whole stack: kernel, APIs, and applications?

OTOH, why is Google developing the Fuchsia? It is clearly more than a hobby project.

You wouldn't have to do it all at once. You'd emulate the Linux user space, and do everything incredibly gradually. Both APIs would be supported for many, many years. But they could stop advancing the Android API within a shorter timeframe.

That's what I'm saying :) An (extremely) gradual phase-out of the Android API.

I'm not sure the API can ever really be phased out due to the vast amount of legacy apps and libraries.

Besides I'm sure a lot of developers wouldn't be happy that their domain knowledge just went flying through the window. Even if that is a risk inherent in the job.

Extremely, extremely? :) Apple kept Carbon apps running on OS X for a very long time.

Reply on news.ycombinator.com