Live data from Hacker News

Google’s not-so-secret new OS

techspecs.blog

181–190 of 561 posts

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

#181
post #87
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…

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.

Maybe you somehow haven't noticed that even mobile devices now are an order of magnitude faster than desktop computers were back in the days of applets. Desktop computers can run Java applications with no significant overhead.

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

#182
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…

Phones and desktops are completely different form factors with different constraints. Running an Android app on Windows would be a horrible experience.

I don't know. I think many "tablet" apps would work fine on the Surface 4 (if they got scaling right).

I still think touch screens is the future - also on desktops (there either in tablet form or "drafting table" form).

I think editors more like acme and less like vim might rise up. Along with new input types like the power bar and surface wheel.

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

#183

Earlier quoted context omitted.

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…

First up - I do not argue with you. Android is not as open as it was in the old days. But I think its not fair to only blame Google here. Google making Google play services was a natural reaction to manufacturers never updating Android on their phones for years leading to all kinds of vulnerabilities and bugs on Android that kept it far behind iOS in quality and features. Lets face it - Android used to be sneered at,…

Google is 100% to blame.

There are these things called contracts, and if there are clauses for an OEM to be allowed to have access to Google services, Google lawyers could certainly add a few more sentences regarding compulsory updates.

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

#184
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…

Phones and desktops are completely different form factors with different constraints. Running an Android app on Windows would be a horrible experience.

Now this is a reasonable objection. Small form factor touch screen interfaces just don't work the same way as mouse-based desktop interfaces with acres of space. Trying to use a phone UI on a desktop is heinous (as is pointed out above with Windows 10 as the example.)

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

#185

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

> 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: * Rest of the world: I'd als…

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.

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

#186

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…

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

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

#187
post #181
post #87

Earlier quoted context omitted.

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.

Maybe you somehow haven't noticed that even mobile devices now are an order of magnitude faster than desktop computers were back in the days of applets. Desktop computers can run Java applications with no significant overhead.

Not totally. We support a number of java applets at work. The clients still take "way too long" to load and feel bloated. "Way too long" is a subjective measure based on the current hardware/OS. For a JVM to not feel slow it would have to speed up relative to itself...and I haven't seen them do that.

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

#189
post #158
post #146

Earlier quoted context omitted.

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

> 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?

> Actually they suffer from most of the same problems, only computers have gotten faster (masking performance issues)

If an issue no longer affects anyone in any way, is it still an "issue"? Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.

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

#190
post #171

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

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

Java is not using a VM on Android since ART was introduced, although on Android 7, it is a bit more complicated, given the mix of pure Assembly interpreter, PGO driven JIT and AOT compiler.
Post reply on HN