Hacker News Reader

Comment by kuschku | Hacker News Reader

The real problem with it is Linux. Here's a few facts:

The Kernel has no stable ABI for drivers.

Manufacturers only ever develop a driver for their chips once, and then send that to the OEM. They never update.

The Linux Kernel LTS gets 2 years of updates, Google's fork about 4.

From the day a Kernel is released, to the day it ships in a phone, usually 2 years are spent integrating the blobs and code drops from the chip manufacturers.

On every kernel upgrade that breaks the ABI, those 2 years would have to be redone from scratch.

Linux can't mainline support for every exotic piece of hardware that ever shows up in a device.

Manufacturers can't keep maintaining several developers to update every single chip they release.

Google can't keep Android on 6 year old kernels forever.

Now combine these facts, and you'll see the issue.

View on HN

That's only a problem because they're keeping driver support closed. If they contributed a driver for their hardware upstream it would be maintained (by others) as the internal interfaces and standards change.

Whenever a security issue or design change happened, their driver would also get updated and fixed with the rest of the kernel.

What the hardware manufacturers SHOULD do is create hardware with a well defined control interface that they CAN make public. Any 'secret sauce', uploaded firmware blobs, etc, should be free to re-distribute since they were too cheep to ship a ROM or EEPROM with the firmware for their device with the device.

That's often not that simple.

For example, SAMSUNG might build your device, and get all of their own code openly.

But now for the US model, due to CDMA, they need to use a Qualcomm processor.

That needs a blob, and Qualcomm won't release that under an open license, nor update it.

So the OEM can either just not have CDMA support, or accept foreign blobs.

It works like this all way down the stack, down to even camera chips.

And then these devices all have custom hardware. Often hundreds of customly designed parts, with custom drivers, only ever for a single device.

Think of the Moto Z Play, withthe replacable components. Samsung phones with facial scanners. LG phones with 3D display.

One-off features that'd never get mainlined.

My understanding about the US side of this is that the software defined radios and FCC compliance are a major portion of the problem.

STILL, that stuff should be equivalent to a firmware blob that should have been baked in to a ROM or EEPROM. The actual driver controlling it should be able to be open, and for regulatory compliance should use 'magic numbers' as specified for the configuration; which as a fact of how to use that device must be configured already /not/ be covered by copyright (in the US at least).

Apple has the same issues, yet they keep their devices updated and secure for 5+ years.

Well, Apple completely controls the XNU kernel and its I/O Kit framework. By contrast, Google--and especially phone manufacturers--don't control development of the Linux kernel.

Well that’s not actually a problem if Google controlled the hardware (or a hardware standard, at least).

But they don’t.

So while you’re absolutely correct from a technical perspective it’s still a consequence of Googles strategy, and a problem for us all.

Android device vendors are Linux distribution vendors, and could support their releases for 5-10 years for a given device generation, like many other Linux distribution vendors are doing. (Or outsource it)

Yes of course it's not free and you can save money by leaving users stranded. But it's myopic to claim it's the fault of Linux.

That’s not really possible.

Let’s imagine you try to build a phone.

You buy an SoC, and you get a single kernel build. If you’re lucky, you get a few binary kernel modules.

These will never be updated.

You will always be stuck on that kernel version.

No manufacturer of ARM SoCs for phones currently provides ever updates for these.

Linux LTS Kernels get 2 years of support.

Now, tell me, how do you support a kernel that was dropped by upstream, with proprietary drivers that you can’t do anything about? I’m not sure if you’ve ever tried porting a custom ROM to such a device, I have. By the time Android was on the 3.11 kernel, I had a device still using kernel 2.6. It was insanity, half the functionality wasn’t working, we were reverse engineering and hacking together the rest, and still barely got anything working. It’s impossible to use a decade-old kernel with modern Android userland, yet that’s what you ask for.

You can support that kernel version, like distributions do now with back port etc work, or you can prefer SoC vendors that promise updated driver support. If the latter was happening, the problem would be fixed by now. So essentially phone vendors have been voting with their dollars for lack of driver updates.

But even for the self caused major version jam, the "get 2 years of support from upstream" is a heavy understatement and even after the n years of community LTS support ends, it's just the baseline you get for granted and you can diy more.

Maybe Fuchsia is an effort to solve such issues? But it won't see the day of light for at least 2 or 3 years.

The official Kernel.org LTS support is 6 years from the Linux devs, some vendors support theirs for longer.

The Kernel.org LTS support was 2 years until a few weeks ago.

Due to Google’s pressure, it’s now 6 years.

http://web.archive.org/web/20170812023641/https://www.kernel... says previously's been 2-6 years for the various LTS releases. But it's always been open to more sponsorship of course.

Reply on news.ycombinator.com