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.
I've never heard anyone in real life say "I bought a Samsung phone last time and it was good but it didn't get any updates after 3 years so I'm never buying one again."
Few years ago it was not like that, I don't remember there were official promises and you typically got a year or two of updates. Until recently, long support was always mentioned as a big plus for iPhones.
Now every review I look mentions years of support as a big thing. I also see quite often on forums "I still have year of updates for my device, I'll skip this year's model" so people do think about it.
It's possible only techies look at these things (and read reviews and online discussions), but even so it's still better than it was.
[1] https://www.gsmarena.com/samsung_pledges_4_os_updates_5_year...
> 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.
I don't really think driver robustness is an issue here. The number of phones I've seen, used or heard about with driver problems is zero.
Add in the fact that phones are almost never rebooted (compared to desktops/laptops and other computers), and the driver situation looks incredibly stable.
I was disappointed to find that on many models of phone, there was not a single active user who had not experienced at least one random reboot caused by a kernel panic a year after purchase.
The fact it boots straight back up to the lockscreen means many users will never notice that it's happened though.
The actual stats here will help; across a few million devices, random reboots unrelated to software or drivers will be expected.
You're saying that, one some models, the device never crashed. On others, there was at least one crash. That's at least a 0.00001% crash rate. That's unbelievably good. At that rate it's probably a hardware error, not a driver error.
If you used a different threshold we'd have a better idea - how many models have a crash rate of 10%? 5%?
> The fact it boots straight back up to the lockscreen means many users will never notice that it's happened though.
That provides further evidence that the money being poured into a new kernel to alleviate a problem that happens so rarely it can't be distinguished from statistical noise, and when it does happen, is almost never noticed by the user, is money being wasted.
The return here is not proportionate to the problem being experienced, and the solution is definitely not proportionate to the money being spent.
For at least one user, yes.
But there are many users who maybe only turn the phone on 5 minutes a day to check messages - so it isn't really odd for a few users to never see a crash.
I don't really know anyone who uses their smartphone for less than 5m per day, but that's irrelevant anyway.
The question is still: is the money being put into preventing this problem at all proportionate to the size of the problem?
If there's a problem that no one notices[1], is a solution really worth spending millions of dollars per year over five years?
[1] So few users complained about this it's not even a statistical rounding error.
edit: sure, bit flips will happen at scale, but they’re not as common as bad threaded programming.
But also yes some drivers don't run in kernel space! https://docs.microsoft.com/en-us/windows-hardware/drivers/wd...
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.
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.)
Even though this is true, they still offer the longest updates.
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-g...
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/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.
So what? If it makes them comply then I'm fine with it. No one else has taken on the fight except for a handful of large companies (Vizio and a settop-box-manufacturer whose name I forgot are the only cases I remember). Everyone else, particularly in the phone and embedded sector, outright shits on the GPL for decades now.
Particularly Google would be in an excellent position - they possess the Android trademark, they could require manufacturers and SoC vendors to properly open-source their stuff as part of the Android license, even for AOSP-powered devices.
Governments could also step in, similarly to enforcement of patents, but no government in the world has done anything to establish legal protection for open source that does not rely on open-source authors filing lawsuits on their own! Just imagine customs going on a trade fair and confiscating every device where the GPL and other OSS licenses are not obliged. After two rounds, no one would dare mess around any longer.
> Got a link for that Apple firmware thing?
Unfortunately not, that was many years ago and I might be remembering it wrong :(
Conservancy are doing the Vizio lawsuit, do a lot of behind-the-scenes work, supported the VMware lawsuit, did a lawsuit against Best Buy/Samsung/Westinghouse/JVC and did one of the earliest compliance actions against Linksys resulting in the OpenWRT project:
https://sfconservancy.org/copyleft-compliance/past-lawsuits.... https://sfconservancy.org/copyleft-compliance/enforcement-st...
Harald Welte of gpl-violations.org did a lot of GPL compliance actions in Germany, admittedly none recently.
It would be great if Google could do GPL compliance actions against Android vendors, but they seem to be moving away from GPL projects instead of embracing them, so that seems very unlikely.
There was already a case where a Linux copyright holder got the USA customs department to withhold import of some GPL violating tablets. I think that eventually resulted in compliance, the details are somewhere on LWN, I forget the URL though.
I think if the Vizio lawsuit is concluded in favor of Conservancy, that is probably the best chance for widespread GPL compliance.
An infringement lawsuit can't make anyone comply because a court will only ever order an infringer to pay monetary damages. An infringer might settle a lawsuit by agreeing to comply with GPL terms instead of paying damages, but that's not something a court would order.
Theoretically, if the GPL were a contract (an exchange of promises) and not a license (a grant subject to conditions), then a court could order a party in breach to comply with its terms. A court would only do that, however, if monetary damages were insufficient to compensate the non-breaching party.
https://en.wikipedia.org/wiki/Legal_remedy
The Conservancy lawsuit against Vizio contends that the GPL is also a contract and that downstream users are third-party beneficiaries of that contract, so they should be able to sue for compliance with the contract. Its a really interesting approach and I hope they win. I encourage you to read the court documents, they make for interesting reading.
https://sfconservancy.org/copyleft-compliance/vizio.html
Also, monetary damages are pretty much always insufficient in GPL cases, since money doesn't get you source code. I guess if the money was enough to pay for reverse engineering and reimplementation of the fixes/features present in the non-compliant codebase, then they could be enough.
Exactly.
True, but the community does clean up and upstream stuff over time. It's just very slow work, made even more confusing by how much SoC hardware components are duplicated with small variations in different platforms. De-duplicating and merging drivers for some random IP block can involve pretty serious effort
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.