Also consider Apple's chips, which have gotten Linux support without Apple ever submitting a single line of code.
While Qualcomm's behaviour is definitely a massive bummer (not to mention Qualcomm's competitors), it doesn't stop manufacturers from supporting their devices. It merely stops maintaining support from being cheap and easy.
It should be noted that Intel makes CPUs, while Qualcomm makes SoCs, which include much more than just a CPU. Usually supporting the CPU is the easiest part, the rest is the issue.
That said, when device OEMs release the kernel sources, modders are able to update custom roms for a long time, so I doubt this is just a Qualcomm issue.
Here's a random 15 year old Intel PC (you can also do this on many current ones):
$ lspci | grep -v Intel
[no output]
Every piece of silicon in it is made by Intel and most of them, including the GPU, are integrated into the CPU. And it's all supported by current Linux kernels. The same is true for many AMD systems except that you'll usually see a third party network or storage controller which is itself still supported.So no, it's a Qualcomm problem.
so basically the kernel is frozen even if the android version is updated
Anyone can make a diff between the upstream kernel and the Qualcomm kernel. Maintaining these changes into later versions of the kernel will be quite challenging, but the base is already there.
That said, phones also come with plenty of binary drivers and those cannot be ported. That's an important reason not to bother with later kernel versions in custom ROMs: after all of your hard work, the end result will be missing important features such as GPU acceleration.
Custom kernels also exist for amd64 devices, often including workarounds and patches that are not in mainline to improve performance or compatibility.
As a vendor, that requires practically zero extra effort.
https://wiki.postmarketos.org/wiki/Devices has a list of devices that run either mainline or almost-mainline Linux. Only the "downstream" devices require vendor Linux kernels. Of course, hardware support is partial for most of these devices because vendors haven't contributed proper upstreamable drivers and volunteers haven't had the time to write them yet, but it's not like every ARM device needs a special kernel fork, that's just something ARM vendors do out of laziness.
Yeah, so that's not a why, that's a how (and it's not necessary or sufficient anymore, see the Samsung and Pixel reference).
The why seems very much what the article covers.
I (well my mom) had a supported with security updates version of Windows 7 on my 2007 Mac Mini (not a typo) until 2023.
Yet Google can’t seem to make that happen.
they should NEVER accept any of the binary only crap drivers, they should demand code be upstream or wont buy. But they dont care. Google doesnt care.
That's not entirely accurate. They do provide chips with extended support, such as the QCM6490 in the Fairphone 5. These are not popular because most of the market demands high performance, and companies profit from churning out products every year, but solutions exist for consumers who value stability and reliability over chasing trends and specs.
Vertical integration makes it possible but motivation makes it happen. Where is Samsung's ultra LTS Exynos device?
With the Switch being shipped for nearly 10 years, it pales in comparison to the shelf life of most any processor Apple, Google, Samsung, Qualcomm, MediaTek (?) push out.
Though Apple in particular is interesting, as their Apple TV lineup also has the same long legs, with the Apple TV HD/4th Gen releasing in 2015 and receiving the latest OS.
Point being, blame lies not only on Qualcomm as Google advocates tend to point out.