There are a couple reasons, that when combined result in the current unfortunate situation:

Embedded hardware development technique spilling over

Anyone who ever worked with embedded hardware might will likely confirm that the way how software is developed and deployed is often far from ideal (ancient kernels/tools/compiler, hacky deployment tools and general lack of standardization). This still generally works out for fire-and-forget-embedded devices with infrequent or even no firmware updates once deployed in the field.

But things generally fall apart when you try to apply the same techniques to what is basically a mass market small computer used by regular people used to desktop update schedules. The embedded techniques just no longer scale.

Lack of BIOS & device enumeration APIs

X86 PCs and servers generally have BIOS (old style or EFI based), which is a built-in minimal OS that when the computer starts up brings up the hardware, checks it's working correctly and then hands control over to the really OS (Linux/Windows/etc.). The BIOS also provides some hardware enumeration APIs, such as ACPI, that the OS can use to enumerate hardware on the given machine and act accordingly.

There is no such thing on mobile ARM devices.

And that's a big problem - the Linux kernel needs to known on exactly which hardware it will run and do all the low-level configuration and checking itself. There are generally also no device enumeration APIs so you need to hardcode the exact hardware configuration to your kernel or else stuff will not work.

This was the reasons that it used to be the norm in the past that there was separate kernel fork for every specific device variant. Compare that with situation where there is exactly one kernel a distro, such as Fedora, maintains and that works on all hardware Fedora supports thanks to BIOS handling all the low level hardware configuration details.

BTW, a bit of trivia - who can we thank for universal availability of BIOS & ACPI on x86 devices ? Microsoft, really! They needed one OS image that can work on all the hardware and thanks to the dominant position of Windows x86 hardware companies had no choice than to provide what was needed for that, which was BISO, ACPI & co.

Linux then basically piggy-backed on that.

Thankfully, situation seems to be hopefully improving on the ARM front. There is now the device-tree mechanism where the Linux kernel get a blob describing the current hardware. This way a single kernel can handle multiple versions of BIOS-less hardware. On the other hand the kernel still needs to do all the low-level hardware setup. Also some hardware, generally ARM servers, has EFI-based bios (see SBSA for more details).

Time to market

Mobile device market seems to be still moving more quickly than the PC market, so how quickly you can get you device out of the door with some new features/better performance/lower price than the competition. That includes hack to hell software because there just was no time to do things properly. But hey, you were first!

Planed obsolescence

The hardware vendors generally get the most money from you when they sell you the device - they have no real monetary incentive to keep supporting the device afterwards. Actually the opposite - if they quickly stop supporting it, you are more likely to buy a new one, possibly from them.

This is why I really like the Sailfish X subscription model - it has a chance to break this vicious circle.

People still generally don't care

General users don't seem to really care about both running unsecure software and throwing the device away when it no longer works for them. That again does put less pressure on hardware manufacturers to do things properly.

People seem to care more about not throwing away desktop/laptop hardware - maybe because of prior experience or because it's larger ?

Google vendor lockin

Some issues on Android also stem from the meddling Google is doing to gain ever more control over Android via the Google play services API which more and more Android applications depend on. Another vector which Google uses to control Android hardware manufacturers is the Open Handset Alliance. See the Arstechnica article for details of how this all works.

Great summary here MartinK !

If someone needs an example of what hardcoding the peripherals list for every device means, take a look at the dts subdirectory for arm in the linux kernel source : https://git.kernel.org/pub/scm/linux...ts?h=v4.17-rc2
There are hundreds of files in there, and that's only for the devices *supported* upstream (ok, some are included by other and shared, but that doesn't change much the results)...

You can find different things here like raw chips (NXP, TI, Atmel, even Xilinx Zynq), SBC like odroids, industrial modules likes Toradex's ones, and finally phones like the mighty N900 or N9 OMAPs.

PS : there are even dts for STM32F7/H7, which are Cortex-M architecture, not Cortex-A !

MartinK has summarized it pretty well, I could not have said it better myself.

