5 ms·

> Many at Google believe Android to be unsalvageable on two fronts: drivers and the general ecosystem. Could you elaborate? I'm simply curious why people would

by mdasen 5y ago

> Many at Google believe Android to be unsalvageable on two fronts: drivers and the general ecosystem. Could you elaborate? I'm simply curious why people would feel that way about Android. By the ecosystem, do you mean the fact that apps are primarily Java? That they're poorly made? What makes the drivers unsalvageable? Proprietary blobs interacting with the Linux kernel? Something else? It seems like a new kernel would have minimal drivers, but maybe it would offer a better way of having proprietary drivers? Linux doesn't have a stable device driver ABI so maybe that is making it hard for Google to update Android without the phone manufacturer being involved in the updating? I'm just curious what people see as the problems with Android that would require a new OS to fix. For example, if the problem is poorly made apps, that problem will follow you to a new OS if you let them publish for the new OS - and if you truly don't want them, you could remove them from the Play Store.

grumpyprole 5y ago
Linux does not have a stable driver ABI or API.
cletus 5y ago
The drivers part is easier to answer. Where Linux started drivers were compiled into the kernel. A few years later modules came along to dynamically load drivers (and other things). But modules could still (and can still) crash the kernel and the drivers don't necessarily have a particularly stable interface. Compare this to Windows. Drivers were once the bane of Windows and a huge problem for stability. Microsoft invested heavily in this and it seems to have worked. The Windows driver interface is I believe stable and has been for many years at this point and drivers themselves are more insulated from the kernel. Not completely but it's better in many aays. Android really has its hands tied here by what Linux does. You may agree or disagree with that but the above is a view held by influential people within Fuchsia. The ecosystem is really around the process by which updates are released. This is a tedious process of maintaining many Android trees and updating them with new Android releases. These need to be patched onto the existing trees or the changes made to the existing trees need to be ported onto the new Android tree. This is a nontrivial task either way. It's why Android phones get limited updates and those updates can lag behind the official release by months or even years. This isn't a situation Google likes so some want to make the manufacturer responsible for less, most notably the drivers. Remember that Samsung is motivated to sell handsets, not update existing handsets.
- md_ 5y ago
  Huh? Are you saying that in Windows, drivers don’t run in kernel space?
  - Rusky 5y ago
    Some kinds of drivers (e.g. graphics) run at least partially in userspace.
    - md_ 5y ago
      Yeah, but it’s not the norm. Don’t get me wrong. Windows did a lot of work on driver stability. But I think cletus is too narrowly focused, and misunderstanding the context around Android and Fuschia. Fuschia has been described as a replacement for both ChromeOS and Android, with a goal of solving a range of problems (not just driver compatibility) and unifying the target development platform (beyond the somewhat-limited Android-for-ChromeOS options that exist today). It does not seem to me that it’s primarily about fixing Android driver compat, which could probably be done in simpler ways (and, as others have noted, Treble sort of kind of exists to mitigate). (I also was amused that Cletus claimed that Windows drivers run in userspace—generally not true—while claiming that there are no real-world microkernel OSes.)
  - tsujamin 5y ago
    I think they were talking about the various driver frameworks in Windows (WDM, KMDF, UMDF, NDIS and the various miniport drivers) having stable/well-defined interfaces and support libraries. But also yes some drivers don't run in kernel space! https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/overview-of-the-umdf https://docs.microsoft.com/en-us/windows-hardware/drivers/wd...
  - CJefferson 5y ago
    I believe the main problem is that Windows goes to reasonably extremely lengths (it's not perfect, but it's fairly good) to not break the driver interface, so if someone makes a driver for something, then semi-abandons it, the driver will continue to work for many years. This is often clear in graphics cards, the main problem is old cards don't get support for newer versions of DirectX, but otherwise continue to work. Linux explictly doesn't support this -- that means when some hardware manufacturer makes a closed source driver, it's very hard to update the kernel. Unfortunately it seems many bits of important phone hardware (like stuff Qualcomm makes) only have closed source drivers.
