Software updates should be indefinite, like Linux distros, which can still run on 15 year old hardware just fine.
The future ought to be something like PinePhone (but with better hardware) that can be customized to run a variety of OS with consumables such as batteries easily user replaceable.
> like Linux distros, which can still run on 15 year old hardware just fine
First, let's remind that LineageOS does not run on 15 year old smartphones (and they drop support for a device when there is no upstream support from vendors on the same Android version).
One issue is that unlike x86/x86_64, there is no generalized abstraction platform (similar to BIOS/UEFI/ACPI description tables) that enables "one kernel to rule them all" i.e. you need some custom adjustments on your kernel for your SoC and board. Since a few years we have device-tree which improves a lot the situation, but I understand it does not cover everything (i.e. there would still be some missing aspects compared to UEFI/ACPI with regards to hardware description. Maybe some embedded experts can comment ?). Besides it is still not always implemented in chipset vendor's BSP which sometimes still rely on board files (where the data is not easy to extract from a binary kernel, noting that a lot of low-end OEMs do not properly comply with GPL and do not publish their sources)...
> One issue is that unlike x86/x86_64, there is no generalized abstraction platform (similar to BIOS/UEFI/ACPI description tables) that enables "one kernel to rule them all"
Windows on Arm devices use UEFI + ACPI, including Windows Phone starting from Windows Phone 8 (2012!). That allowed even the latest releases of Windows 10 Mobile to work on totally unsupported devices (1st gen WP8 devices) when that existed.
It's not an Arm problem, it's that the Android world didn't bother really tackling the problem for a long time.
I think user karteum brings up good points, but they are more like industry excuses than reasons. It's clearly possible to clean up this mess, but the OEMs and OS vendors simply won't bother since there is no regulatory reason to do it. This move from Germany is a great first step, but it's a step down a long road that the industry will fight at every exit.
This is a bit disingenuous. The problem is that every soc manufacturer wants custom data to pass to their driver. With ACPI, you need to standardize this data and get it published in the yearly spec update. With device tree you just check in your new device tree bindings alongside your driver in the kernel repo. Device Tree blobs are only stable with respect to the kernel version they were built for. It also doesn't have to worry about being OS independent. SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI. In recent years, ACPI has started adding support for encoding data which is non standard by allowing key value data, but using that sort of defeats the point. Those fields aren't usually documented and only the driver written for it understands how to interpret that data. Again, that forces ACPI blobs to be versioned alongside drivers. There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board. Of course even on x86 you can have more specific drivers which are more optimized or expose additional functionality, but generic drivers can an do exist which get you decent support. Beyond device tree/ACPI this means adhering to standardized register layouts and things like that which is completely off the table with arm soc manufacturers.
Windows doesn't have that issue on Arm, you can just boot the newest Windows on Arm release on a random SoC from the past that (if it's the same arch of course, 32 bit or 64 bit have different drivers) as long as the work was initially done first.
For ACPI, the vendors themselves tend to avoid changing bindings between generations for Windows there. Compounded with a stable driver ABI, things continued to work stably within all of Windows Phone (NT based, 8.0 to 10)'s lifetime, which had security update support until December 2019.
Windows RT 8.1 still gets security updates today, and will continue to do so until January 2023.
Linux not managing to standardize on a proper driver ABI _or_ stable bindings with the drivers in the kernel tree is just a Linux problem, and doesn't even affect other kernels on the platform, which mandate ACPI or something else.
> There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board
Nope, on x86, the meaty bits like the GPU and such do not have a stable register interface or anything remotely near that between generations. :)
On Arm systems, the interrupt controller (GICv2/3/4), timer (arch timer, since Cortex-A7/A15), IOMMUs (SMMU) and other standard devices were standardised since ages now (Apple is their own bubble and doesn't apply to this discussion). One of the remaining issues so far is PCIe hardware quirks/erratums, but that's getting solved.
But Qualcomm isn't interested in making their Linux drivers work with their ACPI definitions, they are stable between generations on Windows though, and not changed needlessly over there. (which allowed us to work to bring AArch64 Windows on the Lumia 950/950 XL using drivers from other SoCs too)
While you cherry picked examples that work for your arguments, I would say that they arent entirely correct. On x86, you can use a bounded number of drivers and boot successfully on a large number of boards. This is because things like buses, storage and display are standardized. This is not true for ARM. Every manufacturer does its own thing. Yes there are bits which have been standardized and shared, but for the most part that's not the case. As a result you cannot really make a single image that boots on a large number of boards without also including a very large number of drivers. Windows phone only ran on a limited number of SOCs, primarily Qualcomm.
Also for what it's worth, Qualcomm does update their ACPI definitions between SoC generations. They also fork their drivers to match. If there was a stable driver ABI they could probably do the same on Linux but that's not an option.
On server, ARM vendors went the PC route and just adopted standard interfaces used servers (pcie, sata, etc). This is large departure from SoCs targeting phones, tablets, and iot.
For QCOM the bindings for the base drivers are stable, and despite them forking drivers, the one for the others generally are - too
The biggest concern there is the PEP power management mechanism instead of using what ACPI provides.
> This is because things like buses, storage and display are standardized
That's a rosy view of x86. Quite some laptops ship with Intel RST set up such as stock Windows wouldn't boot on them before adding that driver. Display (frame buffer) is standardised too as UEFI GOP, but that no longer applies when the GPU driver takes over of course. Storage controllers & USB bindings are standardised too.
Doing a Qualcomm driverless boot on those platforms is very much possible, with storage and USB available, enough to install the OS and make it reach the desktop.
(and on a side note, as far back as the Snapdragon 810, PCIe was very much used. The Lumia 950 (XL) had their Wi-Fi controller over a PCIe bus.)
Laptops are definitely trending in the same direction as smart phones, I will not contest that. However my main point is that it's all much more standardized. Booting the system to the point you can prompt the user to connect to the internet and download more drivers is much easier on x86.
Qualcomm having "stable" bindings is a choice they've made. There is nothing forcing them to do that. The point is that they could not do that, because they know all images built for their phones will be specialized.
Qualcomm may use PCIe for one off peripherals, but it is not the bus used for most peripherals.
> SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI.
You can also get away with ugly hacks and sub par devs. Doesn't matter anyways, you got all the money from selling the SoC, software is an afterthought.
> and they drop support for a device when there is no upstream support from vendors on the same Android version
Nope, they drop support when the community runs into issues with a particular model that it's impractical to fix. Upstream vendor support helps but is not required in any way.
Device tree "doesn't cover everything" because some device components are yet to be supported in the mainline kernel. Once mainline support is added, that enables a 'universal' kernel to provide that support via the device tree.
This is true. I have used Lineage OS with android 7.1 on a first gen Motorola G phone (that was declared EOL after the Android 5.1 update) and now on a OnePlus 5 with Android 11 (manufacturer dropped support after 10)
Wouldn't that cause them to skip features and pick cheap drivers? How many people would benefit (not theoretically, but in practice)? Average life span of a mobile seems to be 2 years and a bit. After seven years, very few users will be left. And it's not as if everyone ditches their phone because of lack of updates.
> And it's not as if everyone ditches their phone because of lack of updates.
Often it's because of lack of app support, which is in turn because of lack of updates. Of course some people will always want the latest phone, but there are plenty of people that don't, and the second hand market is thriving. This is especially true in countries with lower income levels. I went on a trip to South America a few years ago, and most of the young people seemed to be using iPhone and android phones from top-tier manufacturers, but several generations old.
I don't see why. Theorically it could benefit a lot of people and help community driven projects or companies wanting to provide long term support. For example, if you create a phone that relies on Qualcom socs, qualcom only provides a few years of support, once they don't provide any new driver you're screwed. Forcing the release of source code would at least help open source driver initiatives.
If phone manufacturers stopped producing 10 models every year and focused on making a single robust one, they would have plenty of resources left for actual maintenance.
Sure, but they're in the business of selling as many phones as possible which means getting you to upgrade every so often. Unless they settle on a business model that allows them to make money from your old phone, I see this continuing.
Honestly why should I care what their business model is, if it is detrimental to users and the environment. That's the whole point of laws, to discourage behaviour that we as society deem undesirable.
"Selling as many phones as possible" allows yearly upgrades, but instead of 10 different models per year they can sell 3 models per year with 3.3x sales of each model. I am looking at Samsung models on the market, they are close to 10, Apple has maybe 2 or 3.
How so? Apple also releases new models almost every year with very dubious quality. I remember some scandals about antennas, and more recently about RF interference with pacemakers, but i'm sure there's a lot more i'm unaware of. Apple prevents users from using the hardware however they please and blocks the bootloader. They don't even give you root on your own phone!
Also they're famous for making their products hard to repair. It's hard to find spare parts, hard to find their custom screw heads, and hard to tear everything apart. You can't even remove the battery without tools which is very user-hostile, bad for the environment, AND was a pattern "popularized" by Apple, because if any other hardware manufacturer had dared to do that, they would have sold exactly ZERO phones.
All in all, Apple is close to the worst manufacturer i can think of to get inspiration from, although on specific topics (eg. LCD screen solidity) they are definitely not the worst.
Yeah, that is definitely the ideal future. Problem is that it has to be a well organized entity behind this. The open source community is very fragmented and can't spawn a reliable product for the mass consumer in the way current companies can.
While the idea that companies are held responsible for all theyr actions are good, there is one big problem. If the rist of failure of a product is to large, companies build shell companies that can go bancrupt. It is done so in oil shipment companies and i am sure there are other good examples. Nothing has been done against that even after huge oil leaks where the responsible companies have been very obvious.
(I do agree to longer enforced support on devices nevertheless)
This requires hardware manufacturers to work with kernel maintainers. It’s hard enough just getting them to publish the driver source code and not screw the user over for removing “value add” user space software.
Basic video is the keyword, on its heyday of GNU/Linux drivers it was capable of OpenGL 4.1 with hardware video decoding, then it got replaced with a driver that does OpenGL 3.3 and that is about it, thankfully the Windows drivers have been kept up to date.
The future ought to be something like PinePhone (but with better hardware) that can be customized to run a variety of OS with consumables such as batteries easily user replaceable.