There are no incentives in place for doing otherwise.
Already in the old days, Nokia was one of the very few manufacturers that bothered to provide firmware updates, and even then usually only once.
Are there any work done on a system similar to the one on PC, where software can enumerate available hardware? We have advanced computers in our pockets, but they can't be updated to a new OS version as easy as a 15 year old PC. It's ridiculous.
The other issue is that there's zero (0, no) incentive to update the devices. No matter how easy it is - the OEMs see that as a pure cost that won't be recuperated. For each of the (literaly!) 100 devices they churn out per year they need to get new drivers from the SoC manufaturer (and Qualcomm pretty much does not give a crap about SoCs of the previous year, especially lower end ones - which makes this process stop there), update the kernel and move all their specific hacks to it.
I don't see how these changes Google did will change incentives. The only way we might see a change in this field is by a few class action suites from users being left without updates or regulators putting down the punitive damages hammer. Everything else is just Google kindly hoping OEMs will stop being dicks from the goodness of their heart.
In car industry we have strong regulation which demands that your car is serviceable at least 5 years since last unit was sold (and that their security issues are fixed by recalls). We need that for arguably the most important electronic devices in our lives as well.
Treble removes much of the cause for forking, and removes the cost for OEMs that follow it's design.
To some extent doesn't this make a case for (say) HTML# and browser based apps? That is the browser is a known sandbox of sorts. It's interface with the device (e.g., Phone app) is a known, and fixed. It has no care about what's on the other side of that wall. And the device OS more or less exists to run and support the browser.
But when the applications interface directly with the device, and there are countless device and OS, etc. combos there will always be a mess. Too many variables. Too many chefs in the kitchen if you will.
I realize I probably oversimplified. (Sorry.) I'm also outside my knowledge sweet spot, but am curious enough to want to learn. Please don't hurt me. Thank you.
I don't think users want dozens of apps installed on their phone, each with the possibility to be using up bandwidth, hogging resources, stalling programs and draining battery life, not to mention abusing permissions. If most apps can be done with webasm (and I don't see why the majority of apps can't be) then the only things that need to run in a more native context would be apps that use special features.
Unless the browsers offer APIs at the same feature level as native OS APIs, web applications will always be a second class experience.
But in any case, to your point, native apps should be limited to special cases (that can't be done via the browser). That's not the case ATM.
But i have to agree, for low end devices, even from famous companies i dont think they will update their phone even with this.
When you put it that way, it seems like it's gotten a lot better.
On the Porters five forces scheme of things, the SoC vendors have much better bargaing power than device makers.
Long time ago, people also though ARM was going to close doors.
If Qualcomm refuses, other would gladly do and eventually become good enough for Qualcomm to either change their mind or become irrelevant.
The majority of my devices don't have Qualcomm.
And i think Nokia got into it because they had a very popular model that was found to have a nasty flaw. I still recall news reports about people queuing to get theirs flashed (this was back when GSM was the hot new system, and carriers were giving away phones if you signed up with them).
The long term plan smells of Magenta.
Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>.
Stock Linux definitely has a stable userland API, though I imagine that third party driver vendors don't know how to do stable userland APIs.
> Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>.
As for driver ABI compatibility, I know that almost all enterprise distributions maintain kABI compatibility for a particular release of their distribution (this is one of the selling points of such distributions). I believe there are also some community distributions with similar stability guarantees (for instance openSUSE Leap uses the same kernel as SUSE Linux Enterprise, so I would assume the same guarantee is provided).
Try copying some Linux binaries between a few distros, a few release years apart and tell me again about stability. Try the same with some Windows apps and compare and contrast.
API == ABI for stability purposes, and the kernel isn't the problem, otherwise things like docker wouldn't meaningfully work at all. It's all the auxiliary libraries, much larger surface area.
The issue is the dynamic libraries (which are handled by distributions in different ways). Try statically compiling a binary like that and you'll find that it will work between distributions and kernel versions.
> Try the same with some Windows apps and compare and contrast.
Because they include their dynamic libraries with their programs, which has its own tradeoffs (updating security issues in shared libraries is much harder, even if you had a package manager on windows -- which you don't).
> It's all the auxiliary libraries, much larger surface area.
Right, but GP's point was that Linux doesn't have userland-to-kernel stability and I was saying that's simply not true. It's true that there is no stable upstream driver API but there are also solutions to that problem as well.
It's not as simple as "windows programs include their dependencies". Windows has far better forward and backward compatibility than Linux (by which I mean Linux plus the required userland stuff - libc, ld, etc.)
That's kind of to be expected. Comparability is tons of extra effort that open source can't really prioritise, but don't just pretend that it is as good as Windows.
This is where autotools helps: ./configure --static. There are also equivalents for CMake.
Aside from that I also statically compile Golang programs all the time (specifically runc which is a container runtime that uses cgo and a bunch of other magic). If static compilation didn't work, neither would our releases.
Just because Rust only lets you statically link binaries if you use musl doesn't mean that nobody else knows how to link things statically.
> because glibc cannot be statically linked
This is patently false. It is true that glibc will make static linking _hard_ but it's definitely not impossible. You need to set some magic settings (that autotools does for you) which disables all of the dynamic loading stuff glibc does.
> It's not as simple as "windows programs include their dependencies".
But it is. If you ignore the core system libraries, and included all of the other library dependencies with programs, most of these problems would be fixed.
> Windows has far better forward and backward compatibility than Linux
glibc has symbol versioning so in principle (I have had to use this once or twice) you can use an older program (linked against an old glibc) on a newer glibc.
It's in drivers, third party kernel modules, libraries, etc.
But that doesn't make it any easier.
On desktoo GNU/Linux or GNU/NT we don't have easy stable environments, and the fight between dynamic and static linking is always won by static linking. In the GNU world, that ended with snap/flatpack/docker/rkt/containerd
I really wish userland devs would spend more time actually maintaining API/ABI stability, and less time reinventing wheels because they are not "perfect" (after whatever arbitrary marker for perfection they work with).
But yes. One issue anywhere, and I can upgrade everything again.
Tbh i did like android, but the only problem for me was 2 year only update. That is not enough. Not even close when similar products from apple get 5 year suppurt. Specially now, after passing a threshold, our phones SoC are capable of handling ordinarily jobs (like if you are not into playing AAA games) for more than 4 years, performance wise.
P.s. After using iphone for 4,5 months i have to say , their i products are awesome. Far superior than android in term of consistent performance and fps.
I wonder if this means that Google will lead by example and prolong the time they deliver updates to their own phones. They don't guarantee new updates to their current Pixel phones after October 2018 [0], which is not good enough.
[0] https://support.google.com/pixelphone/answer/4457705?hl=en