KSPAtlas 5y ago
Isn't fuchsia a microkernel?
mschuster91 5y ago
> What makes the drivers unsalvageable? Proprietary blobs interacting with the Linux kernel? Most drivers in the embedded world come from the BSPs (board support packages) of the SoC vendor. And holy hell wherever you look at leaked source code (cough Mediatek) it's madness. Nothing is upstreamed because the quality is so shoddy that you'd get Linus Torvalds into a proper ragepost if you dared to post it for submission, and as a result Android and most of embedded Linux is stuck at outright fossilized kernels where it's extremely hard to backport anything from newer kernels - which is also the reason why so few Android phones are supported for longer than two or three years after initial release. The SoC vendors simply won't provide BSP updates because of the effort involved. And forget about copyright requiring vendors to open-source everything in Linux kernel space... most simply do not care and there is absolutely no will of enforcing it on a large scale - to the contrary, people trying to do so got booted off [1]. The proprietary blobs for components like WiFi/BT/GPU are only the icing on the cake. Barely any effort made to ensure it actually holds up in real world usage, only enough to pass qualification testing. IIRC Apple had at least one RF vendor make a completely new firmware for their chips because the official one was riddled with bugs. [1]: https://sfconservancy.org/blog/2016/jul/19/patrick-mchardy-gpl-enforcement/ https://sfconservancy.org/blog/2016/jul/19/patrick-mchardy-g...
- pabs3 5y ago
  Patrick McHardy wasn't interested in GPL compliance and source code release, only in extracting money from non-compliant companies. Software Freedom Conservancy's approach on the other hand is to require compliance. Through their lawsuit against Vizio they are also aiming to make it possible for any user of GPLed but non-compliant software to sue for compliance. Hopefully this will change the amount of spontaneous GPL compliance for Linux in the industry. https://sfconservancy.org/copyleft-compliance/vizio.html https://sfconservancy.org/copyleft-compliance/vizio.html https://sfconservancy.org/copyleft-compliance/principles.html https://sfconservancy.org/copyleft-compliance/principles.htm... Got a link for that Apple firmware thing? Sounds interesting. We really need open firmware for hardware devices. There is some for very old hardware though. https://wiki.debian.org/Firmware/Open https://wiki.debian.org/Firmware/Open
  - 5y ago

by mdasen 5y ago

grumpyprole 5y ago

Linux does not have a stable driver ABI or API.

cletus 5y ago

The drivers part is easier to answer. Where Linux started drivers were compiled into the kernel. A few years later modules came along to dynamically load drivers (and other things). But modules could still (and can still) crash the kernel and the drivers don't necessarily have a particularly stable interface. Compare this to Windows. Drivers were once the bane of Windows and a huge problem for stability. Microsoft invested heavily in this and it seems to have worked. The Windows driver interface is I believe stable and has been for many years at this point and drivers themselves are more insulated from the kernel. Not completely but it's better in many aays. Android really has its hands tied here by what Linux does. You may agree or disagree with that but the above is a view held by influential people within Fuchsia. The ecosystem is really around the process by which updates are released. This is a tedious process of maintaining many Android trees and updating them with new Android releases. These need to be patched onto the existing trees or the changes made to the existing trees need to be ported onto the new Android tree. This is a nontrivial task either way. It's why Android phones get limited updates and those updates can lag behind the official release by months or even years. This isn't a situation Google likes so some want to make the manufacturer responsible for less, most notably the drivers. Remember that Samsung is motivated to sell handsets, not update existing handsets.

