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

441–450 of 561 posts

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

#441

Post by drewg123 »

pjc50 wrote: post #310
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…

"Linux's lack of a driver ABI."

RedHat Enterprise Linux actually solved this with their kABI. This allows vendors to ship binary driver RPMs for kernels in the same RHEL major version (eg, RHEL 4, RHEL 5, etc). However, this entails a major effort on the part of RHEL, as it forces them to carefully backport improvements from upstream in a slow and careful way, so as to avoid breaking binary compatibility.

The RHEL kABI model was quite nice to deal with as a 3rd party NIC vendor (and you had to do it, even if you upstreamed your drivers, as they were frequently not backported to RHEL/Centos at a rapid clip, so RHEL customers would be using ancient buggy drivers unless you put together a driver RPM for them).

However, the source changes to support all the backports were something else entirely (which you needed if you wanted support for newly backported features). For a 10GbE driver that was roughly 2000 lines of C, I had a roughly 1000 line hand-made configure script, roughly 1/2 which was checks made necessary due to RHEL's backports. Checks that could have been a simple check to see what the linux kernel version was were complex spaghetti, trying to detect how many arguments some function took. This is because EVERY kernel was 2.6.18 for RHEL5, even if it had backports from 10 or more versions higher.

I'm guessing that Google felt that it was better to invest in building an OS they could control from the ground up, rather than hiring a building full of people to backport upstream patches in a binary compatible way.

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

#442

Post by drewg123 »

dTal wrote: post #349
pjc50 wrote: post #310

Earlier quoted context omitted.

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…

>The OEMs ought to send these upstream, but don't want to. Isn't this a rampant GPL violation? Why do we put up with this? We are about to lose the war for general purpose computing due to insufficient GPL enforcement.

Dealing with the upstream linux community is a painful, time-consuming process. A lot of hardware vendors would rather just not bother, and release their source code to maintain GPL compliance, but never attempt to upstream anything because the process is so time consuming, with little to no immediately apparent upside. This is especially true if they are a parts supplier with a handful of large customers who don't care about upstream support.

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

#443

Post by syntheticnature »

pmilot wrote: post #367
snvzz wrote: post #362

Earlier quoted context omitted.

> Its not merely not a flaw in the underlying linux kernel its not a technical issue at all. I believe he's talking about having a driver API. Fuchsia also runs its drivers in userspace, which is the proper design in a post-Liedtke world. (principle of minimality)

Even when talking about driver updates, the argument is nonsensical. Android updates already require a full reboot of the device at the end of the update process, so new drivers can (and are) already be loaded into the kernel. The update problem on Android is indeed a policy issue, not a technical one.

Based on what I've seen elsewhere in these threads, the idea is that a stable driver ABI means that manufacturers/chipmakers need not rewrite drivers just because there is a kernel update, removing that as a block to doing said kernel update. The willingness of Qualcomm to do the driver updates for a given chip to work with the latest kernel in Android was a big determiner of which phones have any chance of getting the latest Android, for example.

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

#444

Post by digi_owl »

TeMPOraL wrote: post #373
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

My SO's S3 is of more-less the same age and it's so slow that it's barely usable now. Still can't track down why - she is not a power user, she wasn't installing apps beyond the few things I installed her and the OS updates. My old S4, currently used by my brother, suffered the same fate, being slow even after a factory reset. I wonder where this comes from?

Personal experience suggests that Android (or perhaps Linux?) slows down as the internal storage fills up.

Also, the GC on older Android devices is a mess. It does not take many apps hanging out in the background before things slow to a crawl.

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

#445

Post by pookeh »

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

You should also take into account that internet speeds of that era were not as great. Today, we download multiple megabytes of javascript. Back then downloading the same multiple megabytes of java was slow because of network.

At least that was the case for me...

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

#446

Post by ianai »

majewsky wrote: post #378
ianai wrote: post #185

Earlier quoted context omitted.

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.

I favor the proposal of requiring a prominent "Best Before" date for new devices, indicating how long the manufacturer will guarantee the availability of security updates.

That's an SLA and we should all b getting them.

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

#447

Post by pjc50 »

flukus wrote: post #363
pjc50 wrote: post #310

Earlier quoted context omitted.

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…

> 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. This is just an excuse. The reality is the manufacturers still have the mentality that once something is sold their responsibility ends. We see the exact same results on certain OS's that do have stable ABI's. You've probably made a transaction recently on a device that uses an o…

> You've probably made a transaction recently on a device that uses an old and unpatched version of windows CE.

I'm still shipping software for WinCE4.2 devices. They're supposed to be on their own little LAN segment, not bridged to the internet, with a border PC managing them. The upgrade path would almost certainly both an expensive nightmare and possibly infeasible - they have exactly enough Flash for the OS they shipped with.

It's really a cost-benefit tradeoff; all these software updates cost money. Who pays for that, under what circumstances, and why?

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

#448

Post by Certhas »

flukus wrote: post #363
pjc50 wrote: post #310

Earlier quoted context omitted.

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…

> 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. This is just an excuse. The reality is the manufacturers still have the mentality that once something is sold their responsibility ends. We see the exact same results on certain OS's that do have stable ABI's. You've probably made a transaction recently on a device that uses an o…

So if we had a stable ABI the manufacturer writes a driver, ships, and forgets about it, and the driver just continues working when I update the OS.

Thus, with what you describe, the argument can be made that the Linux driver model doesn't appropriately take into consideration the incentives and needs of hardware manufacturers.

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

#449

Post by teddyh »

lossolo wrote: post #424
sametmax wrote: post #398

Google could have taken firefox and improve it to make it better, but they created something new. Now instead of improving the linux stack and the gnu stack (the kernel, wayland, the buses, the drivers), they rewrite everything. They put millions into this. Imagine what could have been done with it on existing software. They say they are good citizen in the FOSS world, but eventually they just use the label to promot…

Isn't Google paying to Mozilla for Google searches from inside search bar in Firefox ? Isn't like main money flow for Mozilla? More people use Chrome, more money Google saves. It's all about the data, making Firefox better didn't benefit Google as good as creating new browser. Now they do not have to pay so much for all their users searches to other companies and they have so much more data that they can use internal…

No, that ended in 2014. Google no longer gives Mozilla anything.

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

#450

Post by MikusR »

TeMPOraL wrote: post #373
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

My SO's S3 is of more-less the same age and it's so slow that it's barely usable now. Still can't track down why - she is not a power user, she wasn't installing apps beyond the few things I installed her and the OS updates. My old S4, currently used by my brother, suffered the same fate, being slow even after a factory reset. I wonder where this comes from?

It's Google services. It's a huge library that's only growing larger.
Post reply on HN