I have one more thing to add, though: android video drivers are a mess, because the android kernel is purposefully engineered in such a way that video drivers that work on android will not work on the upstream kernel. So even if a manufacturer has any incentive to make the android driver available, it won't work from a non-android system. This is why they made hacks like libhybris to combat this situation.

This article from Greg Kroah-Hartman summarizes it very well:
http://www.kroah.com/log/linux/andro...-problems.html

Let's face it:
"Serious Operationg Systems", i.e. systems the end user has full control over and can in principle accomplish any task with are a thing of the past, and these times won't be coming back.
30 years ago, the vast majority of computer users were geeks. Being able to understand and change the way their devices work was part of their life style, and there was pretty much no point for non-geeks in using a computer at all.
Today, these same geeks are just a small fraction of all the computer users, because today a lot of people use computers that 30 years ago didn't even know what a computer was. Ironcally some people still don't know, but today it doesn't stop them from using computers anyways because computers have become ubiquitous.

Some people say that computers have just "grown up", because they think that this state of maturity includes that the end user would not have to care about how it works. It just does.
For the manufacturer this mindset facilitates support and generates additional ROI (user data).
For the average end user it's convenient because walled gardens are comfortable and pretty as long as you accept the walls around you.
The laws of the market dictate, that the needs of the many (average users) outweigh the needs of the few (geeks).

In that regard, x86 (and probably even more so GNU/Linux/the unix aproach) is a relic of another era, that's only still around because it works well and in its niche never allowed any competitor to gain a foothold.


I've tried the desktop variant of PureOS on a laptop and it's basically just the same like Debian with Gnome.
In principle Gnome could work well on a big touch screen (10"+), but because the Gnome devs refuse to resize the desktop area when the on-screen keyboard is shown, it actually does not work. They say that resizing the desktop would irritate the user, but not resizing it means that terminal windows (or anything where the lower part of the screen is essential) become useless.
I found that Xfce with the "Onboard" [1] keyboard works much better.

On small screens I still don't understand how working without a hardware keyboard can work at all. On a 5" screen you basically need the whole screen to display a half-way useable keyboard, because unlike on a hardware keyboard where you get haptic feedback before(!) a key is pressed (e.g. N900) you can't make the individual keys on an on-screen keyboard any smaller than a fingertip.
I understand that on-screen phone keyboards basically circumvent this limitation by auto completion and auto correction and that seems to work well for texts that are adressed to humans. But I can't imagine this would work in a terminal where you type highly context-sensitive arbitrary two-letter commands.


[1] https://launchpad.net/onboard

That should not be an excuse for poor quality.

It's not meant o be one.
It just shows that "good quality" doesn't really matter, because most customers don't care which leads to manufacturers not having to focus on it.

In addition to what sulu said, one's definition of "quality" may differ. By most people's definitions, quality is about stability, reliability, ability to perform desired tasks, even aesthetics. "I can hack and modify it to no end" does not come anyway near the top of quality criteria.

This continued approach to discussion potentially delves too deeply into semantics.

Let's keep it simple.

Either it functions or it does not. When it is seemingly cobbled together, the ease of entering "it doesn't function" happens too easy. I'm overlooking efficiency, extensibility, ease of use, ease or programming and integration on purpose. Those are deflections into even more arguments/discussion points for a rather simple subject.

There's really no need to go into some multiple page semantic discussion about something that's easy to break down, but harder to qualify when limiter words like "quality" are being thrown about and are subject to whatever you decide is the word you want to center your argument about. It's tiresome.

Simply stated, the state of the quality is shaky at best. And that is not ideal.

Indeed. Can I run [an application of my choice that is vital for me] on OS A? No, I can't. Can I run it on OS B? Yes, I can. Conclusion, I don't care what's under the bonnet. OS A is rubbish, OS B is the bee's knees.

I agree with this up to a point. The problem I have is with not caring about "what's under the bonnet" as you may be losing functionality or performance because the hardware is not designed with OS in mind. A simple example is using a virtual machine for Linux on windows computer. Also, chrooting linux on android, while can be useful, leaves something to be desired.