4 ms·
You're talking about three different classes of device: PCs, phones, and IoT (IoS)/deep embedded. Embedded development is hard. Really hard. And much of that d
by exmadscientist 6y ago
You're talking about three different classes of device: PCs, phones, and IoT (IoS)/deep embedded.
Embedded development is hard. Really hard. And much of that difficulty is intrinsic to the problem space, so it isn't going away anytime soon. But much of it is just embedded developers being masochists and embedded tool developers being sadists. For phones, the pain is probably 90% avoidable. 90 percent!
No, I don't know why we live with it either.
The reason your phone is different than your PC is that the PC's OS has all the drivers for everything built in, then loads whichever drivers your specific machine needs. Embedded Linux images are built specific to one model of hardware, with weird crappy OEM-provided drivers baked in and nowhere else available. It doesn't _have_ to be this way. But it is.
So to support your phone, the vendor basically maintains a custom-patched kernel with a bizarre build process. And that's done more or less independently for every model they're supporting. It's a huge headache!
Why deep embedded is this way is a little more understandable. (It's also where I prefer to work if I'm doing software; I don't like embedded Linux. It's just not my thing. So if I'm wrong when talking about it, that's why.) Deep embedded is often working with very limited hardware, custom circuits, and general strangeness. It also can serve the industrial, automotive, or medical markets, which naturally tend to longer product cycles. So the product is generally less standard, meaning it makes more sense (at least to me) why the support flow is so bespoke.
- vidanay 6y agoThat "custom-patched kernel with a bizarre build process" is a self-inflicted wound on the part of both Google and the carriers. It could have been corrected years ago.
- cogman10 6y agoYup, and to that point, the fix is really stupid simple, push the drivers into the linux kernel mainline and give google (or whoever) a kernel build profile for your device. Done. You don't have to support the device for an eternity and, as a bonus, you can benefit from OS improvements to your drivers/etc. Hell, you and other manufactures using the same broadcom SOC (and hear me out... this might sound crazy) wouldn't have to spend the same engineering effort building drivers! Of course, that would require manufactures to actually give a damn about driver quality, whereas the current situation allows them to push out the most broken patch imaginable to pass whatever conformance tests google asks for. That would also cut into manufactures bottom line which is why I suspect they've not gone down this route. Gotta sell them phones every year... (they'd cut support to 1 month if they could)
- ebg13 6y ago> Yup, and to that point, the fix is really stupid simple, push the drivers into the linux kernel mainline and give google (or whoever) a kernel build profile for your device. "If only the bad people would just stop being bad!" This mantra continually assumes goodwill from people who continue to show that they have none. At some point one needs to stop gaslighting themselves and their users and make the system more robust to bad actors. Manufacturers don't want to mainline their drivers? Fine. You can work on getting drivers mainlined while also stabilizing the interface so that it doesn't injure a billion customers when they don't.
- cogman10 6y agoYeah, there definitely needs to be some sort of enforcement that keeps bad actors from misbehaving. Google seems like the natural point for that. Maybe a law is needed? Too bad most law makers are completely tech illiterate. But I agree, it won't change without some central force to kibosh it.
- JetSpiegel 6y agoGoogle earns more money with the current scheme, so they have no incentive to improve this. Android One is a joke, it should be the baseline for Android, not a "special" version. They could force the OEM to play ball, like they require Google Play Services to be pre-installed.
- kelnos 6y ago> They could force the OEM to play ball, like they require Google Play Services to be pre-installed. I think Google really has to walk a fine line here. Android OEMs are already not thrilled with their lack of freedom when it comes to changing the experience on their phones. The more restrictions Google adds on, the closer some of them (especially Samsung) will be to cutting ties with the Android name and forking.
- GeekyBear 6y agoGoogle had absolutely no problem with forcing the hands of device makers when it came to their ability to build devices running a fork of Android. They are not powerless. They simply made the decision to treat carriers and device makers as the customers they cared about and not the people using the devices.
- sangnoir 6y agoSurely, you mean "Qualcomm-inflicted wound"? After TI left the Android SoC space, most OEMs and Carriers are beholden to Qualcomm, who write their own drivers and will never mainline them, if they can help it: long upgrade cycles will hurt Qualcomms bottomline, planned obsolescence via kernel incompatibility is how they achieve that. I don't think customers will upgrade from Snapdragon X05 to Snapdragon X20 for the minor gains in performance, if their old device could get the latest Android features.
- JetSpiegel 6y agoCouldn't Google bend Qualcomm to their will? Or even just buy them out, it's not like they lack the cash.
- sangnoir 6y agoGoogle decided on a cheaper technical solution instead - they only recently started abstracting Android drivers from the linux kernel (Project Treble[1]), which should allow drivers to continue working after the kernel has been updgraded. 1. https://android-developers.googleblog.com/2018/11/an-update-on-project-treble.html https://android-developers.googleblog.com/2018/11/an-update-...
- corty 6y agoExcept Qualcom drivers are so crappy, you can rely on a remote exploit via WiFi or BT every year. So no chance to use the phone longer than maybe 2 years, even if nominally the software support might be longer. Not incidentally, "Qual" is german for "torture".
- vetinari 6y agoPartially. You know, your PC has BIOS/UEFI and PCIE busses and other ways for kernel to discover what it is really running on, which drivers to load and so on. ARM devices have none of these (except for servers, where Redhat had enough clout to say, that if your ARMv8 server has no UEFI, it will have no RHEL). Not only they add up to energy consumption (it is extra hardware, after all), they add up in the BOM as well (again, it is extra hardware). So we are stuck with kernels targeting only a known hardware (which today devicetree describes to some degree) and where a poke on a wrong port could mean that the entire device hangs. And after all, no consumers base their decision on whether a third party can replace the operating system, so why make a worse (=worse battery) and more expensive (=more BOM) than the competition?
- eigenvector 6y ago> You're talking about three different classes of device: PCs, phones, and IoT (IoS)/deep embedded. Not really, Google applies the same disposable approach to supporting ChromeOS on bog-standard x86 hardware. I have an x86 Chromebox that Google suddenly dropped all support for - including security patches - with a generic message that "your device is out of its support window". This basically rendered it useless as a ChromeOS device, because you can't browse the public web with an unpatched web browser. Yet I can run up-to-date Linux in Crouton. I don't see how this is technically any different than Microsoft deciding to stop all Windows 10 patches on PCs older than a certain age not because of any blocking compatibility issue, but just because they've passed a certain age threshold and they don't want to do it anymore. I used to evangelize ChromeOS as a great, simple solution for non-technical users who just want to browse the web without the hassle of maintaining a full-fledged PC, but I won't do that if Chrome devices are part of the smartphone "time based support model" rather than the "compatibility based support" model we've had on PCs for decades. A PC for basic use can easily last 10 years, OEMs who arbitrarily shorten that are not helping their customers.
- nonbirithm 6y ago> No, I don't know why we live with it either. Maybe it's the profit motive. If companies are not incentivized to change, then nothing is going to change. If companies pushing OS and hardware refreshes every year means people are going to buy more phones, I'm not sure why they would have any reason to stop. Anecdotally, I needed a new phone because my Pixel XL was getting 4 hours of standby time and was constantly overheating. I had just gotten back from an overseas trip and was nearly stranded several times from finding myself in remote places with my backup battery dead. In the end, I settled for a OnePlus 7 (ironic, I know). I would rather have used the Pixel for many more years. hate not having a headphone jack or bezel, and I know that some product manager is going to use my purchase as evidence that those "features" were the correct move and continue to propagate the belief that nobody wants headphone jacks or bezels anymore. But I was in serious need of a smartphone that was actually reliable over one that had a headphone jack or bezel, so I got one without those features anyway. People like me are now reliant on smartphones to do things like make calls, navigate unknown places or look up things on cellular data. In my book, if people need to have a cellphone in order to function in modern society, or are at least strongly incentivized to have one, then planned obsolescence only increases profits. Companies can market this as "upgrading" to new phones with a festureset that doesn't have to be a significant improvement over the last generation, and if people are used to this and don't mind spending the money to upgrade, then this will continue. And there are surely a lot of people who will buy the lastest model anyway even if they don't absolutely need to upgrade.