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

Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

arstechnica.com

Post reply on HN
Print view View original

171–180 of 226 posts

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#171

Post by [deleted] »

cwyers wrote: post #91
dathinab wrote: post #87

Earlier quoted context omitted.

> have strangled Linux in its early years. And likely would still do so toady. I mean we are speaking about the kernel internal API (not the syscall API, which is stable). Even systems which pride themself for internal kernel API stability do change the API every view years, while often having much less internal (feature/platform support) changes then Linux . Furthermore in android Linux LTS versions are often used w…

Why? WDDM drivers written for Windows Vista can still work on Windows 10. And Windows is not a "niche" system.

[deleted]

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#172

Post by imtringued »

pantalaimon wrote: post #53
techrat wrote: post #44

Earlier quoted context omitted.

What I don't understand (due to my ignorance, please explain if you can)... what keeps the driver blobs from continuing to work from one version of Android to the next? What prevents people from using the same drivers for a device on Android 7 and upgrading the OS to 9 or 10? I always understood that drivers would continue to allow the OS to recognize the component that the drivers are for unless something drasticall…

Are you implying the 'no stable binary ABI' policy is responsible for a lot of e-waste?

No, Qualcomm is responsible for that. It's their device. The idea that a third party is responsible for supporting thousands of different devices simply doesn't make sense.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#174

Post by corty »

Something1234 wrote: post #132
koolba wrote: post #123

Earlier quoted context omitted.

Still not as a bad as Linuxant: https://lwn.net/Articles/82305/

I'm having trouble understanding the issue was here. Linuxant produced a module that lied to the kernel about being a non-binary blob. Am I correct, but I'm still having trouble understand how the company survived since they seem to have a website up still.

Linux kernel license enforcement is very lax. Most binary blob drivers probably violate GPL in one way or the other, as do the "GPL-condom" half-open-source "drivers" that do most of their stuff in a userspace blob.

When asked about it most kernel developers point to closed-door negotiations that are being kept confidential. Usually also saying "trust us, we know what we are doing, we'll get more source opened our way".

Those who actually try to enforce GPL publically are ignored or shunned, e.g. Harald Welte/LaForge of gpl-violations.org

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#175

Post by ac29 »

hvemsomhelst wrote: post #56

some qcom competitors pay ip designers for new android version drivers for designs from more than a decade ago

Android is only 12 years old. Are there really devices from the 1.x/2.x Android days that are still getting updated?

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#176

Post by kevincox »

codewiz wrote: post #133
dathinab wrote: post #15

It's not just Qualcomm it's closed source driver blobs in general. Even if your CPU might still be supported your other hardware might not. A common offender is camera drivers as far as I know and while you sometimes can still make the camera work it often comes with noticeable decreased quality (as the special patent encumbered closed source image post processing sausage is missing). Besides that potential but as fa…

> It's not just Qualcomm it's closed source driver blobs in general. To be precise, Qualcomm's Linux drivers are GPL'd like the rest of the kernel. Drivers often come with firmware blobs and proprietary binaries in userspace, but it should be possible to keep the kernel driver compatible with both. The actual reason why older SoCs stop working on newer Linux kernels is that Qualcom's drivers were not fully upstreamed…

That may keep the phone working but that doesn't provide security updates. Only Qualcomm can provide security updates for the binary blobs, so if Qualcomm won't sell security updates past 3 years than no OEM can guarantee a secure phone for more than 3 years. Sure, they can update other components but I would be very upset if 3.5 years into my 5 year supported phone a CPU vulnerability was discovered that let apps get root.

So while in practice this is rare it means that longer updates can't be offered as a product feature, and if it can't be offered as a product feature than how does it help sell phones.

I'll tell you right now that if any somewhat reputable manufacturer promised 5 year support on an otherwise reasonable phone I would buy it (and 5 isn't even that much). I would even pay a bit more for it. The amount of environmental waste that is basically working phones that just need a couple of software patches is disgusting.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#177

Post by rincebrain »

scaladev wrote: post #145
rubatuga wrote: post #138

Earlier quoted context omitted.

X5690 (Westmere) works well in Z400. Here’s another article specifying the BIOS update: https://www.techpowerup.com/forums/threads/new-microcode-for...

Jesus, what a pain. Why the hell do you need to wait for your proprietary OS vendor or BIOS vendor to update anything? On Linux the kernel does that for you, just configure your bootloader to point the kernel to a microcode image and that's it. Why can't windows do the same?

You only really need the "early" microcode loading procedure (the one where you pass it in the bootloader) if you have a microcode problem that is so broken the system won't boot with it unfixed (...or you're toggling feature bits off and the kernel will break if you originally booted with those bits and then they go missing - e.g. the broken TSX implementations on Haswell/Broadwell).

Otherwise, just loading the microcode update once you get into the running OS is fine. I've never actually had a system that needed to use the former, but I've certainly used the latter.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#178

Post by kevincox »

young_unixer wrote: post #153
garaetjjte wrote: post #100

Earlier quoted context omitted.

>as an effort to make the cost of keeping drivers closed-source high I don't think it is intentional. Linux development is very pragmatic, they just want to have freedom to refactor anything without caring about stable kernel APIs.

Ironically, they care a lot about stability towards user space interfaces, to the point that bugs become features if someone depends on them, but they don't care about driver interfaces being stable.

This seems like a win-win. The kernel developers are free to refactor as they need to keep the quality and velocity high and companies are incentivized to upstream patches including making drivers in-kernel.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#179

Post by fulafel »

surround wrote: post #139

> First, your SoC (System on a Chip) manufacturer (usually Qualcomm) has to get hold of it and customize Android for a particular SoC, adding drivers and other hardware support. Then, that build goes to your phone manufacturer (Fairphone, in this case) which adds support for the rest of the hardware—things like cameras, the display, and any other accessories. Why is it so easy to boot any linux distro on almost any d…

Lack of motivation / market pressure. Also a good excuse for planned obsolescence.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#180

Post by teddyh »

bri3d wrote: post #77
techrat wrote: post #44

Earlier quoted context omitted.

What I don't understand (due to my ignorance, please explain if you can)... what keeps the driver blobs from continuing to work from one version of Android to the next? What prevents people from using the same drivers for a device on Android 7 and upgrading the OS to 9 or 10? I always understood that drivers would continue to allow the OS to recognize the component that the drivers are for unless something drasticall…

This is because the Linux kernel itself is constructed and developed in a way where driver interfaces (API) are ruthlessly refactored and the linker interface for kernel modules (ABI) is intentionally version-incompatible. If the driver's source code is not in the kernel, it doesn't gain the benefit of kernel developers doing this ruthless refactoring and falls behind immediately from a source point of view, and from…

> This is a conscious and opinionated strategy on the part of Linux

If anyone wants to read the Linux developers’ explanation directly, here it is:

https://www.kernel.org/doc/html/latest/process/stable-api-no...

Post reply on HN