Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google’s not-so-secret new OS

techspecs.blog

Post reply on HN
Print view View original

111–120 of 561 posts

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

#111

Post by caltelt »

frik wrote: post #91
throwawaydbfif wrote: post #56

Earlier quoted context omitted.

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

Microsoft is lobbying to get their favorite syntax into JS6/7. Who wanted the class syntax? etc And TypeScript and WebAssembly are part of their plan. Ultimately, they want to recompile their 27 year old Office codebase from C/C++ to web browser.

To be fair, it seems to me like the typical webdev coming from C#/Java really wants the class syntax. I disagree with it, but I don't think it's just MS that's pushing it through, and even if it is, there's definitely an audience for it.

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

#113

Post by stcredzero »

gigatexal wrote: post #35
thewhitetulip wrote: post #15

Earlier quoted context omitted.

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

And can a universal OS be everything to a power user and still be useful to a beginner?

This is what Smalltalk was intended to be, back in the day. The answer is yes, but you may not be able to get more than a few people to adopt it anyways. (There were no smartphones back then, but it did get to the point where grade school children, professional developers, and researchers were using basically the same programming environment, just with customized interfaces for their particular group.)

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

#114

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

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

#116

Post by djsumdog »

throwawaydbfif wrote: post #95
skybrian wrote: post #69

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…

Hardware made a big difference with Linux and its growth. It could run on PC/x86, alpha, sparc because those are platforms. ARM is a spec sold to manufactures that all have their own SoC that attach random shit to random pins and implement the worst kernel hacks that can never be upstreamed.

http://penguindreams.org/blog/android-fragmentation/

We can't have the 90s Linux revolution for handhelds because they each need customized kernels and drivers. Many fall into disrepair and go unmaintained, even in things like Cyanogen. (On two phones I tried running newer CM images on old hardware and ran into speed and performance issues).

This is why things like Plasma and Ubuntu mobile have such limited phone support. Porting is difficult.

Also notice that I said "PC" above. There are plenty of x86 systems that are just as difficult to port to (PS4, Wonderswan, those old T1 cards with 4x486 processors on them). At least Microsoft forced their ARM manufactures to use UEFI. Too bad those platforms have locked bootloaders. I'd love to see some Lumia running Plasma.

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

#117

Post by josefx »

mark242 wrote: post #87
MarkMc wrote: 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.

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.

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

#118

Post by jpfr »

vii wrote: post #53

It's awesome that Google is doing this and in public too 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 devi…

Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1].

And on mobile devices, many hardware component vendors provide custom drivers (with binary blobs) anyways. It will not be hard to convince them to support Fuchsia for new hardware releases. If they loose access to Android otherwise...

[1] https://en.wikipedia.org/wiki/Rump_kernel

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

#119

Post by djsumdog »

therealmarv wrote: post #114

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

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

#120

Post by dragonwriter »

bitmapbrother wrote: post #82
MarkMc wrote: 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…

The amount of additional code required to support Android apps on the Chrome browser would be far too great. No one wants to download a 500MB+ browser.

> The amount of additional code required to support Android apps on the Chrome browser would be far too great. No one wants to download a 500MB+ browser.

So, divide up by services, and download only the services needed by installed apps with the first app that needs them. Adds basically nothing to the browser install.

Post reply on HN