View Single Post
Posts: 248 | Thanked: 1,142 times | Joined on Dec 2014 @ Earth
#38
Originally Posted by peterleinchen View Post
It is due to the bad approach of Jolla to give a small rootfs in favour of BIG user data. Just deinstall some huge applications and reinstall them after update.
He said J[s]1[/s].
That one is BTRFS based and uses subvolumes on the same partition. (So mort of ther problems are around freeing chunks - hence my port).
Not LVM (which would have had the exact same problem if Jolla went for the thin provisionned pools route).

Originally Posted by MartinK View Post
So while we might get some general tablet UI fixes, it's for example unlikely the Android layer gets fixes given that the corporate Sailfish OS, if I am not mistaken, does not contain the Android emulation layer at all by design.
Jolla tablet as you mention is based on Intel x86 hardware.
Meaning that it could run vanilla upstream kernels rather more easily than smartphones (or ARM-based tablets).

But currently, Jolla Tablet runs an Android kernel using the same kind of libhybris-based abtraction layer that they use on smartphone, for ease of development (based on what tablet owners have reported).
Which means that the tablet is stuck with whatever old android kernel was available back when it was designed.
Which also means that it can only run old Android user-space and won't be able to run the modern 8.1 Oreo-compatible Android abstraction layer that Jolla has made for Xperia XA2.

In theory, because Intel hardware is more open-source friendly, it should be possible for devs to retarget an upstream modern Linux kernel (4.19, 4.20, 5.0, whatever).
Once that is done, it should also be possible to compile the additionnal android specific modules which are important for Android, and then either run the "andbox" container-based solution for android abstraction, or see if the current 8.1 Oreo android layer from Jolla could be ported to tablet's x86 arch.
So in theory no technical blocker.

In practice it's not going to happen because that costs tons of development time, whic Jolla can't invest, even more so for a platform that didn't even get release properly.

But their current android compatibility layer is container based, and simply rely on the underlying kernel+blobs to provide the appropriate APIs, and that's about it.
As long as their newer corporate tablets are based on an android ARM platform and use libhybris for the abstraction layer, they're going to provide android-ish APIs (by design) and could in theory be leveraged for the android apps compatibility layer.
In theory, no technical blocker for ARM-based tablet that use hardware normally designed for android.
In practice, nobody at Jolla is ever going to spend time making sure that the compatibility layer works, as there is absolutely zero interest from the corporate client. Why blow uselessly ressource on a feature that nobody will use?
 

The Following 5 Users Say Thank You to DrYak For This Useful Post: