3 ms·

The main problem with this is it would basically hand the market over to Apple. They're the only company with the vertical integration to be capable of supporti

by simonh 5y ago

The main problem with this is it would basically hand the market over to Apple. They're the only company with the vertical integration to be capable of supporting all their hardware and software properly for this sort of time span. Hence their ability to already support their devices solidly for twice as long as the longest supported Android devices. All the Android manufacturers, with the exception of Samsung, rely on their parties for hardware components and therefore device driver binaries that would need supporting and patching. And all of them including Samsung rely on Google for OS patches (well, except Google). Third party firmware is why Google struggles to support their devices for more than 3 or 4 years. A lot of manufacturers wouldn't even exist after 10 years. Blackberry, Nokia, Palm, all gone in the last 10 years. HTC were big back in 2011 but gave up on phones a few years ago. I'm sure there are more I'm forgetting.

webmobdev 5y ago
The fix is regulation mandating: 1. All phones should allow the bootloader to be unlocked, without compromising security, so that the user can install any OS on it. 2. All hardware parts should provide details of an API so that anyone can make device drivers for them for any OS.
- zsmi 5y ago
  I agree with you in principle but I think writing this regulation, in a way that actually solves the problem and is not trivial to work-around, is much harder than you think. Here's an example: The other day I was using a lidar sensor has a very well documented API, into its c-library. I do have the source for that c-library, and can build it, but it's calling into the part which doing many undocumented things because the part itself has a micro inside it and it has been updated since the documentation was written. And that c-library comes with a binary file that is filled with micro firmware and magic numbers that were determined by the factory during calibration. I have no idea how those measurements represent or how they were made, not that I can reproduce them anyway. Is this sensor compliant? And, it probably was compliant once, but now is it still? Because the sensor itself changed, even though the C API remained constant. Also, many parts, like this sensor, are made internationally: hardware is from one country, firmware is from another, company headquarters are a third.
- bzzzt 5y ago
  I think the problem with this kind of reasoning is that need to have a lot of faith in this mythical 'anyone' person to minimally provide you with timely, trustworthy security updates. Bonus points for keeping up with the more advanced features of newer phones. I've got a drawer full of 2000's era 'open source' hardware where the possibility is there but nobody bothered to create a good working operating system.
908B64B197 5y ago
> The main problem with this is it would basically hand the market over to Apple. Phone makers can just decide to build better SoC (or to purchase better ones) that are easier to keep working when you update the Kernel. Or they are free to run Android on top of an easier Kernel to work with. What we're seeing is Apple innovating and writing good software for almost 30 years since the NeXT purchase. Investing in good tech is just like compound interests, it pays over time.
miffy900 5y ago
> ...it would basically hand the market over to Apple. They're the only company with the vertical integration to be capable of supporting all their hardware and software properly for this sort of time span. Microsoft has no trouble supporting Windows and Windows Server for 10 years, and they're installed on innumerable number of different hardware configurations. The core issue is that Android's OS stack was built without a properly decoupled hardware abstraction layer (HAL), necessitating the phone's OEM, the SOC manufacturer and the carrier to all work together to prep an OS update. Google tried addressing this in Android 8 (https://arstechnica.com/gadgets/2017/05/google-hopes-to-fix-android-updates-no-really-with-project-treble https://arstechnica.com/gadgets/2017/05/google-hopes-to-fix-...), but even now, an OEM still needs a carrier's input when prepping a new Android OS update, and there's still simply no motivation from either.

by simonh 5y ago

webmobdev 5y ago

The fix is regulation mandating: 1. All phones should allow the bootloader to be unlocked, without compromising security, so that the user can install any OS on it. 2. All hardware parts should provide details of an API so that anyone can make device drivers for them for any OS.

zsmi 5y ago
I agree with you in principle but I think writing this regulation, in a way that actually solves the problem and is not trivial to work-around, is much harder than you think. Here's an example: The other day I was using a lidar sensor has a very well documented API, into its c-library. I do have the source for that c-library, and can build it, but it's calling into the part which doing many undocumented things because the part itself has a micro inside it and it has been updated since the documentation was written. And that c-library comes with a binary file that is filled with micro firmware and magic numbers that were determined by the factory during calibration. I have no idea how those measurements represent or how they were made, not that I can reproduce them anyway. Is this sensor compliant? And, it probably was compliant once, but now is it still? Because the sensor itself changed, even though the C API remained constant. Also, many parts, like this sensor, are made internationally: hardware is from one country, firmware is from another, company headquarters are a third.
bzzzt 5y ago
I think the problem with this kind of reasoning is that need to have a lot of faith in this mythical 'anyone' person to minimally provide you with timely, trustworthy security updates. Bonus points for keeping up with the more advanced features of newer phones. I've got a drawer full of 2000's era 'open source' hardware where the possibility is there but nobody bothered to create a good working operating system.

908B64B197 5y ago

> The main problem with this is it would basically hand the market over to Apple. Phone makers can just decide to build better SoC (or to purchase better ones) that are easier to keep working when you update the Kernel. Or they are free to run Android on top of an easier Kernel to work with. What we're seeing is Apple innovating and writing good software for almost 30 years since the NeXT purchase. Investing in good tech is just like compound interests, it pays over time.

miffy900 5y ago

> ...it would basically hand the market over to Apple. They're the only company with the vertical integration to be capable of supporting all their hardware and software properly for this sort of time span. Microsoft has no trouble supporting Windows and Windows Server for 10 years, and they're installed on innumerable number of different hardware configurations. The core issue is that Android's OS stack was built without a properly decoupled hardware abstraction layer (HAL), necessitating the phone's OEM, the SOC manufacturer and the carrier to all work together to prep an OS update. Google tried addressing this in Android 8 (https://arstechnica.com/gadgets/2017/05/google-hopes-to-fix-android-updates-no-really-with-project-treble https://arstechnica.com/gadgets/2017/05/google-hopes-to-fix-...), but even now, an OEM still needs a carrier's input when prepping a new Android OS update, and there's still simply no motivation from either.