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

301–310 of 561 posts

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

#301

Post by whatusername »

e98cuenc wrote: post #266
reacweb wrote: post #222

Earlier quoted context omitted.

IMHO, the history was different. Java applets were initially secure in a sandbox and faster than what was possible with the "javascript" of that era. Applets have become slow to start many years latter when bloated "enterprise" applications have been produced in abusive ways. The security of applets has started to deteriorate a bit slightly before the death of Sun. It has become a security hell only since it is in th…

The startup time was horrible . The speed, once it was running, was good, but the startup time made it completely unusable on the web. The ugly default UIs in Java did not help. I did my fair share of applets back in the day, starting with the very first public versions and have very vivid memories of the loading screen :)

I always wonder -- if Sun had forced people to build their own loading screen UI per applet -- how the perception of Java (and Java Applets) would be different.

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

#302

Post by thewhitetulip »

flukus wrote: post #149
thewhitetulip wrote: post #39

Earlier quoted context omitted.

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.

I have syncthing for syncing files, that isn't an issue. I want a universal OS which allows me to just plug my phone into my machine at home and it'll do magic and I can then continue my work. I have no other alternative than reading when I am on the bus. I want the mobile to be a native extension to the laptop

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

#303

Post by TeMPOraL »

pjmlp wrote: post #286
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…

> The only way they can get more of your money is to sell you a new phone which they hope to do between 1-2 years from now. The thing is, this only works on countries similar to US where most people are on contracts. In the rest of the world, where people are on pre-paid, we use our phones until they either die or get stolen, which is way more than just 1-2 years.

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.

Between that and fragility of smartphones (mechanical damage, water damage), most people are bound to replace theirs every few years anyway.

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

#304

Post by leadingthenet »

RyanZAG wrote: post #199
xiaoma wrote: post #86

Earlier quoted context omitted.

Given that it's Google, I wonder if it will support the languages favored by bootstrappers and small startups—Obj C, Ruby, JavaScript and more recently Swift and Elixir. I get the distinct impression that they're heavily optimizing large team productivity and aren't a fan of functional or highly expressive languages. It's too bad, given how much nicer their app approval process, etc is than Apple's that the Android d…

Well going off common sense, it seems likely that Obj C and Swift definitely would not be supported on purpose.

I wouldn't write Swift off yet.

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

#305

Post by discreteevent »

maheart wrote: post #153

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…

I think he is just making it up as he goes along. If you look at the fuschia docs or newsgroups all it says is that it they are working on this OS and intend to combine it with flutter to make a fast platform.

Nobody says anywhere that it will replace android. It looks just like a lot of these other Google projects. They put people on it. If turns into a contender then they might use it but if in the meantime android introduces features that make it more competitive then maybe they will throw fuschia away. That's my understanding anyway.

Also: "I have very strong reservations about Dart as the language of the primary platform API" and then later... "I am not a programmer"

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

#306

Post by zigzigzag »

eklavya wrote: post #299
mark242 wrote: 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.

What? Android runtime is not JVM, it's AOT compiled to native for quite some time now.

It's a mix, actually.

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

#307

Post by bertrand-caron »

throwawaydbfif wrote: post #228
caltelt wrote: post #111

Earlier quoted context omitted.

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.

I've used a ton of languages over the years and vastly prefer Java type syntax when working on larger projects. The forced organization tends to lead towards some level of mandatory code clarity. Something greatly lacking in Js land. OO is a bad word these days and functional is all the rage, even though functional languages were largely superceded by OO languages eons ago for many reasons people are slowly redicover…

Could you elaborate on how "functional languages were largely superceded by OO languages eons ago for many reasons people are slowly redicovering" ?

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

#308

Post by TeMPOraL »

flukus wrote: post #158
MarkMc wrote: 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?

> How many of these web apps obey the native OS themeing for instance?

Forget the theme - how many of these web apps obey the native OS GUI features? TAB-navigation, arrow navigation (in e.g. lists), accelerator shortcuts, editing shortcuts, not to mention a lot of visual idiosyncrasies that together make the interface feel "right"? Ironically, if you use default HTML controls, most of the things will be OK on a decent browser. But no, designers and developers absolutely have to make it worse by applying tons of CSS and JavaScript.

This applies to web apps pretending to be mobile apps, too. You can quickly tell one from another; the web app is the one with mediocre UI that behaves "wrong" in more or less subtle ways.

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

#309

Post by innocentoldguy »

throwawaydbfif wrote: post #212
innocentoldguy wrote: post #200

Earlier quoted context omitted.

JavaScript sucks because it has a weak standard library, ugly syntax, and its monopoly in web development has the industry stuck in a state of mediocrity, in my opinion. I have a VERY hard time believing that the apex of engineering intelligence and ingenuity is found in JavaScript. Also, as much as I love Elm, for instance, languages that transpile to JavaScript are just lipstick on a pig, and do little to solve the…

I agree with you that JavaScript sucks balls in far more ways than is reasonable for such a widely used language. The design is seriously shit when compared directly to really any popular language, even PHP. I disagree with transpilers not being a reasonable answer. Eventually JavaScript will be okay to work with, some day. Until then, transpilers offer nearly unlimited freedom in redesigning the bad parts of the lan…

I can see your point about transpilers. Of all the transpilers I've used, I like Elm the best, due to its functional nature, syntax, strong typing, compiler, and debugger. It isn't fully stable yet, as a language, and there have been breaking changes in each release since I started using it, but it offers the most promising departure from JavaScript. I guess anything that facilitates the de-turding of web development in general is a good thing.

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

#310

Post by pjc50 »

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…

There's one design decision in Linux that makes this slightly harder than it needs to be in this situation: Linux's lack of a driver ABI.

At the moment, phones include all sorts of custom drivers for very specific versions of the hardware. The OEMs ought to send these upstream, but don't want to. You can't build your own kernel and upgrade without breaking all the binary-only drivers.

Android falls between two stools. Google own the userland but the OEMs are responsible for updates and the SOC manufacturers (mostly Qualcomm and Mediatek) are responsible for closed-source drivers. Arguably the cleanest and least achievable way out of this is trying to have an OS-only phone.

Post reply on HN