Live data from Hacker News

Google’s not-so-secret new OS

techspecs.blog

141–150 of 561 posts

Re: Google’s not-so-secret new OS

#141
post #117

Earlier quoted context omitted.

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 def…

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.

You missed the biggest difference: Chrome is the same everywhere.

Re: Google’s not-so-secret new OS

#143

Earlier quoted context omitted.

But the thing is, you really can fork. There's nothing preventing forking. I think you're complaining about merging. But every open source project has standards about what they merge. Try getting a patch into Linux and see what they say; it won't be a rubber stamp.

Yeah, you can fork. Take AMP or Android for example. With AMP, the instant you fork and change a single character of code it becomes incompatible because part of AMP is a verifier that makes sure only the official version is used with Google's cache. Without being able to serve your custom AMP pages from Google's AMP cache the entire point to its existence goes away. The reason? Typical "security". "Tampered" version…

>And Android. Android used to honor the promise of being open. Years ago. This was before every manufacturer was encouraged to lock bootloaders, and back when platform SDK's and drivers for hardware were generally available even if they were kinda hard to get. This was also before the Android kernel heavily diverged from mainline Linux, and before "google play services" grew from a tiny app to a framework that powers half the OS features.

The only thing Google is directly responsible is Google Play Services, and

1. A good of that is a shim to Google's servers.

2. Is small and emulate-able (especially if you don't really intend to connect to their servers).

3. One can run plenty of apps without it. Mostly Open Source, but I've heard of people running CM without Google Play. I've never heard anyone run Windows 10 or iOS in OpenSource mode only.

Re: Google’s not-so-secret new OS

#144
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.

Re: Google’s not-so-secret new OS

#145
post #83
post #51

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 platf…

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 heav…

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.

Re: Google’s not-so-secret new OS

#146
post #117

Earlier quoted context omitted.

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 def…

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.

"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".

Re: Google’s not-so-secret new OS

#147
post #117

Earlier quoted context omitted.

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 def…

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.

[deleted]

Re: Google’s not-so-secret new OS

#148

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. ;)

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).

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.

Re: Google’s not-so-secret new OS

#149

Earlier quoted context omitted.

On OS X all my stuff syncs between my iDevices

But I don't have an iPhone, I have an android phone, I use syncthing, but this isn't the kind of sync I hope, I want both the OSes to be quite same with inbuilt sync not through the internet but through my LAN

What exactly are you trying to sync? For music/files rsync is great.

Re: Google’s not-so-secret new OS

#150
post #74

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 li…

I worked with a company that was part of the beta for ARC Welder and it was a very experimental product experience. Things were hit or miss on chromebooks. Support from Google engineers was amazing though.
Post reply on HN