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

451–460 of 561 posts

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

#451

Post by socmag »

michaelmrose wrote: post #249

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

Just for correctness sake, the quote from the article:

"a post-API programming model"

looks like it came directly from the source repo.

https://fuchsia.googlesource.com/modular/+/master

/----------------- Modular

Modular is the application platform of Fuchsia.

It provides a post-API programming model that allows applications to cooperate in a shared context without the need to call each other's APIs directly.

/-----------------

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

#452

Post by fixermark »

logicchains wrote: post #324
isoos wrote: post #231

Earlier quoted context omitted.

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

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

Typescript is definitely an improvement over type-free JS, but it's still wedded to the JS type system so unfortunately, it will still let you shoot yourself in the foot in ways you might not anticipate if you have experience with other languages with a stronger type system.

For example, If you have a string-typed foo and a number-typed bar, "foo + bar" is still a valid statement in TS because they have to maintain backwards-compatibility with JS's unfortunate language design choices.

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

#453

Post by pjmlp »

noobermin wrote: post #412
pjmlp wrote: post #339

Earlier quoted context omitted.

> 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

Sorry but you are nowhere near the mean. We can't use your experience as a stand-in for the mean.

Sure, but we cannot use your words either.

Do you have an study available that I can refer to?

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

#454

Post by fixermark »

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…

This reduces to the old argument that the Four Freedoms model of open-source software is basically moot in a world where the value of software is dominated by network effect, not modifiability.

It continues to be a weakness of the Four Freedoms model.

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

#455

Post by jerf »

mncharity wrote: post #68

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

Some people seem to have skimmed over the discussions about the pros and cons of garbage collection and come away with the idea that all garbage collected languages function by stopping the world for 50-100 millisecond pauses four or five times per second, minimum. There are real performance issues that GC can create, but there's a looooooot of vigorous overstating of the issues.

Slightly in those people's defense, it is true that while GC relieves you of the need to track lifetimes and worry about using dead pointers, it doesn't relieve you of the need to consider performance as one of many factors that go into your code. So while I think the performance issues of GC'd languages are very frequently overstated, it definitely is true that a UI framework written in a GC'd language by someone who isn't giving any thought to performance implications of allocation can very quickly exceed its targets for 60 fps, let alone 120 fps, even on very simple GUI screens. But that's only maybe 10% the fault of garbage collection... 90% is that someone is writing a GUI framework without realizing they have to pay a lot of attention to every aspect of performance because GUI frameworks are very fundamental and their every pathological behavior will not only be discovered, but be encountered quickly by all but the most casual programmers. It doesn't take long before someone is using your text widgets to assemble a multi-dimensional spreadsheet with one text widget per spreadsheet node or something, just as one example.

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

#456

Post by manmal »

bitL wrote: post #333
fauigerzigerk wrote: post #323

Earlier quoted context omitted.

Sounds like something that could be used for customizing a CMS a little bit, but software development is something very different from what you're describing. Developing software requires understanding of completely open ended natural language. NLP is nowhere near that level of AI and doubt that it will be in the next 30 years.

Yes, but when you talk to regular people and their needs for web pages, apps, they are often either very trivial or unbearably complex. You can potentially automate away those very trivial with the current state of ML already, and there is a bulk of money there that goes to a lot of independent developers and smaller companies. And once you have such a system built, you can extend it as new advances in ML/GPU come, a…

Yes, some are very easy to implement, just look at squarespace's customers. One could build an NLP interface (bot?) to configure squarespace sites and this would take you quite far. Not sure I'd call that AI though.

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

#457

Post by fixermark »

scott_karana wrote: post #145
Inconel wrote: post #83

Earlier quoted context omitted.

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.

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.

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

#458

Post by MarkMc »

sedatk wrote: post #248
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…

Android is already dominant on mobile. Desktop market is shrinking. "Running" doesn't correlate to a good experience. Google probably thinks about that stuff.

Actually the PC market has stopped shrinking and is now about steady: http://www.gartner.com/newsroom/id/3468817

'Running' can be pretty good, even when it's not a native app - there are plenty of successful web apps, including a few written by Google.

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

#459

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

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

#460

Post by manmal »

wapz wrote: post #24

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.

Why not bend the rules a bit before omitting vital components?
Post reply on HN