71–80 of 121 posts
By separating out the driver interface using Treble, you can update the kernel and android versions from upstream without worrying about driver integration/updates.
When I buy a laptop I install whatever is the latest version of Ubuntu on it and am done. When I buy an access point I install whatever is the latest version of OpenWrt on it and am done. I've tried to do the same thing with phones using LineageOS but it's hopeless. Devices are often half broken and are never guaranteed to continue being supported because of this kernel mess. It seems there's slow progress being made…
There's a compromise solution to achieve something equivalent. And I say so after having tried many possibilities. Buy a Pixel or any other phone that supports AOSP (Sony does too, with some caveats) and install plain AOSP. It's not perfect as you need a bit of infrastructure to compile it yourself and keep OTA updates. But it's the most practical secure and privacy-respecting option, I think.
My friends seem to get a year or so before the SoC desolders from the motherboard, causing the device to bootloop, or the battery fails, or one of a million other things. Among us, there are a few dozen Pixels that are unusable due to their hardware defects.
Meanwhile, both of my old Galaxy S4's is going strong, and ditto for all but one of my LGs (one had its charge controller start smoking, LG repaired it).
Earlier quoted context omitted.
> Also, iPhone 3g is ancient. Released 2008. If I get an x86 laptop from 2008, I can install a modern Ubuntu on it with approximately 0 effort. If anything, it'll usually be better than cutting-edge hardware because the drivers have already been developed and released in a stable Linux version. iOS still loses this comparison.
This. I managed to build recent Linux on a Pentium MMX Mobile (IIRC) laptop from 1998. A cell phone from 5 years ago can't handle a modern operating system, but a 1998 laptop can run Xorg just fine.
Its frankly shocking that the Allwinner A10/A20/A64 (which can run Win10!) /H3/H5/H6 has nearly complete mainline kernel support, whereas nearly any of the smartphones made since 2008 can't boot mainline Linux and drive their cameras, screen, GPS, etc. Its a huge failing of the industry.
Google should go one step further and require upstreaming hardware drivers.
When I buy a laptop I install whatever is the latest version of Ubuntu on it and am done. When I buy an access point I install whatever is the latest version of OpenWrt on it and am done. I've tried to do the same thing with phones using LineageOS but it's hopeless. Devices are often half broken and are never guaranteed to continue being supported because of this kernel mess. It seems there's slow progress being made…
There's a compromise solution to achieve something equivalent. And I say so after having tried many possibilities. Buy a Pixel or any other phone that supports AOSP (Sony does too, with some caveats) and install plain AOSP. It's not perfect as you need a bit of infrastructure to compile it yourself and keep OTA updates. But it's the most practical secure and privacy-respecting option, I think.
Earlier quoted context omitted.
My ancient iPhone 4 did everything that I needed it to, but I had to abandon it because Apple did too.
I challenge you to name me one Android device that is officially supported for 4 or more years. ;) iPhone 4 is 8 years old so not sure I see your point.
This thread started with a comment about mobile phones in general being locked down to a specific kernel/os/software-combo, and that the upgrade paths is at the mercy of the vendor (unlike PCs).
Both Apple and Android phones are locked down. Who does it in the most convenient way is irellevant to the argument made.
This is happening because of Project Treble which creating a boundary between device drivers and the kernel. Earlier, kernel versions (even android versions itself) were subject to integration of device drivers into the kernel source code... which took a long time and often resulted in forced obsolescence. By separating out the driver interface using Treble, you can update the kernel and android versions from upstrea…
Google is finally facing the issue that regular consumers aren't caring to update anymore, specially now that devices are quite usable for several years.
So if they want to bring new OS versions into the market they really have to force OEMs to do it.
Hence the new GSI concept, finally adding update clauses to the Play Store usage agreement, and now upstreaming kernel changes.
Earlier quoted context omitted.
My ancient iPhone 4 did everything that I needed it to, but I had to abandon it because Apple did too.
I challenge you to name me one Android device that is officially supported for 4 or more years. ;) iPhone 4 is 8 years old so not sure I see your point.
The OP's comment was that any mobile devices these days, both Android and iOS are locked down black boxes. It wasn't specifically criticizing just Apple.
I've always found this curious since Linux fans usually mention the high usage of Android as Linux usage. The people usually think of GNU/Linux when they think about using Linux but the truth is Android is far from that. Be it the lack of GNU utils, not using a mainline kernel or the myriad of blobs and proprietary stuff bolted on top.
Official NDK APIs are ISO C and C++ standard libraries, a couple of portable libraries like zlib and Android specific APIs.
As of Android 7, any application that tries to link to on-device libraries or do calls that aren't whitelisted just gets killed.
Yes one might successfully do Linux specific calls, but given they aren't part of the stable Android NDK API, any OEM is free to bork those attemps.
In practice, being based on Linux doesn't mean anything for app developers.
Only for those doing system space development, which are Google and the OEMs, noone else.
Earlier quoted context omitted.
> You do nothing of the sort. You're buying a specific combination of hardware and software that may or may not get upgrades and security fixes over time Bringing in strictly theoretical supposition which is directly at odds with what's historically been a very solid track record from Apple isn't doing your argument any favours. Unless I misunderstood you.
The point isn't that Apple isn't good at doing updates. The very next sentence points out explicitly that they do that above and beyond everyone else in the space. The point is that you're locked in to a specific HW+SW ecosystem at the mercy of the vendor. If you like that ecosystem that may be great service to you, I'm pointing out that the #1 computing platform has only that choice and that's not the case in all th…