What "support" does Google need from Qualcomm after three years beyond driver/firmware blobs, which three years into a SoC's lifetime should be pretty stable?
We're talking about a company that maintains its own fork of the Linux kernel with something like 19,000 patches against mainstream. Anything not in a blob should be easily within their abilities to address.
Also, Nexus and Pixel devices have a long history of software and hardware problems, many of which are immediately obvious within a day or two of devices hitting people's mailboxes, and are never fixed over the life of the phone. It's not like google seems to be picking up the phone very often to talk to Qualcomm for support, even during a device's development, much less after?
The Pixel line jumped the shark when Google started permanently carrier-locking phone bootloaders for Verizon.
Can you guarantee that no one will hack Qualcomm's "blobs" tho? And if Qualcomm says "that's your problem, we only support it for 3 years", now you have millions of customers calling you a liar when you say "sorry can't fix the security issues, it's in Qualcomm's code that we don't have access to". They won't blame Qualcomm they will blame google. That's why I had real hope for Intel there for a while until they sold off their modem chip business.
You need access to the software that runs those SOCs which is owned by Qualcomm. Qualcomm isn't just going to give the sourcecode of those SOCs for Google engineers to tinker around with it. It creates all kinds of crazy legal problems.
It's not just the main Android OS that needs to be patched, the chips have their own proprietary software too.
The problem is that after 3 years, most of those chips have gone EOL and QC wants to put their resources into developing new chips because that's where the revenue comes from (e.g. how they pay their employees). Meanwhile new security flaws keep getting discovered on EOL chips that provide zero new revenue.
So what do you want here? Do you want the break neck pace of innovation to continue which is ultimately very good for everyone? Or should we spend all of our time making sure your Apple IIc still has security patches for 2022? At some point you just have to move on and that's just the trade you make for all technology. You can't simultaneously benefit from this cycle and then bemoan it. If all we ever did was make security patches for your Commodore and AppleIIc you wouldn't have a Pixel3.
> So what do you want here? Do you want the break neck pace of innovation to continue which is ultimately very good for everyone? Or should we spend all of our time making sure your Apple IIc still has security patches for 2022?
I want my perfectly good phone, that I bought 3 years ago, to still get updates. In all honestly, my old Motorola G4 would still be a good phone if it had more storage (and didn't eat SD cards).
Everything about my Pixel 3a (which is EOL in 4 months), works absolutely perfect for all my needs. Great camera, still very good battery life, plenty of storage / power. This is forced obsolescence for a device that is more than capable of handling most everyone's mobile workload. And, as a mobile minimalist, mine especially.
This kinda shit makes me want to go back to a fucking flip phone. I'll probably roll the dice with Lineage or Calyx, but the absurdity of all this is really frustrating.
Ultimately most people don't need the rapid pace of new chips. The pixel 3 level is sufficient for the foreseeable future.
There isnt a binary innovation or support. Just as we have LTS branches of software we should have LTS firmware. I would buy a LTS device in a heartbeat. But there are those who want the bleeding edge and they should be catered for too.
> Or should we spend all of our time making sure your Apple IIc still has security patches for 2022
Microsoft's timilene for OS support is easily 10 to 20 years. Windows XP was released in 2001. It's final ecurity support ended in 2019. 18 years later.
I know, it's hard for modern "programmers" to fathom such a level of commitment.
> You need access to the software that runs those SOCs which is owned by Qualcomm. Qualcomm isn't just going to give the sourcecode of those SOCs for Google engineers to tinker around with it. It creates all kinds of crazy legal problems
Alphabet cannot buy Qualcomm for the same reason Nvidia could not buy Arm.
If your implication is that someone market cap equals negotiating leverage you would only be right if Alphabet was the only elephant that Qualcomm was in bed with.
Point taken, however: modern apps don't run on 80s hardware, but they do run on a Pixel 3. The line in the sand just needs to align a bit more with the physical capabilities, for e-waste reasons.
We're talking about a company that maintains its own fork of the Linux kernel with something like 19,000 patches against mainstream. Anything not in a blob should be easily within their abilities to address.
Also, Nexus and Pixel devices have a long history of software and hardware problems, many of which are immediately obvious within a day or two of devices hitting people's mailboxes, and are never fixed over the life of the phone. It's not like google seems to be picking up the phone very often to talk to Qualcomm for support, even during a device's development, much less after?
The Pixel line jumped the shark when Google started permanently carrier-locking phone bootloaders for Verizon.