Notices


Reply
Thread Tools
Posts: 1,471 | Thanked: 7,001 times | Joined on Apr 2010 @ Czech Republic
#331
Originally Posted by bennypr0fane View Post
Stupid layman question:
Why *is* mobile hardware support such a shitshow indeed?
I can't explain to myself why - on the one hand - you can just download one of hundreds of linux distros and install them on any old computer, and there's a pretty good chance everything will just work right out of the box (and if it doesn', there's a good chance it can be fixed in a matter of hours); while - on the other´ hand -
there's a company of skillful engineers (Jolla) making it its top priority to make this one Linux distro (Sailfish) run on this specific mobile computer (Sony Xperia X) that they have all the specs and drivers for, but they can't get it finished in a matter of six months? I just don't get it. What accounts for this incredible difference in difficulty?
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.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 43 Users Say Thank You to MartinK For This Useful Post:
Posts: 287 | Thanked: 1,320 times | Joined on Oct 2013 @ France
#332
Great summary here MartinK !

Originally Posted by MartinK View Post
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.
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 !
 

The Following 8 Users Say Thank You to Zeta For This Useful Post:
Venemo's Avatar
Posts: 1,290 | Thanked: 1,753 times | Joined on Aug 2009 @ Budapest, Hungary
#333
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
 

The Following 11 Users Say Thank You to Venemo For This Useful Post:
Posts: 794 | Thanked: 2,572 times | Joined on Jan 2011 @ Germany
#334
Originally Posted by theonelaw View Post
iPhone and any other implementations
will never be serious Operating Systems.

They will remain walled gardens,
virtual toy-store imitations of actual software.
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.


Originally Posted by Fellfrosch View Post
What I find a little bit irritating on the the Librem 5 is, that it comes installed with PureOS, which nobody has ever seen on a small form factor touch device like a smartphone.

So what will work with PureOS and what not. I'm quite sure that Purism has no magical skills and that it is impossible to deliver what so many others has struggled with: A free OS running on a Smartphone, all sensors working and touch optimized.
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
 

The Following 9 Users Say Thank You to sulu For This Useful Post:
Venemo's Avatar
Posts: 1,290 | Thanked: 1,753 times | Joined on Aug 2009 @ Budapest, Hungary
#335
Originally Posted by sulu View Post
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.
[...]

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).
[...]
That should not be an excuse for poor quality.
 

The Following 4 Users Say Thank You to Venemo For This Useful Post:
Posts: 794 | Thanked: 2,572 times | Joined on Jan 2011 @ Germany
#336
Originally Posted by Venemo View Post
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.
 

The Following 3 Users Say Thank You to sulu For This Useful Post:
pichlo's Avatar
Posts: 5,416 | Thanked: 16,674 times | Joined on Sep 2012 @ UK
#337
Originally Posted by Venemo View Post
That should not be an excuse for poor quality.
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.
__________________
In particle accelerators atoms are indeed not only touching each others. But banging together in a massive explosive orgasm.
-- nieldk in a TMO post
 

The Following 4 Users Say Thank You to pichlo For This Useful Post:
gerbick's Avatar
Posts: 6,612 | Thanked: 14,695 times | Joined on Jul 2007 @ undecided.
#338
Originally Posted by pichlo View Post
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.
__________________
gerbick | iPhone X [ 256GB iOS 12.0 Beta ] | iPad Pro [ 256GB iOS 12.0 Beta ]
Former Maemo Council Member - 2015
 

The Following 3 Users Say Thank You to gerbick For This Useful Post:
pichlo's Avatar
Posts: 5,416 | Thanked: 16,674 times | Joined on Sep 2012 @ UK
#339
Originally Posted by gerbick View Post
Let's keep it simple.
Either it functions or it does not.
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.
__________________
In particle accelerators atoms are indeed not only touching each others. But banging together in a massive explosive orgasm.
-- nieldk in a TMO post
 

The Following 3 Users Say Thank You to pichlo For This Useful Post:
Posts: 1,595 | Thanked: 3,409 times | Joined on Mar 2010 @ North Potomac MD
#340
Originally Posted by pichlo View Post
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.

Last edited by mscion; 2018-04-24 at 14:32.
 

The Following 3 Users Say Thank You to mscion For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 00:49.