md_ 5y ago
Huh? Are you saying that in Windows, drivers don’t run in kernel space?
- Rusky 5y ago
  Some kinds of drivers (e.g. graphics) run at least partially in userspace.
  - md_ 5y ago
    Yeah, but it’s not the norm. Don’t get me wrong. Windows did a lot of work on driver stability. But I think cletus is too narrowly focused, and misunderstanding the context around Android and Fuschia. Fuschia has been described as a replacement for both ChromeOS and Android, with a goal of solving a range of problems (not just driver compatibility) and unifying the target development platform (beyond the somewhat-limited Android-for-ChromeOS options that exist today). It does not seem to me that it’s primarily about fixing Android driver compat, which could probably be done in simpler ways (and, as others have noted, Treble sort of kind of exists to mitigate). (I also was amused that Cletus claimed that Windows drivers run in userspace—generally not true—while claiming that there are no real-world microkernel OSes.)
- tsujamin 5y ago
  I think they were talking about the various driver frameworks in Windows (WDM, KMDF, UMDF, NDIS and the various miniport drivers) having stable/well-defined interfaces and support libraries. But also yes some drivers don't run in kernel space! https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/overview-of-the-umdf https://docs.microsoft.com/en-us/windows-hardware/drivers/wd...
- CJefferson 5y ago
  I believe the main problem is that Windows goes to reasonably extremely lengths (it's not perfect, but it's fairly good) to not break the driver interface, so if someone makes a driver for something, then semi-abandons it, the driver will continue to work for many years. This is often clear in graphics cards, the main problem is old cards don't get support for newer versions of DirectX, but otherwise continue to work. Linux explictly doesn't support this -- that means when some hardware manufacturer makes a closed source driver, it's very hard to update the kernel. Unfortunately it seems many bits of important phone hardware (like stuff Qualcomm makes) only have closed source drivers.

KSPAtlas 5y ago

Isn't fuchsia a microkernel?

mschuster91 5y ago

> What makes the drivers unsalvageable? Proprietary blobs interacting with the Linux kernel? Most drivers in the embedded world come from the BSPs (board support packages) of the SoC vendor. And holy hell wherever you look at leaked source code (cough Mediatek) it's madness. Nothing is upstreamed because the quality is so shoddy that you'd get Linus Torvalds into a proper ragepost if you dared to post it for submission, and as a result Android and most of embedded Linux is stuck at outright fossilized kernels where it's extremely hard to backport anything from newer kernels - which is also the reason why so few Android phones are supported for longer than two or three years after initial release. The SoC vendors simply won't provide BSP updates because of the effort involved. And forget about copyright requiring vendors to open-source everything in Linux kernel space... most simply do not care and there is absolutely no will of enforcing it on a large scale - to the contrary, people trying to do so got booted off [1]. The proprietary blobs for components like WiFi/BT/GPU are only the icing on the cake. Barely any effort made to ensure it actually holds up in real world usage, only enough to pass qualification testing. IIRC Apple had at least one RF vendor make a completely new firmware for their chips because the official one was riddled with bugs. [1]: https://sfconservancy.org/blog/2016/jul/19/patrick-mchardy-gpl-enforcement/ https://sfconservancy.org/blog/2016/jul/19/patrick-mchardy-g...

pabs3 5y ago
Patrick McHardy wasn't interested in GPL compliance and source code release, only in extracting money from non-compliant companies. Software Freedom Conservancy's approach on the other hand is to require compliance. Through their lawsuit against Vizio they are also aiming to make it possible for any user of GPLed but non-compliant software to sue for compliance. Hopefully this will change the amount of spontaneous GPL compliance for Linux in the industry. https://sfconservancy.org/copyleft-compliance/vizio.html https://sfconservancy.org/copyleft-compliance/vizio.html https://sfconservancy.org/copyleft-compliance/principles.html https://sfconservancy.org/copyleft-compliance/principles.htm... Got a link for that Apple firmware thing? Sounds interesting. We really need open firmware for hardware devices. There is some for very old hardware though. https://wiki.debian.org/Firmware/Open https://wiki.debian.org/Firmware/Open
- 5y ago