Live data from Hacker News

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

arstechnica.com

191–200 of 226 posts

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

#191

It's mind-boggling to me that Qualcomm only guarantees 2-3 years of support for their chipset. Compare that to the PC processor space, how much does AMD/Intel provide? 10 years? More? Somehow people seem to be running on 15 year-old Thinkpads without a problem, yet a $1000 phone apparently can't scrape by for more than three years due to vendor support?

>yet a $1000 phone apparently can't scrape by for more than three years due to vendor support The OEMs came up with a simple solution. Make batteries non-replaceable so that given the limited charge/discharge cycle life of a Li-ion the phone becomes almost useless after 2-3 years anyway.

There’s something else to this story people don’t talk about: write endurance of nand. Phone performance degradation over time can be explained by a combination of (in decreasing outlandishness) TGMLC, nand wearing out, throttling due to battery peak current being lower, and some secret throttling. I haven’t seen nand performance over time discussed or tested.

Replaceable batteries might be moot if after two batteries the device was unbearably slow. Consumers would still replace their phones within a few years.

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

#192
post #173

Earlier quoted context omitted.

That rules out iPhone as well, then.

It seems like Apple is being enough that they can get updates for their blobs, or are writing their own blobs. Although even then there are no promises. Maybe if a critical vulnerability was found in a Qualcomm blob Apple wouldn't be able to patch it. So in practice they do very well despite containing Qualcomm parts, but it isn't clear how much of this is just luck.

At this point Qualcomm should be pretty worried about getting replaced out of Apple hardware, so I suppose key account managers are scrambling to do Apples' bidding, at least to some degree. Apple has so much control over their embedded hardware now, they probably are already working at ridding themselves of everything that stops them from 100% control. This is unparalleled in other hardware/software ecosystems; there, the situation is often much the reverse.

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

#193

Earlier quoted context omitted.

Meanwhile, on a platform with a generally stable binary driver ABI alike Windows, even drivers for a prototype MSM8960 phone (Snapdragon S4) released in 2012-2013 will still run on 2021 versions of ARM32 Windows (insofar as these are still being built and released, of course).

ABIs are only needed because some manufacturers insist on closed source blobs. Why should Linux, a project whose entire raison d'etre is to provide an open source kernel, make life easier for companies unwilling to accept that?

The questuon is, can you actyally force their hand? So far, the answer seems to be no.

Personally I feel we need to push for a law where the iser has a right to an open driver in the same way he has a right to a manual. Attempts to ship undocumented / secret functionality is software or devices should be equates with spreadind spyware or malware.

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

#194

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.

It's somewhat pragmatic for the Linux developers. Support a stable kernel API probably wouldn't be that expensive. It's clearly a political decision against writing close source code that does anything low level.

I am not sure why the comment is being downvoted - thats exactly what it is, a political decision to force companies to produce open drivers.

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

#195

It's mind-boggling to me that Qualcomm only guarantees 2-3 years of support for their chipset. Compare that to the PC processor space, how much does AMD/Intel provide? 10 years? More? Somehow people seem to be running on 15 year-old Thinkpads without a problem, yet a $1000 phone apparently can't scrape by for more than three years due to vendor support?

>yet a $1000 phone apparently can't scrape by for more than three years due to vendor support The OEMs came up with a simple solution. Make batteries non-replaceable so that given the limited charge/discharge cycle life of a Li-ion the phone becomes almost useless after 2-3 years anyway.

Whule I also hate the status quo, the batteries can still be replaced, in the same way that a car's exhaust can be replaced, you just need to have the tools and skills" or pay a repairshop to do it for you.

If the phone still had years of milage, its worth doing

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

#196
post #52
post #46

Earlier quoted context omitted.

Amd and Intel CPUs are still 100% backwards compatable with 40 year old chips. Not just their own chips but also nearly all the features of their competitor's chip too.

>Amd and Intel CPUs are still 100% backwards compatable with 40 year old chips The CPUs might be, but the chipset drivers definitely aren't. You'll have a hard time booting windows 95 on a ryzen system, for instance. Hell, ryzen doesn't officially support windows 7. Still, I get your point, standardization in the PC space (mainly stemming from the "IBM compatible" standard) has made backwards/forwards compatibility m…

I am not sure about win95, but applications compiled 15 years ago still run on windows 10. That's stability.

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

#197
post #61

Earlier quoted context omitted.

I mean, that seems to be the result, yes? The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space.

> The intent is to compel device manufacturers to release the source of their drivers I doubt that was the "intent"... perhaps a contributory argument in favour of a non-stable ABI, but I understand the reasons are far more pragmatic: maintaining a stable kernel ABI is a lot of work which could have strangled Linux in its early years.

There are many different reasons that all contribute. But Linux clearly can keep some form of stability, given their dedication to never breaking userspace, if they really want to.

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

#198

Earlier quoted context omitted.

That's more or less what happens already.

It is but if the radio driver was open source then the interface with the radio SoC would be documented. Right now it is the worst of both worlds. Closed interface for a closed undocumented chip able to execute arbitrary code.

Drivers don't need to be open source to interact with GPLed code.

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

#199
post #99

Earlier quoted context omitted.

> Is there a smartphone that's usable as a daily driver, lets me have root and provides long term updates? A touchscreen notebook with a GSM/LTE modem and a decent microphone running Linux is the closest you can get today as far as I know

Or, you know, almost any Android phone from a reputable brand like Oneplus for example.

cheeky comment considering the premise was long-term updates.

while there are android phones that are supported by custom rom's up to ~5 years (exceptions even longer), the majority isn't.

meanwhile a 5year old iphone se is seamlessly supported by the manufacturer and probably will be for a few years to come.

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

#200
post #93

Earlier quoted context omitted.

Or you just push it upstream, which solves your problem because whoever is refactoring kernel code is also likely doing the appropriate changes in your code if necessarily.

This assumes that the person making the SoC owns all the rights to the code for their drivers, instead of licensing them from other firms.

You can demand those terms when you negotiate the license.
Post reply on HN