Fairphone suggests Qualcomm is the biggest barrier to long-term Android support(arstechnica.com)
arstechnica.com
Fairphone suggests Qualcomm is the biggest barrier to long-term Android support
https://arstechnica.com/gadgets/2021/03/the-fairphone-2-hits-five-years-of-updates-with-some-help-from-lineageos/
225 comments
> 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, either because they didn't submit them, or because they tried, but there were quality issues.
In theory, anyone could port those drivers onto the latest Android kernel, but without hardware documentation it's not an easy job.
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, either because they didn't submit them, or because they tried, but there were quality issues.
In theory, anyone could port those drivers onto the latest Android kernel, but without hardware documentation it's not an easy job.
My understanding is that a number of Android vendors operate by just taking a version of the Linux kernel and making any changes they need. By the time the phone is released and anyone cares, it's an old version of the Linux kernel, and the changes weren't written in a way that it's easy to incorporate them in the first place. The idea of incorporating a large chunk of changes all at once at the end is nobody's idea of a good time.
I get that they have no responsibility vis a vis the GPL to upstream their changes, and I have no doubt that this is a cheaper way for them to run their business.
I get that they have no responsibility vis a vis the GPL to upstream their changes, and I have no doubt that this is a cheaper way for them to run their business.
The SoC manufacturer provides to the OEM exactly one kernel version that works on that chip.
The OEM has to use that version. Oftentimes the SoC manufacturer will deliberately make it an old version because they know that the next android release will require a newer kernel version, therefore forcing the OEM to update to a new and more profitable SoC rather than continuing to sell an old model.
The OEM has to use that version. Oftentimes the SoC manufacturer will deliberately make it an old version because they know that the next android release will require a newer kernel version, therefore forcing the OEM to update to a new and more profitable SoC rather than continuing to sell an old model.
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.
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.
> 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
I think that's exactly what Fairphone does. Sure they are not as big as Samsung, but they seem to be true to their word (I'm a happy FP3 customer, but to be honest I have much reasonable expectations for my phone than many :) )
I think that's exactly what Fairphone does. Sure they are not as big as Samsung, but they seem to be true to their word (I'm a happy FP3 customer, but to be honest I have much reasonable expectations for my phone than many :) )
This was one of the big reasons my newest phone is an iPhone, not an Android phone. I am tired of buying new hardware every 2-3 years just to have a secure device.
I worked on the Linux Kernel team at Qualcomm for about five years, left in 2016. Our director was very much in favor of upstreaming but the product release schedules were so aggressive everyone was scrambling just to hit customer deadlines. It was incredibly difficult to get upper management on board with spending an additional 20% time getting drivers upstreamed, despite our team making the case for it ad nauseam.
Hopefully they recognize the value of "upstream first" more now. I think it is getting better...
Hopefully they recognize the value of "upstream first" more now. I think it is getting better...
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 drastically changes on the OS side of things.
Why can't we say "Fuck you, Qualcomm" and continue to use the older drivers for newer OS versions without having to wait for them to officially support it?
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 drastically changes on the OS side of things.
Why can't we say "Fuck you, Qualcomm" and continue to use the older drivers for newer OS versions without having to wait for them to officially support it?
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 a binary point of view, modules compiled for one kernel intentionally will not work with another.
This is a conscious and opinionated strategy on the part of Linux, as an effort to make the cost of keeping drivers closed-source high and the cost of kernel refactoring low. It also has... disadvantages, in the form of a massive wasteland of only-supported-once snapshot-in-time devices. I am sure this comment thread will happy expound on this in great and painful detail.
Secondly, there was an entire effort by Google called "Project Treble" to build a stable Android HAL/ABI over the top of these unstable kernel interfaces. Unfortunately it would/will require essentially an Android-specific rewrite from vendors in order to fully implement, so many drivers are not yet operating in this model.
This is a conscious and opinionated strategy on the part of Linux, as an effort to make the cost of keeping drivers closed-source high and the cost of kernel refactoring low. It also has... disadvantages, in the form of a massive wasteland of only-supported-once snapshot-in-time devices. I am sure this comment thread will happy expound on this in great and painful detail.
Secondly, there was an entire effort by Google called "Project Treble" to build a stable Android HAL/ABI over the top of these unstable kernel interfaces. Unfortunately it would/will require essentially an Android-specific rewrite from vendors in order to fully implement, so many drivers are not yet operating in this model.
Project Treble is already fully supported by Qualcomm and other SoC vendors, that's not the issue.
The issue is that Treble simply shifts the compatibility issues from on from one layer (kernel) to another (Android HAL). There's still a compatibility horizon, because newer Android systems will eventually want to use newer kernel features and HAL APIs which were not present on ancient HALs which have been abandoned by the vendor.
And even if the OS could theoretically maintain backwards compatibility with older HAL APIs for 10 years, in practice the System + HAL combinations which aren't fully tested tend to break for various unforeseen reasons, making it unwise to push OS updates to devices which aren't fully supported by their vendor.
The issue is that Treble simply shifts the compatibility issues from on from one layer (kernel) to another (Android HAL). There's still a compatibility horizon, because newer Android systems will eventually want to use newer kernel features and HAL APIs which were not present on ancient HALs which have been abandoned by the vendor.
And even if the OS could theoretically maintain backwards compatibility with older HAL APIs for 10 years, in practice the System + HAL combinations which aren't fully tested tend to break for various unforeseen reasons, making it unwise to push OS updates to devices which aren't fully supported by their vendor.
>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.
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.
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.
How is it clear?
[deleted]
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.
Because of this unsubstantiated and baseless claim:
> Support a stable kernel API probably wouldn't be that expensive
> Support a stable kernel API probably wouldn't be that expensive
> 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...
If anyone wants to read the Linux developers’ explanation directly, here it is:
https://www.kernel.org/doc/html/latest/process/stable-api-no...
> is a conscious and opinionated strategy on the part of Linux, as an effort to make the cost of keeping drivers closed-source high.
And Qualcomm is probably very, very happy with this arrangement. They can put a gazillion devs to maintain their BSPs using any means possible, but a small 2nd tier SoC fabbless don't.
And Qualcomm is probably very, very happy with this arrangement. They can put a gazillion devs to maintain their BSPs using any means possible, but a small 2nd tier SoC fabbless don't.
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.
Is it truly necessary that all these drivers run in the kernel space?
I bet a lot of drivers are just interfacing with a standard serial line which could be done in the stable user space and then exposing the next layer through something like FUSE.
If I understand treble correctly that’s close to what Android is doing, where each HAL can be done in userspace?
I bet a lot of drivers are just interfacing with a standard serial line which could be done in the stable user space and then exposing the next layer through something like FUSE.
If I understand treble correctly that’s close to what Android is doing, where each HAL can be done in userspace?
Didn't some Linux maintainers had very clear legal words for NVidia when they tried to make a kernel HAL/ABI?
NoyesNo, Nvidia tried to make a doggy legally questionable workaround for license aspects,
so it's not quite the same.
Also as far as I remember (I might be wrong) the google HAL isn't a abstraction/redirection in the low level kernel module layer it lives on a higher abstraction level and was meant to make the amount of ways braking less but never planed to add abstractions on top of which you could build a graphics driver or CPU support (which doesn't only affect drivers but potential also kernel compiler time conditional compilations).
Also as far as I remember (I might be wrong) the google HAL isn't a abstraction/redirection in the low level kernel module layer it lives on a higher abstraction level and was meant to make the amount of ways braking less but never planed to add abstractions on top of which you could build a graphics driver or CPU support (which doesn't only affect drivers but potential also kernel compiler time conditional compilations).
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
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
Are you implying the 'no stable binary ABI' policy is responsible for a lot of e-waste?
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.
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.
> 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 which do support a long term stable ABI, potentially longer then certain other more niche systems priding themself with long support.
The problem is when a device is sold the kernel (minus back ported security fixes) is often already multiple years old so even if you use a kernel with 7 years longtime support you still have a good chance to run into problem. And supporting any kernel internal API for more then that time is unrealistic.
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 which do support a long term stable ABI, potentially longer then certain other more niche systems priding themself with long support.
The problem is when a device is sold the kernel (minus back ported security fixes) is often already multiple years old so even if you use a kernel with 7 years longtime support you still have a good chance to run into problem. And supporting any kernel internal API for more then that time is unrealistic.
Why? WDDM drivers written for Windows Vista can still work on Windows 10. And Windows is not a "niche" system.
Because Windows is a (very broken) Micro-Kernel system which did very little changes to it's kernel (as far as I know) in the last many years, in difference to that Linux is a macro kernel with constant changes and improvements to it.
Are the improvements worth the cost? I don't know. (For server applications likely yes, but for desktop likely not).
What I do know is that there are clear benefits of micro kernel architectures, even if they are kinda messed up (for a micro kernel) hybrids like windows has.
Lastly the way the kernel API's are designed can also make a major difference independent of the rest. Honestly the Linux kernel API feels much more raw then the windows API, but I only have every written a single dummy driver for each platform and that was quite a while ago.
Are the improvements worth the cost? I don't know. (For server applications likely yes, but for desktop likely not).
What I do know is that there are clear benefits of micro kernel architectures, even if they are kinda messed up (for a micro kernel) hybrids like windows has.
Lastly the way the kernel API's are designed can also make a major difference independent of the rest. Honestly the Linux kernel API feels much more raw then the windows API, but I only have every written a single dummy driver for each platform and that was quite a while ago.
Windows NT is not a microkernel - Windows CE was, however.
NT has been shifting towards running more driver-code in user-space, as has macOS as well, especially with UMDF (especially for USB devices) and for graphics drivers, which are historically the #1 cause of BSODs - however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality. With a true micro-kernel there isn't any third-party code in the kernel space - not even a stub.
NT has been shifting towards running more driver-code in user-space, as has macOS as well, especially with UMDF (especially for USB devices) and for graphics drivers, which are historically the #1 cause of BSODs - however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality. With a true micro-kernel there isn't any third-party code in the kernel space - not even a stub.
> however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality
I typo'd that - it should be
> however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel isn't still responsible for huge swathes of the computer's functionality
I typo'd that - it should be
> however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel isn't still responsible for huge swathes of the computer's functionality
This comment feels like it was written by someone who hasn't done much Windows development (which is fine!). The kernel changes a lot over time, introducing entirely new driver models (see https://en.wikipedia.org/wiki/Windows_Display_Driver_Model#H... for an example), OS-wide features, etc. Things like thread scheduling or timer granularity can and will change (see https://randomascii.wordpress.com/2020/10/04/windows-timer-r... for a recent example)
Let's not forget about massive stuff like the whole Windows Subsystem For Linux, which was literally an entire separate process type alongside Win32 processes, with its own set of syscalls etc. Added and then deprecated (and probably eventually removed entirely) over the span of years.
Maintaining a stable kernel ABI is no doubt a big investment, but it's possible and doesn't have much to do with whether your kernel is a microkernel or not. Lots of Windows drivers these days are user-space which helps maintain compatibility and stability.
Let's not forget about massive stuff like the whole Windows Subsystem For Linux, which was literally an entire separate process type alongside Win32 processes, with its own set of syscalls etc. Added and then deprecated (and probably eventually removed entirely) over the span of years.
Maintaining a stable kernel ABI is no doubt a big investment, but it's possible and doesn't have much to do with whether your kernel is a microkernel or not. Lots of Windows drivers these days are user-space which helps maintain compatibility and stability.
[deleted]
[deleted]
Granted, even ABI-stability to some extend is difficult.
I remember that I have some cheap wifi adapters that aren't supported by in-tree code, but came with a CD (small diameter) that had the SDK on it.
This was unfortunately for the old timespec or w/e the exact struct is called, and I could have ported it to use the new API, especially considering that there are in-tree and/or up-to-date versions for closely related chips, but honestly the lack of easily-accessible tooling for that discouraged me from doing so.
The reason I got them initially is that, some about 2.5y back, they were sold on Aliexpress for 3.50 EUR (~5$) and could do dual-band with at least 40 MHz channels, iirc maybe even 80 MHz on 5GHz. They are just tiny USB-A dongles with a USB 2.0 HighSpeed host interface, but they could do station/softAP/station+softAP, obviously restricted to a single channel.
There's a related issue of a rtl8812-au or rtl8821-au (or compatible) stick (Edimax EW-7822UAC) I got before that, with a USB 3.0 SuperSpeed host interface, intended for trying out a remote radio head point-to-point configuration using polarization-duplex with a recycled satellite-TV dish on each end, as it could do AP-mode on 80 MHz wide channels in the 5 GHz band on Linux, with a 867 Mbit/s link rate (assuming full polarization multiplexing based on the stick's 2x2 MIMO and a circular polarizing feed antenna).
The reason I got them initially is that, some about 2.5y back, they were sold on Aliexpress for 3.50 EUR (~5$) and could do dual-band with at least 40 MHz channels, iirc maybe even 80 MHz on 5GHz. They are just tiny USB-A dongles with a USB 2.0 HighSpeed host interface, but they could do station/softAP/station+softAP, obviously restricted to a single channel.
There's a related issue of a rtl8812-au or rtl8821-au (or compatible) stick (Edimax EW-7822UAC) I got before that, with a USB 3.0 SuperSpeed host interface, intended for trying out a remote radio head point-to-point configuration using polarization-duplex with a recycled satellite-TV dish on each end, as it could do AP-mode on 80 MHz wide channels in the 5 GHz band on Linux, with a 867 Mbit/s link rate (assuming full polarization multiplexing based on the stick's 2x2 MIMO and a circular polarizing feed antenna).
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.
> 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.
But it's still the thing we want, for that and a lot of other reasons. So presumably what we need to do is find a way to exert more leverage, so that we actually get what we want, instead of folding and letting the bad thing take root forever.
But it's still the thing we want, for that and a lot of other reasons. So presumably what we need to do is find a way to exert more leverage, so that we actually get what we want, instead of folding and letting the bad thing take root forever.
I dunno, seems a stretch to blame the kernel for e-waste when theres tons of other well funded parties creating the waste in the first place with zero intention of supporting the device beyond a year, let alone enabling anyone else to support it.
The android ecosystem is already better than the completely proprietary feature phones of before.
The android ecosystem is already better than the completely proprietary feature phones of before.
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.
With new Android versions come new kernel versions, and the interfaces to drivers are not stable, and I assume Android-specific interfaces also do change.
[deleted]
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).
Google is changing this for Android with GKIs (General Kernel Images) being mandatory[1] for new phones which launch with Android 12 (i.e. late 2022 phones). They'll maintain a stable ABI so that OEMs can plug in their proprietary drivers as kernel modules.
Additionally with the work the Android Kernel team are doing to upstream so Android Common Kernel can be just replaced with using the Linux mainline, we're getting ever closer to limiting the effect that closed-source drivers have on updates.
[1] https://source.android.com/devices/architecture/kernel/gener...
Additionally with the work the Android Kernel team are doing to upstream so Android Common Kernel can be just replaced with using the Linux mainline, we're getting ever closer to limiting the effect that closed-source drivers have on updates.
[1] https://source.android.com/devices/architecture/kernel/gener...
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.
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.
> A common offender is camera drivers
This is precisely why open source libcamera[1] exists.
[1] https://libcamera.org/
This is precisely why open source libcamera[1] exists.
[1] https://libcamera.org/
Android should have been GPL
And how would that make any difference when it comes to radio firmware?
The radio firmware could be executed on different CPU than the Android kernel and communicate with a standard protocol ?
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.
Right now it is the worst of both worlds. Closed interface for a closed undocumented chip able to execute arbitrary code.
The interface isn't closed anymore, is it? [1]
[1] https://www.kernel.org/doc/html/latest/mhi/mhi.html
[1] https://www.kernel.org/doc/html/latest/mhi/mhi.html
[deleted]
Drivers don't need to be open source to interact with GPLed code.
Apache License 2.0 is GPL-compatible, isn't it?
Edit: expanding the acronym, to evade Android/Apache confusion.
Edit: expanding the acronym, to evade Android/Apache confusion.
The whole point of the patent system is that you do not keep the technique obfuscated.
Yeah, I think this is a major design point behind Fuschia/Zircon; they have a stable driver ABI to address this specific problem
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?
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?
When Intel released the microcode updates for the MDS family of vulnerabilities, in May 2019, they declined to support my Westmere Xeon, which launched in May 2010.
So, not quite 10 years. Still a hell of a lot better than Qualcomm, though.
So, not quite 10 years. Still a hell of a lot better than Qualcomm, though.
HP Z400 series got the microcode updates, so it was actually up to your vendor.
Hmm, don't think so. Vendors cannot create CPU microcode, Intel has to do that. And the relevant Intel document[1] clearly stated that they weren't going to do that.
The HP400 specs I found only list Bloomfield processors[2], not Westmere. Perhaps that is the source of your confusion?
1- https://www.intel.com/content/dam/www/public/us/en/documents...
2- https://support.hp.com/us-en/document/c01709672
The HP400 specs I found only list Bloomfield processors[2], not Westmere. Perhaps that is the source of your confusion?
1- https://www.intel.com/content/dam/www/public/us/en/documents...
2- https://support.hp.com/us-en/document/c01709672
X5690 (Westmere) works well in Z400. Here’s another article specifying the BIOS update:
https://www.techpowerup.com/forums/threads/new-microcode-for...
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?
Microsoft does release microcode updates for windows, here's an example: https://support.microsoft.com/en-us/topic/kb4494454-intel-mi...
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.
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.
That's a Meltdown and Spectre update from 2018. I'm talking about Microarchitectural Data Sampling, from 2019.
That got me thinking, why aren't Dell, HP, Lenovo etc selling "enterprise" Android phones? They could get probably pretty good margins on basic devices if they'd have good well-defined support periods. Bonus points for good MDM compatibility and various silly standard compliances that nobody cares about. Just being able to do purchases from same supplier as workstations seems like a major benefit for IT depts. They could probably do some bundle deals ("buy/lease workstation and get phone for free").
Because most IT departments now get the best of both worlds. They won't pay for phones for employees but still insist employees install their spyware to "byod".
Samsung has enterprise versions of some phones/tablets with 5 year security updates
Minus the bundle deals, it sounds like you're describing iPhone.
>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.
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.
Replaceable batteries might be moot if after two batteries the device was unbearably slow. Consumers would still replace their phones within a few years.
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
If the phone still had years of milage, its worth doing
>Compare that to the PC processor space, how much does AMD/Intel provide? 10 years? More?
They don't "provide" anything. It's the software (eg. linux/windows) that's providing backwards compatible support. Vendor support for pc hardware lasts a few years at most.
They don't "provide" anything. It's the software (eg. linux/windows) that's providing backwards compatible support. Vendor support for pc hardware lasts a few years at most.
Well, Intel's employees are fixing Intel drivers for Intel hardware released >15 years ago on the Linux Kernel main repository, among other trees such as the Mesa project. So yes they are providing support. Other companies do that too.
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 much easier.
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 much easier.
True, but old hardware can run windows 10, or modern Linux just fine.
Windows and Linux (and others) seem to hold the policy of drivers for old hardware being maintained and supported seemingly indefinitely. This work isn’t free, but there’s no reason Qualcomm and Samsung and others couldn’t do the same.
Windows and Linux (and others) seem to hold the policy of drivers for old hardware being maintained and supported seemingly indefinitely. This work isn’t free, but there’s no reason Qualcomm and Samsung and others couldn’t do the same.
Somewhat controversially at the time, Kaby Lake from Intel dropped Windows 7 support: https://arstechnica.com/information-technology/2016/01/skyla...
What anybody wants is the other way around though. If you want to run Windows 95 on modern hardware you run it in a VM; running it on bare metal isn't that interesting.
And the current versions of various Linux distributions do run on 25+ year old PC hardware, if you really want to.
And the current versions of various Linux distributions do run on 25+ year old PC hardware, if you really want to.
I am not sure about win95, but applications compiled 15 years ago still run on windows 10. That's stability.
They provide microcode updates.
Congratulations to Fairphone. This sounds like a massive task especially for such a small team. I run a Fairphone 3 and I couldn't be happier. Sure it was on the pricy side but it's served me well, takes great photos, has survived numerous drops (the phone protector shipped with it is great), looks cool,strikes up interesting conversations now and then, and will apparently have Android updates well into the future. Fairphone's a great company shipping a great product. Well worth the investment!
It's a decent device, but feels several generations behind any mid-range phone released in 2019. The screen has color blurring when scrolling especially visible with text, the fingerprint reader often doesn't get a good read, and it's noticeably sluggish in everyday tasks.
I justified the higher price to support their vision, not because it's a great daily driver, but it serves well as a backup phone with /e/OS. The cameras can be upgraded to the 3+ ones, so it's great that it's the only truly modular and DIY repairable device on the market.
I wish that a chipset swap and upgrade would be possible though. Google's Project Ara was interesting, but it was probably infeasible, and the technology might not be there yet.
I justified the higher price to support their vision, not because it's a great daily driver, but it serves well as a backup phone with /e/OS. The cameras can be upgraded to the 3+ ones, so it's great that it's the only truly modular and DIY repairable device on the market.
I wish that a chipset swap and upgrade would be possible though. Google's Project Ara was interesting, but it was probably infeasible, and the technology might not be there yet.
I'll admit I'm not someone who really follows phone developments closely enough to disagree. What you say is the standard review of FFs, that it costs more and is technically inferior. But then again I believe it costs what a fairly sourced and built phone costs. Other phones are too cheap.
> The screen has color blurring when scrolling especially visible with text
Mine doesnt
> the fingerprint reader often doesn't get a good read
I don't make a habit of volunteering biometric data near Google, so can't comment.
> it's noticeably sluggish in everyday tasks.
Not sure what everyday tasks you mean? Haven't ever really noticed it being sluggish? HN is snappy as hell :)
> The cameras can be upgraded to the 3+ ones
I didn't know, thanks!
> The screen has color blurring when scrolling especially visible with text
Mine doesnt
> the fingerprint reader often doesn't get a good read
I don't make a habit of volunteering biometric data near Google, so can't comment.
> it's noticeably sluggish in everyday tasks.
Not sure what everyday tasks you mean? Haven't ever really noticed it being sluggish? HN is snappy as hell :)
> The cameras can be upgraded to the 3+ ones
I didn't know, thanks!
> The screen has color blurring when scrolling especially visible with text
This was a big issue on my Samsung Galaxy S9 (2-3 years old flagship), OnePlus 7 Pro (2 years old flagship), and Google Pixel 5 (8 month old flagship). Those are all AMOLED so it's not an issue in normal mode black text on white background, but with dark themes scrolling makes the text look really bad, and it's even worse at low brightness.
This was a big issue on my Samsung Galaxy S9 (2-3 years old flagship), OnePlus 7 Pro (2 years old flagship), and Google Pixel 5 (8 month old flagship). Those are all AMOLED so it's not an issue in normal mode black text on white background, but with dark themes scrolling makes the text look really bad, and it's even worse at low brightness.
> it's noticeably sluggish in everyday tasks.
I'm not a fan of statements like this. They really should be qualified further, because the Fairphone project deserves thoughtful critique.
What exactly is sluggish? Scrolling in the mail app? Tapping links when browsing over cellular? Opening the app drawer?
I'm not a fan of statements like this. They really should be qualified further, because the Fairphone project deserves thoughtful critique.
What exactly is sluggish? Scrolling in the mail app? Tapping links when browsing over cellular? Opening the app drawer?
I'm writing this on a Fairphone 2, and even that I wouldn't describe as sluggish. Scrolling, tapping links, opening the app drawer - everything responds to my touches directly.
I'm sure newer phones are significantly faster, and heavier workloads can probably feel a bit janky (I don't usually have those), but phones haven't been sluggish the way pre-SSD computers could be for quite a while now.
I'm sure newer phones are significantly faster, and heavier workloads can probably feel a bit janky (I don't usually have those), but phones haven't been sluggish the way pre-SSD computers could be for quite a while now.
Scrolling in the RedReader and Materialistic apps, loading images in the built-in viewer, opening links in the built-in or external browser, and many more regular tasks have noticeable hitches and are not as responsive as on other devices of the same era.
Granted, I'm comparing this to a OnePlus 5T with a more powerful chipset, but I also think the screen itself is not as responsive to touch input which adds to the slowness perception. It reminds me of the way Android devices responded before Google's Project Butter, so seeing it in a modern $500 mid-range device from 2019 is underwhelming.
None of these are dealbreakers and the phone is perfectly usable, but together with the other (bigger IMO) issues it adds up to a lackluster experience.
Granted, I'm comparing this to a OnePlus 5T with a more powerful chipset, but I also think the screen itself is not as responsive to touch input which adds to the slowness perception. It reminds me of the way Android devices responded before Google's Project Butter, so seeing it in a modern $500 mid-range device from 2019 is underwhelming.
None of these are dealbreakers and the phone is perfectly usable, but together with the other (bigger IMO) issues it adds up to a lackluster experience.
How happy are you with the audio quality? I've been reading about issues with echoes on coip connections that seem to have been plaguing some people for quite some time. I dislike the cell phone audio quality by itself, but additional echoes would be a complete show stopper for me.
Really can't say I've experienced anything like this at all. Audio has always worked fine for me.
Qualcomm is only able to obstruct in this way because Linux doesn’t keep the kernel driver ABI stable for any fixed period of time.
If Android used FreeBSD and Qualcomm shipped drivers for the latest build when the SoC was released, you’d have up to five years of support from that kernel release.
Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the platform was never competitive, and they’d burned all their goodwill on the 7 and 8 fiascos.
If Android used FreeBSD and Qualcomm shipped drivers for the latest build when the SoC was released, you’d have up to five years of support from that kernel release.
Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the platform was never competitive, and they’d burned all their goodwill on the 7 and 8 fiascos.
Two things:
1. There are longterm kernel releases, with up to 10 years support, and Android uses those exactly to avoid major support issues (https://en.wikipedia.org/wiki/Android_(operating_system)#Lin...).
2. That doesn't fix the issue that Qualcomm themselves do not want to release documentation and only want to support their hardware for up to two years. Ergo, you would run some outdated binary blob.
1. There are longterm kernel releases, with up to 10 years support, and Android uses those exactly to avoid major support issues (https://en.wikipedia.org/wiki/Android_(operating_system)#Lin...).
2. That doesn't fix the issue that Qualcomm themselves do not want to release documentation and only want to support their hardware for up to two years. Ergo, you would run some outdated binary blob.
Exactly, having the hardware work is one thing. But to support a phone you need to fix security issues. So every binary blob is a ticking time bomb that is just waiting for a security vulnerability to be found either in it, or that needs a firmware patch to solve or workaround.
So either you need the source so that you can support it yourself, or you need a contract with Qualcomm to release security patches.
Sure, a stable ABI may mean that it would be cheaper for Qualcomm to release version updates as well, but at this point I would be happy if I could get security updates for more than 3 years. We can start asking for feature updates next.
So either you need the source so that you can support it yourself, or you need a contract with Qualcomm to release security patches.
Sure, a stable ABI may mean that it would be cheaper for Qualcomm to release version updates as well, but at this point I would be happy if I could get security updates for more than 3 years. We can start asking for feature updates next.
I’m going to reply to a few sibling comments at once:
Yes, they could upstream drivers, but they won’t. It’s not in their best interest. I’m taking about what could be done in spite of this.
Given that they won’t upstream drivers, if the blobs they release keep working for the reasonable life of your device, your phone can get other software updates, including major OS updates. I don’t expect or need the camera or radio driver to change across various android versions. The hardware is the same!
And if you want a newer phone, you’re free to buy one! It’s just sad that you can’t safely use older devices just because the blobs break compatibility with OS security and feature updates. This need not be the case.
Yes, they could upstream drivers, but they won’t. It’s not in their best interest. I’m taking about what could be done in spite of this.
Given that they won’t upstream drivers, if the blobs they release keep working for the reasonable life of your device, your phone can get other software updates, including major OS updates. I don’t expect or need the camera or radio driver to change across various android versions. The hardware is the same!
And if you want a newer phone, you’re free to buy one! It’s just sad that you can’t safely use older devices just because the blobs break compatibility with OS security and feature updates. This need not be the case.
You can use older devices safely. Switch to iOS. My iPad Air 2 from 2014 still receives every update. It’s clear that android vendors have no interest in long term support and apple does. So I send my money to the company that works the way I want.
> I don’t expect or need the camera or radio driver to change across various android versions. The hardware is the same!
You probably don't. But a serious security vulnerability could be discovered that lets apps get root. So yes, it likely is fine, but I want a promise from my manufacturer that I will be able to keep using my phone for 5-10 years. I want to take the guaranteed lifetime into account when I am buying a phone.
Ideally it would be legally binding such that I can get a refund if they don't uphold it.
You probably don't. But a serious security vulnerability could be discovered that lets apps get root. So yes, it likely is fine, but I want a promise from my manufacturer that I will be able to keep using my phone for 5-10 years. I want to take the guaranteed lifetime into account when I am buying a phone.
Ideally it would be legally binding such that I can get a refund if they don't uphold it.
Qualcomm upstreams tons of support for their SoCs.
> Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the platform was never competitive, and they’d burned all their goodwill on the 7 and 8 fiascos.
Regardless of how much goodwill they burned with 7 and 8, their handling of the WM 10 release nailed the coffin shut. They actually made a release that ran ok, but it was 18 months after the initial release. And Edge managed to be worse than mobile IE, but they were pretending to be Apple and disallowed competing browsers in WP. Grumble mumble, live tiles were nice.
Regardless of how much goodwill they burned with 7 and 8, their handling of the WM 10 release nailed the coffin shut. They actually made a release that ran ok, but it was 18 months after the initial release. And Edge managed to be worse than mobile IE, but they were pretending to be Apple and disallowed competing browsers in WP. Grumble mumble, live tiles were nice.
Yes, exactly that. I got onto windows phone with 8.0 and it was very nice to use even if app support was lacking. I steadily saw it decline. 8.1 took away much of what made it unique in the hope of getting better app support (narrator: it didn’t) but still remained fast and stable. Windows phone 10 was an outright disaster, slow and buggy, with no advantage to the user.
Maybe microsoft was always doomed in the mobile space because of app support, but they did a lot of things wrong that sealed the deal.
Maybe microsoft was always doomed in the mobile space because of app support, but they did a lot of things wrong that sealed the deal.
> Maybe microsoft was always doomed in the mobile space because of app support, but they did a lot of things wrong that sealed the deal.
I don't think they really were. They were actually gaining market share in the 8.x days, in part because their low priced phones were a lot more usable than similarly priced Android phones. Had they continued that trend with 10, instead of making a terrible release and pivoting towards high priced phones, they might have gotten enough market share to change developer's minds. And it's not like Microsoft didn't have experience on breaking into a market; the first xbox was weird and different, but they became a top tier console.
I don't think they really were. They were actually gaining market share in the 8.x days, in part because their low priced phones were a lot more usable than similarly priced Android phones. Had they continued that trend with 10, instead of making a terrible release and pivoting towards high priced phones, they might have gotten enough market share to change developer's minds. And it's not like Microsoft didn't have experience on breaking into a market; the first xbox was weird and different, but they became a top tier console.
Because the solution would be to actually upstream the necessary drivers or publish enough documentation that they could be created instead of doing hacks.
1. There are userspace blob too.
2. Android did change drivers architecture across version in the past. We are talking something as old as Android 6
2. Android did change drivers architecture across version in the past. We are talking something as old as Android 6
FWIW I do not want to use a 5 year old kernel and I do want to use a 5 year old phone (LG V20).
Just be happy that the kernel you get on your brand new phone is only 5 years old.
Example: the Nokia 7.2 was released at the end of 2019 and is running on Linux 4.4.194 on the newest available Android update. 4.4 was first released in January 2016 and is currently at 4.4.262. 4.4.194 was released in September 2019.
The newest LTS release at the end of 2019 was 4.19, released in October 2018. 4.9 and 4.14 are also LTS releases. 4.4 is a bit special because it's a Super Long Term Support kernel but 4.19 is SLTS as well.
The newest LTS release at the end of 2019 was 4.19, released in October 2018. 4.9 and 4.14 are also LTS releases. 4.4 is a bit special because it's a Super Long Term Support kernel but 4.19 is SLTS as well.
Is that a fair example? Most phones sold are going to be from Samsung.[0] Their recent flagship, the Galaxy S21, is a 5.4.61 kernel.
[0] https://www.appbrain.com/stats/top-manufacturers
[1] https://github.com/mohammad92/android_kernel_samsung_sm8350/...
[0] https://www.appbrain.com/stats/top-manufacturers
[1] https://github.com/mohammad92/android_kernel_samsung_sm8350/...
For a like-for-like example, the Galaxy S10 released in 2019 like the Nokia 7.2 is 4.14.212.
>Windows Phone 10......shame the platform was never competitive
I still think there is some possibility of Microsoft releasing Windows Kernel as open source. But they will need Azure to be a competitive and stable business first. ( Which is not right now )
I still think there is some possibility of Microsoft releasing Windows Kernel as open source. But they will need Azure to be a competitive and stable business first. ( Which is not right now )
This is not true. They could simply upstream the drivers.
I heard one of the reasons Microsoft had to ruthless kill support for phones when switching from WP7 to 8 to 10 was Qualcomm not willing to ship chipset drivers for the older devices with the new kernels in each of those iterations.
It would have gotten Microsoft a lot of goodwill if they had, but strangely enough Microsoft at that time did not seem to be interested in the goodwill of Windows Phone users anyway :-)
I'm still hanging on to a 950XL for some weird reason.
It would have gotten Microsoft a lot of goodwill if they had, but strangely enough Microsoft at that time did not seem to be interested in the goodwill of Windows Phone users anyway :-)
I'm still hanging on to a 950XL for some weird reason.
From WP7 to WP8 was WinCE kernel and single core to WinNT kernel and multicore. Maybe the WP7 devices could do it, but not with good performance. That one just wasn't going to happen.
Most of the WP8 devices were able to run WM 10, but the experience was really poor on the low memory devices, so those didn't get a release outside of the public insider builds. There was one or two devices that didn't get upgrades for some reason, other than those and the low memory devices upgrading to 10 was available, but it took a long time for them to get around to fixing things; it actually got a lot better in the release after they officially gave up. Possibly if there was a focus on mobile during development of 10, they could have made the first release good, and maybe even got it to work OK on low memory devices; Edge was still going to be trash though.
All of that said, a bigger problem was dumping goodwill of developers. WP7, WP8, and WM10 all had new frameworks for apps that were needed for new functionality and didn't work with prior Microsoft OSes; calling the WM10 one 'Universal' was darkly humorous.
Most of the WP8 devices were able to run WM 10, but the experience was really poor on the low memory devices, so those didn't get a release outside of the public insider builds. There was one or two devices that didn't get upgrades for some reason, other than those and the low memory devices upgrading to 10 was available, but it took a long time for them to get around to fixing things; it actually got a lot better in the release after they officially gave up. Possibly if there was a focus on mobile during development of 10, they could have made the first release good, and maybe even got it to work OK on low memory devices; Edge was still going to be trash though.
All of that said, a bigger problem was dumping goodwill of developers. WP7, WP8, and WM10 all had new frameworks for apps that were needed for new functionality and didn't work with prior Microsoft OSes; calling the WM10 one 'Universal' was darkly humorous.
> All of that said, a bigger problem was dumping goodwill of developers. WP7, WP8, and WM10 all had new frameworks for apps that were needed for new functionality and didn't work with prior Microsoft OSes; calling the WM10 one 'Universal' was darkly humorous.
I think this was somewhat overstated, since compatibility in the other direction was great. I wrote a WP7 app that worked fine across WP7/WP8/WM10 that I supported until MS pulled the plug entirely on the ecosystem.
I think this was somewhat overstated, since compatibility in the other direction was great. I wrote a WP7 app that worked fine across WP7/WP8/WM10 that I supported until MS pulled the plug entirely on the ecosystem.
The Linux driver ABI doesn't need to be stable because the drivers are supposed to be published under the GPL. This way manufactures just need to help get their drivers upstreamed and are largely off the hook for support after that.
Androids awful graphics API is hack that allows Qualcomm to keep the driver source closed which means the BSPs rot and you can't use your phone after 2-3 years.
I'll happily buy a 10 year old SoC with half the clock speed but open source drivers over anything from Qualcomm because of how awful they are with this.
Androids awful graphics API is hack that allows Qualcomm to keep the driver source closed which means the BSPs rot and you can't use your phone after 2-3 years.
I'll happily buy a 10 year old SoC with half the clock speed but open source drivers over anything from Qualcomm because of how awful they are with this.
There is actually quite some upstream work happening for Qualcomm SoCs these days, it's just a lot of effort.
Last I checked the official work the graphics drivers were completely left out.
That would be freedreno, not sure how complete it is yet.
Freedreno didn't come from Qualcomm and I've been through two Qualcomm based phones since it was started. Last time I checked (and I did give up a couple years ago) they barely had framebuffer support on a couple SoCs I didn't have.
This has been a long time ago. One of the Pixel phones was running freedreno by default.
Qualcomm is allowing their GPU drivers to be updated via the Play Store. This started in 2020 so it will only apply to Qualcomm SoC's released from 2020 onwards.
>Qualcomm is only able to obstruct in this way because Linux doesn’t keep the kernel driver ABI stable for any fixed period of time.
The Linux kernel used by Android is based on the LTS version that now has 6 years of support [1]. So by the time an OEM releases a new device the support window will be about 4 years. Google has also been working to stabilize the Android kernel HAL so that OS updates don't require a brand new kernel [2]. Because of these developments Android devices can now offer 4 years of support [3].
>Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the platform was never competitive, and they’d burned all their goodwill on the 7 and 8 fiascos.
This is pure speculation and I highly doubt Qualcomm would have invested the time and money, to support a platform that had no chance of success, beyond their obligated 2 years of support at the time.
[1] https://arstechnica.com/gadgets/2017/09/android-users-rejoic...
[2] https://arstechnica.com/gadgets/2019/11/google-outlines-plan...
[3] https://android-developers.googleblog.com/2020/12/treble-plu...
The Linux kernel used by Android is based on the LTS version that now has 6 years of support [1]. So by the time an OEM releases a new device the support window will be about 4 years. Google has also been working to stabilize the Android kernel HAL so that OS updates don't require a brand new kernel [2]. Because of these developments Android devices can now offer 4 years of support [3].
>Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the platform was never competitive, and they’d burned all their goodwill on the 7 and 8 fiascos.
This is pure speculation and I highly doubt Qualcomm would have invested the time and money, to support a platform that had no chance of success, beyond their obligated 2 years of support at the time.
[1] https://arstechnica.com/gadgets/2017/09/android-users-rejoic...
[2] https://arstechnica.com/gadgets/2019/11/google-outlines-plan...
[3] https://android-developers.googleblog.com/2020/12/treble-plu...
If Android used FreeBSD...
the only open source part (which is the kernel) will be closed source. No chances for customization and freedom now.
the only open source part (which is the kernel) will be closed source. No chances for customization and freedom now.
Compare mobile phones to PC today, you will find that a PC made like five or more years ago can run the latest software without issues while for mobile devices, they can hardly survive for more than three years (I guess?) since the ability to support a new Android version completely depends on the SoC manufacturer. You may also upgrade part of the hardware of PC or install whatever OS you like on them if you want to. However, look at those "smart" phones, which are not smart at all: you are limited to a few Android versions and you are forced to install all these proprietary userspace drivers (HALs for example). Moreover, if you want to have full access to your device (Root), you have to bag the vendor for that privilege (Xiaomi, Huawei, etc. OnePlus is way better), which should be the right for everyone.
This is because the PC market is standardized (I guess, correct me if I'm wrong), compared to the phone market which has all of these proprietary blobs, private interfaces and lockdown. I hope we could have open source drivers, standardized hardware and software interfaces (like UEFI) for mobile smart devices just as PC does. Thus we can install whatever operating system or software without limitations. Also there will be less e-waste just as PC.
This is because the PC market is standardized (I guess, correct me if I'm wrong), compared to the phone market which has all of these proprietary blobs, private interfaces and lockdown. I hope we could have open source drivers, standardized hardware and software interfaces (like UEFI) for mobile smart devices just as PC does. Thus we can install whatever operating system or software without limitations. Also there will be less e-waste just as PC.
Battery is also an issue. I'm two for two on destroying (my own) Android phones trying to replace the battery myself, but I've been able to replace two iPhone batteries without issue.
Yeah. That's why replaceable battery is a good idea but they disappeared in the recent years.
some Qualcomm SoCs (410c and 845c) are seeing mainline support. I booted a 5.11 kernel on an 2015 device yesterday and had surprisingly good working handheld with the pmOS/Phosh stack. Of course this is still a raw experience for enthusiasts, but one can use an AOSP distribution instead.
The Fairphone concept of easily replacing common problems with screens and battery complements the longterm chipset support, one needs both. It wouldn't help the repair/replace decision if the screen needs 2 hours and heatguns to replace. Making it difficult to unlock the bootloader is another barrier manufacturers and mobile operators are guilty of.
Mainline phones can be used until their counterpart antennas fall from the operators towers - and for 4G I think this is well into 2030.
The Fairphone concept of easily replacing common problems with screens and battery complements the longterm chipset support, one needs both. It wouldn't help the repair/replace decision if the screen needs 2 hours and heatguns to replace. Making it difficult to unlock the bootloader is another barrier manufacturers and mobile operators are guilty of.
Mainline phones can be used until their counterpart antennas fall from the operators towers - and for 4G I think this is well into 2030.
Chipset support from the manufacturer is not, strictly speaking, essential. What we need is support in the mainline Linux kernel. Many of the custom hardware blocks that a kernel has to support via its drivers are shared across chipsets generations anyway, so they end up being supported a lot longer than any single HW platform.
Right, and we're not going to get support in the mainline kernel without chipset manufacturer support. Namely in the form of open sourcing all the binary blobs, because those aren't going to be accepted into the mainline kernel.
Qualcomm just doesn't want to do this. I'm not sure if it's because they don't feel like spending the developer time (money) to do so, or if they believe 2-year obsolescence is better for their bottom line. Probably both.
Qualcomm just doesn't want to do this. I'm not sure if it's because they don't feel like spending the developer time (money) to do so, or if they believe 2-year obsolescence is better for their bottom line. Probably both.
The kernel- and user-space binary blobs can be replaced by the community. See freedreno, lima, panfrost, nouveau etc.
... with a lot of work that starts only after devices start shipping, and rarely takes advantage of the whole functionality of the hardware.
This is not a sustainable model.
This is not a sustainable model.
Have you seen the sunxi project?
It will be interesting to see what Project Treble brings to the table w.r.t. long term support for Android devices. It should help with the bitrot problem, though it pushes a bunch of stuff into blobs instead of creating long-term maintainable kernel source code.
Google has been promising to 'solve' fragmentation and long-term support for almost a decade, and it doesn't seem like there is any real solution.
If you interested in long-term updates, the answer is simple: buy an iPhone.
If you interested in long-term updates, the answer is simple: buy an iPhone.
We agree that Google hasn't completely solved the support problem, but it's not to say Treble hasn't improved things.
Android Pie: https://www.androidauthority.com/project-treble-2019-1045370... Android 11: https://9to5google.com/2020/12/16/android-updates-4-years/
Android Pie: https://www.androidauthority.com/project-treble-2019-1045370... Android 11: https://9to5google.com/2020/12/16/android-updates-4-years/
For the lucky ones buying flagship phones, it has hardly changed in the traditional models used by pre-paid customers.
> If you interested in long-term updates, the answer is simple: buy an iPhone.
I would, if apple wouldn't dictate what i can and cannot install on my phone.
Is there a smartphone that's usable as a daily driver, lets me have root and provides long term updates?
I would, if apple wouldn't dictate what i can and cannot install on my phone.
Is there a smartphone that's usable as a daily driver, lets me have root and provides long term updates?
> 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
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.
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.
Longterm official updates? Not that I've found. Your best bet is likely to buy a high-specced device that allows root + unlocking the bootloader and flashing a custom ROM. That's probably what I'm going to do (minus rooting), even though I'd greatly prefer manufacturer support.
The answer is a monolithic GPL kernel that forces manufactures to publish driver source code but they don't want to admit it.
Or a Windows-style stable ABI with drivers remaining closed-source. That's what Google are doing with their new Fuchsia OS and Zircon kernel, which is expected to replace the GPL-licensed Linux kernel on Android and ChromeOS devices.
Basically their moving away from the copyleft Linux kernel.
Given Google's awful track record with Android and security updates, and their lack of ability to force companies like Qualcomm to provide longer support windows, I'm not sure their new strategy will be successful.
Inevitably they'll be severe vulnerabilities found in the drivers including eg, Cellular radio / baseband drivers, Bluetooth driver, Wifi driver, and the vulnerabilities will never get patched.
Hopefully Google's capability-based microkernel approach with Zircon will stop this ever happening. But again, given Google's atrocious track record with Android and security I highly doubt it.
Even Windows doesn't support eg, i586 and i686 CPU architectures yet the Linux kernel does, so it seems like copyleft drivers are the only way to get security updates decades later.
Basically their moving away from the copyleft Linux kernel.
Given Google's awful track record with Android and security updates, and their lack of ability to force companies like Qualcomm to provide longer support windows, I'm not sure their new strategy will be successful.
Inevitably they'll be severe vulnerabilities found in the drivers including eg, Cellular radio / baseband drivers, Bluetooth driver, Wifi driver, and the vulnerabilities will never get patched.
Hopefully Google's capability-based microkernel approach with Zircon will stop this ever happening. But again, given Google's atrocious track record with Android and security I highly doubt it.
Even Windows doesn't support eg, i586 and i686 CPU architectures yet the Linux kernel does, so it seems like copyleft drivers are the only way to get security updates decades later.
This will allow the same blobs to keep working but won't get those blobs essential security updates.
This isn't a technical problem, it is an economic (and social and legal) problem.
This isn't a technical problem, it is an economic (and social and legal) problem.
Well it is a technical problem: it can be solved by reverse engineering and re-implementing every driver.
But yes, it's an economic problem because that's pretty expensive (but has been achieved before eg, nouveau driver)
Google could easily use their monopolistic position to force all SoC vendors to provide greater software support.
Heck, Google could even simply pay every SoC vendors to open source their drivers. It's unlikely to even cost that much.
But today's Google is simply too incompetent to ever fix Android's security update problem. They've been making silly excuses for decades.
But yes, it's an economic problem because that's pretty expensive (but has been achieved before eg, nouveau driver)
Google could easily use their monopolistic position to force all SoC vendors to provide greater software support.
Heck, Google could even simply pay every SoC vendors to open source their drivers. It's unlikely to even cost that much.
But today's Google is simply too incompetent to ever fix Android's security update problem. They've been making silly excuses for decades.
> Hopefully Google's capability-based microkernel approach with Zircon will stop this ever happening.
Just a correction, I meant "Hopefully Google's capability-based microkernel approach with Zircon will reduce the incidence and severity of vulnerabilities being exploited once they are inevitably discovered".
Just a correction, I meant "Hopefully Google's capability-based microkernel approach with Zircon will reduce the incidence and severity of vulnerabilities being exploited once they are inevitably discovered".
Hasn't treble been around for years now?
I, as an OSS community contributor, have been using Treble for years now, and I have devices who got let down by their OEMs on Android 8, that I pushed up to Android 11, and that's been pretty cool.
I, as an OEM, am still NOT allowed (by Google) to use Treble to provide upgrades. This "legality" issue is being fixed ( https://android-developers.googleblog.com/2020/12/treble-plu... ), but its effect won't reach users for at least 2 years.
I, as an OEM, am still NOT allowed (by Google) to use Treble to provide upgrades. This "legality" issue is being fixed ( https://android-developers.googleblog.com/2020/12/treble-plu... ), but its effect won't reach users for at least 2 years.
I don't see anything in your second link that explains what the "legality" issue is, could you clarify that for me, please?
The idea of Project Treble is to separate drivers from Android, and also to version drivers. When you receive a smartphone running Android 10.0, you also receive drivers "targetting" Android 10.0. With Treble, you can replace that Android 10.0, and bring it up to Android 11.0, while keeping the drivers targetting Android 10.0, and this pretty much works.
To release a smartphone with Google apps, an OEM must adhere to some requirements. One of those requirements, is that if you provide to customers an Android version X, then you must provide drivers targetting this version. You are not allowed by Google to provide an Android version 10 with drivers targgeting Android 9. This is true even across updates: if you release the smartphone with Android 9, then upgrade it to Android 12, then the Android 12 upgrade must include drivers targgetting Android 12.
The change that is coming, is that for Android 13, OEMs will be allowed to keep the drivers they made for Android 12.
To release a smartphone with Google apps, an OEM must adhere to some requirements. One of those requirements, is that if you provide to customers an Android version X, then you must provide drivers targetting this version. You are not allowed by Google to provide an Android version 10 with drivers targgeting Android 9. This is true even across updates: if you release the smartphone with Android 9, then upgrade it to Android 12, then the Android 12 upgrade must include drivers targgetting Android 12.
The change that is coming, is that for Android 13, OEMs will be allowed to keep the drivers they made for Android 12.
I wonder what the motivation was initially, to implement a glue layer that let you keep older drivers functional, only to also require the drivers be updated in lockstep. (Specifically the benefits of the lockstep update policy, not Treble in general, I grasp that.)
Why would a company which holds an effective monopoly over Android chips in the US do anything in order to discourage the sale of new chips? Providing support for older chips would hurt sales.
Qualcomm is abusing its monopoly position and the laws/patents that allow this need to be changed. Qualcomm is a great example of how IP laws can hurt progress and competition.
In the future China and other countries will leapfrog the US in areas where competition is banned, because the only possible competitors will be in other countries.
Qualcomm is abusing its monopoly position and the laws/patents that allow this need to be changed. Qualcomm is a great example of how IP laws can hurt progress and competition.
In the future China and other countries will leapfrog the US in areas where competition is banned, because the only possible competitors will be in other countries.
Google holds a far stronger monopoly than Qualcomm ever will. If Google required the driver support as a condition of allowing Android devices to be distributed with their hardware, Qualcomm would have to comply overnight.
Every single Android device from every manufacturer that wants access to Google apps must be approved by Google, and compliant with Google's terms. The "poor Google is at the mercy of other companies" narrative about Android's product line just doesn't square with the reality.
Every single Android device from every manufacturer that wants access to Google apps must be approved by Google, and compliant with Google's terms. The "poor Google is at the mercy of other companies" narrative about Android's product line just doesn't square with the reality.
[deleted]
That's a strange take considering millions of devices sold across the world running AOSP Android without any kind of Google software. From Huawei/Oppo phones in China, car infotainment systems, tablets used in Enterprise environments... Your own post doesn't really square with reality.
Phones in China alone and some infotainment systems won't keep Qualcomm afloat.
But Qualcomm doesn't have a monopoly on the market. There's Apple too. Sure, Android mostly uses Qualcomm in higher end models, but that is not the reason why Qualcomm can do anything they want.
The reason things are the way they are is simple - users doesn't care. Users will happily throw cash the for next groundbreaking, awesome possum camera innovation that is just so totally worth the $1000 upgrade, because fabulous selfies are what people care about.
The reason things are the way they are is simple - users doesn't care. Users will happily throw cash the for next groundbreaking, awesome possum camera innovation that is just so totally worth the $1000 upgrade, because fabulous selfies are what people care about.
Apple is only another player in "the market" if they start selling chips, or licensing their designs, for use in non-Apple products.
Apple uses Qualcomm as well for their 4G/5G modem. They've started work on fixing that (by buying Intel's business unit that was working on that in 2019) but iphones still contain Qualcomm modems for now.
Most of the industry, except some Chinese vendors, use Qualcomm technology. There just are not a lot of 4G and 5G implementations out there.
In most markets, you end up licensing their patents regardless of whether you use their hard and software too. They have a near monopoly because building a replacement is a non trivial exercise and even if you succeed, you'll still have to license the patents. So, even when Apple ships their replacement, they'll be licensing patents from the likes of Nokia, Qualcomm and a few others for quite some time.
https://www.bloomberg.com/news/articles/2020-12-10/apple-sta...
Most of the industry, except some Chinese vendors, use Qualcomm technology. There just are not a lot of 4G and 5G implementations out there.
In most markets, you end up licensing their patents regardless of whether you use their hard and software too. They have a near monopoly because building a replacement is a non trivial exercise and even if you succeed, you'll still have to license the patents. So, even when Apple ships their replacement, they'll be licensing patents from the likes of Nokia, Qualcomm and a few others for quite some time.
https://www.bloomberg.com/news/articles/2020-12-10/apple-sta...
Ok an oligopoly, does that make it better. Apple has a monopoly on Apple silicon.
Apple doesn’t have a monopoly on Apple silicon nobody buys it.
>the exclusive possession or control of the supply of or trade in a commodity or service.
They have exclusive possession or control of supply of these types of chips. I'm not sure if the question of whether or not they could sell or want to sell it comes into question. Lets say I buy up all the supplies of diamonds and exclude the use of diamonds in any other use than my jewelry. I believe this still falls under a monopoly
They have exclusive possession or control of supply of these types of chips. I'm not sure if the question of whether or not they could sell or want to sell it comes into question. Lets say I buy up all the supplies of diamonds and exclude the use of diamonds in any other use than my jewelry. I believe this still falls under a monopoly
There is no analogy with diamonds, because Apple doesn’t buy up a supply.
There is no supply to buy up - these are just a part apple has made for their own product.
If you use the logic that parts you make for your own products are ‘monopolies’, then most product companies are monopolies, and the term becomes meaningless.
There is no supply to buy up - these are just a part apple has made for their own product.
If you use the logic that parts you make for your own products are ‘monopolies’, then most product companies are monopolies, and the term becomes meaningless.
(Controversial?) opinion: patents encourage innovation because they force competitors to find new solutions instead of only copying existing solutions.
That doesn’t mean that it could not go terribly wrong as for example when patents blocked progress in 3D printing for decades.
That doesn’t mean that it could not go terribly wrong as for example when patents blocked progress in 3D printing for decades.
Unfortunately, many patents are intentionally written to make them as broad as possible, minimizing the possibility of designing alternatives.
Most innovation comes from building on existing solutions. You’re advocating reinventing the wheel
Like I’ve said before, there need to be laws that require companies like Qualcomm to open source their stuff once they stop supporting them in any meaningful way.
If you want lifetime updates for your phone, consider Librem 5 [0] or Pinephone [1] instead. They do no rely on Android but use GNU/Linux as OS.
[0] https://en.wikipedia.org/wiki/Librem_5
[1] https://en.wikipedia.org/wiki/PinePhone
[0] https://en.wikipedia.org/wiki/Librem_5
[1] https://en.wikipedia.org/wiki/PinePhone
If you want a "just works" phone, don't buy a Pinephone. The PinePhone is great for it's intended purpose but it is not a good consumer-phone.
IIRC there are still some binary blobs on there which might not work after some breaking change down the line, right?
Everything on the application processor is open source (think your laptop running debian.)
The only thing that could break are the radios (wifi,bt,modem) becoming incompatible with the networks they communicate with but they're separate components anyway and the modem speaks a standard protocol so I'm sure it could be replaced.
The only thing that could break are the radios (wifi,bt,modem) becoming incompatible with the networks they communicate with but they're separate components anyway and the modem speaks a standard protocol so I'm sure it could be replaced.
>Everything on the application processor is open source (think your laptop running debian.)
Even GPU?
Even GPU?
The ancient Mali-400 GPU in the Pinephone seems to have an open source driver, yes. It also looks like it has been upstreamed into the kernel for years now.
> Even GPU?
The Librem 5 uses a Vivante GPU that is supported by the open source Etnaviv driver.
The Librem 5 uses a Vivante GPU that is supported by the open source Etnaviv driver.
What about Google?
The issues fairphone mention are passing Google certification suites. They should be relaxed to help those cases. As far as I know the major issues are around GLES. It passed older CTS, so GLES was good enough back then. Surely it could be good enough now.
Isn’t gles replaced by vulkan since about 5 years ago? Google wouldn’t want so much fragmentation for app developers to deal with.
Google is slowly working on deprecating/hiding OEM's GLES drivers, in favor of Vulkan, but we're still very far from that.
Most of Android's rendering is still mostly GLES, using directly OEM's GLES driver. Since Android 10, apps can decide to use Angle for generic GLES over Vulkan, but that's opt-in.
Also the Snapdragon 801 chip of the Fairphone 2 doesn't have (official) support for vulkan
Most of Android's rendering is still mostly GLES, using directly OEM's GLES driver. Since Android 10, apps can decide to use Angle for generic GLES over Vulkan, but that's opt-in.
Also the Snapdragon 801 chip of the Fairphone 2 doesn't have (official) support for vulkan
> 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 desktop computer? What makes it more difficult for phones?
Why is it so easy to boot any linux distro on almost any desktop computer? What makes it more difficult for phones?
They aren't PCs. That was the purpose of the PC and open architecture. I don't know why mobile manufacuteres don't see it as beneficial to them though, but it's possibly just because it was such a rapidly developing space until recently and has yet to settle but something else could be at play.
It's hard to make devices as small and thin as a modern day smartphone while keeping its components modular at the same time. Now, this might be an acceptable tradeoff for you in particular, but Apple, Google, Samsung et al have probably already determined that it's not worth catering to that market segment.
Size has nothing to do with size or modularity. The same Qualcom chips get used from smart watches to tablets to cheap PCs, there's plenty of variety going on there. The difference is that the mobile SoCs are designed differently, requiring a complex system of bootloaders to even turn on that can change between models or even revisions of the chips.
The second problem is the proprietary nature of the chips. The PC became popular because other manufacturers copied and reversed IBM's BIOS and hardware, bringing a huge variety of available hardware that runs the same software. The only way that model could be profitable was to make sure everyone stuck mostly to the same standard, because breaking compatibility made your computer significantly incompatible with existing software your customers want. The crux of this requirement was that the user brought the software to the hardware, and the manufacturer could at most provide an operating system with a few tweaks at risk of breaking whatever the user wanted to run. This backwards compatibility still exists today, to the point that many BIOS update tools from manufacturers will boot FreeDOS to flash chips, running a software architecture older than many of their users on bleeding edge x64 chips.
The mobile ecosystem is designed so that devices last two, maybe three years, after that consumers throw their phones out and buy a new one. If you want to use your phone for longer then good luck, hope you bought a brand that ships you updates.
Qualcom, Huawei and Mediatek do not share the same level of compatibility the original PCs did, because they control the software supply chain. You don't take your software to Qualcom and make it work, you take Qualcom's kernel and then write your software. If Qualcom doesn't want to update the kernel version for your chip, good luck getting Android to boot; their open source drivers probably won't work because they either don't exist or are shoddily designed to fit only one kernel.
There's ongoing work over at the postmarketOS to mainline existing devices. Mainlined devices can run a proper, modern version of Linux with normal update support like any operating system, though Linux distributions often fail to properly implement things like deep sleep that are essential to using a phone. It'll be a while before mobile Linux becomes viable.
Then there's Apple, kind of a weird manufacturer in that they provide updates for well over five years even for slow mobile devices. They can do this because they don't need to buy chips from a manufacturer with an incentive to provide as little support as possible so end users buy new devices. They're also too popular for Linux not to hack in support for their weird, proprietary architectures.
All modular prototypes for Android have had the same problems with chipset and operating system constraints their constant-hardware cousins had; the same kernel supply line, with the same update problems.
The second problem is the proprietary nature of the chips. The PC became popular because other manufacturers copied and reversed IBM's BIOS and hardware, bringing a huge variety of available hardware that runs the same software. The only way that model could be profitable was to make sure everyone stuck mostly to the same standard, because breaking compatibility made your computer significantly incompatible with existing software your customers want. The crux of this requirement was that the user brought the software to the hardware, and the manufacturer could at most provide an operating system with a few tweaks at risk of breaking whatever the user wanted to run. This backwards compatibility still exists today, to the point that many BIOS update tools from manufacturers will boot FreeDOS to flash chips, running a software architecture older than many of their users on bleeding edge x64 chips.
The mobile ecosystem is designed so that devices last two, maybe three years, after that consumers throw their phones out and buy a new one. If you want to use your phone for longer then good luck, hope you bought a brand that ships you updates.
Qualcom, Huawei and Mediatek do not share the same level of compatibility the original PCs did, because they control the software supply chain. You don't take your software to Qualcom and make it work, you take Qualcom's kernel and then write your software. If Qualcom doesn't want to update the kernel version for your chip, good luck getting Android to boot; their open source drivers probably won't work because they either don't exist or are shoddily designed to fit only one kernel.
There's ongoing work over at the postmarketOS to mainline existing devices. Mainlined devices can run a proper, modern version of Linux with normal update support like any operating system, though Linux distributions often fail to properly implement things like deep sleep that are essential to using a phone. It'll be a while before mobile Linux becomes viable.
Then there's Apple, kind of a weird manufacturer in that they provide updates for well over five years even for slow mobile devices. They can do this because they don't need to buy chips from a manufacturer with an incentive to provide as little support as possible so end users buy new devices. They're also too popular for Linux not to hack in support for their weird, proprietary architectures.
All modular prototypes for Android have had the same problems with chipset and operating system constraints their constant-hardware cousins had; the same kernel supply line, with the same update problems.
Lack of motivation / market pressure. Also a good excuse for planned obsolescence.
A PC is somewhat standard, at least standard enough that you can use a common API to read from a boot drive and display text on a screen. Going beyond that however does require hardware-dependent drivers and problems start if you don't have them.
A phone doesn't really have this standard; it's closer to a microcontroller with random shit attached to its pins, including for critical operations such as display or disk IO (where as on PCs you can get away with using the generic BIOS-provided functionality, which while not fast will at least work).
A phone doesn't really have this standard; it's closer to a microcontroller with random shit attached to its pins, including for critical operations such as display or disk IO (where as on PCs you can get away with using the generic BIOS-provided functionality, which while not fast will at least work).
worth noting that there has been really good progress reverse-engineering support for 2017's Snapdragon 845[1] (SD845). quad A76 + quad A55 on Samsung 10nm. pretty modern, all in all.
generally i still feel tortured by the situation, by highest of high tech devices being unsupportable, unmaintainable after a couple years, and it seems like upstream support is the only available path to keep devices from turning to e-waste. however, there are some positive signs. most chips still have seen nearly no support from the chip makers, but we have seen, for example, Qualcomm land some additional support for some additional the SD845 gpu, for which reverse engineered support had already been nicely developing.
we're also seeing more phones with Samsung, MediaTek, & some other chips. it's notable that none of the other chip makers have much of a presence in kernel upstreaming either. it's not just Qualcomm: everyone is very bad at making mobile devices able to be supported.
i'm very interested to see what starts happening with cars, which face a similar supportability problem, but which are less disposable. long term kernel support has been extended greatly to enable a longer life. Google's Project Treble has created a device-driver abstraction layer to try to ease things along some. but it's very hard to imagine the sea-change necessary for commercial teams to take their work, & rebuild it, safely, successfully, easily, atop the complex drops of vendor code &c. chip makers have had an enormously difficult job supporting the teams making software, providing them updates that they can readily begin to use, and it's been a very conservative, slow, deliberate process. most technical folk seem anxious to shift the mode, to get more upstream support, such that kernel & system upgrades don't require carefully tailored support packages from the chip maker to make updates possible. the current pace feels very logjammed, there's so much custom code people shipping products rely on, and trying to make folks less critically dependent is such a powerful compelling vision for so many techies to improve supportability, to make updates shippable both faster & doable in the long term.
[1] https://en.wikichip.org/wiki/qualcomm/snapdragon_800/845
[2] https://www.phoronix.com/scan.php?page=news_item&px=Qualcomm...
generally i still feel tortured by the situation, by highest of high tech devices being unsupportable, unmaintainable after a couple years, and it seems like upstream support is the only available path to keep devices from turning to e-waste. however, there are some positive signs. most chips still have seen nearly no support from the chip makers, but we have seen, for example, Qualcomm land some additional support for some additional the SD845 gpu, for which reverse engineered support had already been nicely developing.
we're also seeing more phones with Samsung, MediaTek, & some other chips. it's notable that none of the other chip makers have much of a presence in kernel upstreaming either. it's not just Qualcomm: everyone is very bad at making mobile devices able to be supported.
i'm very interested to see what starts happening with cars, which face a similar supportability problem, but which are less disposable. long term kernel support has been extended greatly to enable a longer life. Google's Project Treble has created a device-driver abstraction layer to try to ease things along some. but it's very hard to imagine the sea-change necessary for commercial teams to take their work, & rebuild it, safely, successfully, easily, atop the complex drops of vendor code &c. chip makers have had an enormously difficult job supporting the teams making software, providing them updates that they can readily begin to use, and it's been a very conservative, slow, deliberate process. most technical folk seem anxious to shift the mode, to get more upstream support, such that kernel & system upgrades don't require carefully tailored support packages from the chip maker to make updates possible. the current pace feels very logjammed, there's so much custom code people shipping products rely on, and trying to make folks less critically dependent is such a powerful compelling vision for so many techies to improve supportability, to make updates shippable both faster & doable in the long term.
[1] https://en.wikichip.org/wiki/qualcomm/snapdragon_800/845
[2] https://www.phoronix.com/scan.php?page=news_item&px=Qualcomm...
SD660/630 too: https://github.com/SoMainline/linux/tree/SoMainline/v5.11-rc...
Not many device trees written yet (really only Sony devices) though
Not many device trees written yet (really only Sony devices) though
Three years of support is very poor and encourages e-waste, I will not be buying a phone with Qualcomm hardware in it.
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.
Isn't this (binary blob drivers) an obvious violation of the linux kernel's GPL license?
I presume that there's a good reason why that isn't being enforced, but I would like to better understand why.
I presume that there's a good reason why that isn't being enforced, but I would like to better understand why.
There are intentional loopholes left in the kernel to allow such drivers (Nvidia, fglrx, etc. are also closed source).
There are some rules though: Kernel module is always open source and cannot use all the symbols. Also, using such driver marks the kernel tainted.
There are some very valid reasons for not releasing open source drivers. NDA bound 3rd party code is one (Java had it, fglrx had it, HDCP stuff has it, Intel's old GPU drivers had it). Another reason is software based secret sauce. Again GPU drivers are the worst offenders in this class. Third reason is greed/being insecure. Lastly, some companies use this method to effectively deprecate their products, so they can sell newer units more. Embedded space is the biggest example of this. I also worked with such vendor in a very unrelated product category. It's unpleasant.
I don't support any of these reasons, but I understand them from an economic sense. Some companies started to bake their magic into their hardware (Mellanox, AMD), so they can open their software completely. This is a much better path IMHO.
There are some rules though: Kernel module is always open source and cannot use all the symbols. Also, using such driver marks the kernel tainted.
There are some very valid reasons for not releasing open source drivers. NDA bound 3rd party code is one (Java had it, fglrx had it, HDCP stuff has it, Intel's old GPU drivers had it). Another reason is software based secret sauce. Again GPU drivers are the worst offenders in this class. Third reason is greed/being insecure. Lastly, some companies use this method to effectively deprecate their products, so they can sell newer units more. Embedded space is the biggest example of this. I also worked with such vendor in a very unrelated product category. It's unpleasant.
I don't support any of these reasons, but I understand them from an economic sense. Some companies started to bake their magic into their hardware (Mellanox, AMD), so they can open their software completely. This is a much better path IMHO.
The sad thing is that all of the "reasons" are really only enabled by a lack of competition.
Customers want devices with in-kernel drivers. Not just curmudgeonly Richard Stallmans who care about the plight of the wild libre, but Joe Sixpack who just wants to be able to keep using the phone he likes instead of having to buy another one every other year. There is a market for that. Regular people would choose it on purpose.
And it's not being satisfied because Qualcomm keeps buying up their competitors. Because they dominate the Android market and the incentives of an effective monopolist are different than the incentives of a competitive market.
If you're one of five equally-sized chip makers, you don't care that the customer isn't going to buy a new phone for ten years instead of three, because with high probability they could buy from one of the other four next time anyway. And because you need a competitive advantage to get the sale today, and "don't have to buy a new phone after three years" is that.
If you're Qualcomm, you get the sale even if you don't offer the advantage because there is no viable alternative, and then you get another sale in three years.
Time to break them up. Or at least, and I mean come on, stop letting them buy their competitors.
Customers want devices with in-kernel drivers. Not just curmudgeonly Richard Stallmans who care about the plight of the wild libre, but Joe Sixpack who just wants to be able to keep using the phone he likes instead of having to buy another one every other year. There is a market for that. Regular people would choose it on purpose.
And it's not being satisfied because Qualcomm keeps buying up their competitors. Because they dominate the Android market and the incentives of an effective monopolist are different than the incentives of a competitive market.
If you're one of five equally-sized chip makers, you don't care that the customer isn't going to buy a new phone for ten years instead of three, because with high probability they could buy from one of the other four next time anyway. And because you need a competitive advantage to get the sale today, and "don't have to buy a new phone after three years" is that.
If you're Qualcomm, you get the sale even if you don't offer the advantage because there is no viable alternative, and then you get another sale in three years.
Time to break them up. Or at least, and I mean come on, stop letting them buy their competitors.
In the Android smartphone world, most big OEMs abid by the GPL properly, with nothing closed source in kernel.
But if you have bugs either in other processors' firmware, or in userspace binary libraries, kernel's GPL won't save you.
One could say that userspace binary blobs are meant to circumvent the GPL, but I don't have that feeling: GLES libs are userland just like Mesa, modem is userland just like ofono It looks like userspace/kernelspace separation is pretty much the same between oss world and android smartphones' proprietary world
But if you have bugs either in other processors' firmware, or in userspace binary libraries, kernel's GPL won't save you.
One could say that userspace binary blobs are meant to circumvent the GPL, but I don't have that feeling: GLES libs are userland just like Mesa, modem is userland just like ofono It looks like userspace/kernelspace separation is pretty much the same between oss world and android smartphones' proprietary world
For the most part, yeah, the closed source kernel blobs are blatant GPL violations. I've heard a cute legal theory as to why Nvidia's GPU blobs are at least grey area, but most of the other blobs don't follow that model.
This has been my main gripe with my Google phones. If a phone lasts half as long, it should cost half as much. Otherwise it's not very good value.
[deleted]
Time is now for an unencumbered SoC with fully available documentation, 1k+ pages downloadable as a complete set of PDFs along with a reference design.
If you count what's been leaked, Mediatek ones would qualify.
1k pages is underestimating by quite a bit. 3-4k pages is closer to the norm, and that's just most of the programming/registers documentation. The complexity in these SoCs is astonishing.
1k pages is underestimating by quite a bit. 3-4k pages is closer to the norm, and that's just most of the programming/registers documentation. The complexity in these SoCs is astonishing.
It was more aspirational, 1k of documentation and -3k of errata that never existed.
Having been through a project where we built a mobile OS both the carrier demands and baseband blobs are huge barriers to market.
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?
Surely any vendor that doesn't upstream their code changes has similar effects on long-term support?
Theirs bootloader is biggest barrier in running mainline Linux.
Interesting.
It seems that open source can never really win.
It seems that open source can never really win.
Completely. No doubt.
I don't blame Qualcomm one bit. Why would they want to support old hardware long after 99% of people aren't using it?
People aren't using it because it is no longer receiving updates. 2-3 year old hardware should not be considered "old", or obsolete.
Android hardware ages really poorly. I have an iPad and a few android tablets from around 2014 and the iPad is on the latest version of iOS 14 and feels almost new while the android tablets are basically unusable and on 2015 versions of android.
My 4 year old S8 is doing just fine. I'd be happy to replace the battery and use it for another 2+ years, but I only get one more quarterly security update.
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 far as I know less likely offenders include the modem.
Ironically both might be integrated into the SoC which then massively increases the chance for problems.