Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (3)
to General by Kalatti - 22 hrs, 48 mins ago - more...
 |
nthn |
2019-03-20
, 23:26
|
|
Posts: 764 |
Thanked: 2,888 times |
Joined on Jun 2014
|
#31
|
Originally Posted by deutch1976
Likewise on the Jolla Tablet, they never fix any of the myriad of bugs (loads of which must be little more than correcting a typo or other one-line fixes). Even better, they keep introducing new ones. Honestly, as Sailfish updates come and go, what I've started looking forward to most of all are the updates where a new Qt version is introduced, because those fix or work around a lot more bugs than Jolla does in all of its updates combined. I don't blame them for having only a small team to keep an entire OS running on multiple devices, but come on, how is it possible that something as simple as taking a screenshot on the tablet hasn't worked for about two years, or why has no one ever fixed the regression where the Android support is set to English regardless of the current locale, also exclusive to the tablet? The tablet's performance in home menu and launcher is still dire, but at least I can sleep soundly knowing that a Qt update will eventually work around those issues.
| The Following 5 Users Say Thank You to nthn For This Useful Post: | ||
|
|
2019-03-21
, 01:06
|
|
Posts: 440 |
Thanked: 2,256 times |
Joined on Jul 2014
|
#32
|
Originally Posted by nthn
Very few people ever received the Jolla Tablet though, even fewer probably still use it. I understand that sucks if you happen to be one of those exclusive few but I can understand if they don't spend much time on Jolla Tablet only issues.
Likewise on the Jolla Tablet, they never fix any of the myriad of bugs (loads of which must be little more than correcting a typo or other one-line fixes). Even better, they keep introducing new ones. Honestly, as Sailfish updates come and go, what I've started looking forward to most of all are the updates where a new Qt version is introduced, because those fix or work around a lot more bugs than Jolla does in all of its updates combined. I don't blame them for having only a small team to keep an entire OS running on multiple devices, but come on, how is it possible that something as simple as taking a screenshot on the tablet hasn't worked for about two years, or why has no one ever fixed the regression where the Android support is set to English regardless of the current locale, also exclusive to the tablet? The tablet's performance in home menu and launcher is still dire, but at least I can sleep soundly knowing that a Qt update will eventually work around those issues.
It is a bit of a hard situation for them, they want to provide new devices for people to use, but it also serves to spread their efforts thinner as they have more devices to maintain. At least with the Sony Xperia stuff the adaptations are all open so you can help fix things yourself
| The Following 3 Users Say Thank You to r0kk3rz For This Useful Post: | ||
|
|
2019-03-21
, 01:55
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#33
|
Originally Posted by taixzo
I'm afraid that's the only way to go if you want to support both past and future Sailfish OS releases - there is either just libpython 3.4 in SFOS <3.0.2 and only libpython 3.7 in SFOS >= 3.0.2.
This is a bit worrying to me, as I'm currently developing an app that has a Python module that's compiled binary code - do I need to create multiple packages with dependencies on different Python versions? (The compiled code is version-specific.)
To be clear I don't think Python was ever specified as a stable API on the Python library level. And while I had to fix modRana for Python 3.7 it was just a ~5 lines where "async" was used a method argument.
Also, this is basically what distros like Fedora do - a new version of Python is built (recently 3.7, the same Sailfish OS picked up) and all packages using get rebuilt, multiple version of libpython are never carried at the same time.
This is of course easier to do for a fully open source distro where all the packages are built on the Fedora run build infrastructure. A bunch of automated scripts with some proven-package intervention will take care of all the rebuilds in a day or two.
This is unfortunately much harder to do on Sailfish OS as both Harbour/Jolla Store and Open Repos still support only binary package uploads, even for fully open source apps that might even be built on the Mer OBS in the first place.
At least the Jolla store IIRC has a feature where you can specify that a given package upload requires a minimal package version. This might be similar to how in Fedora you might want to only update a package in Fedora 29, but skip doing that on Fedora 28 due to outdated libraries. But I'm actually not sue how the feature really works in the Jolla store - do people on older Sailfish OS releases get an older package version ? Or won't they see the app at all until they upgrade the system ? Not sure.
And Open Repos AFAIK does not really have a notion of SFOS releases & no such per-release options (unless you basically create two separate project pages I'm afraid, or do some nasty hacks in the packaging).
In any case, this is yet another thing that would be fixed by native apps being distributed via Flatpaks. Major lungiage runtime/library updates like this would (I would at least hope!
) trigger the creation of a new base runtime (with Python 3.7 and any new updated incompatible libs) while the previous runtime with Python 3.4 would still be supported for a while, giving application authors enough time to migrate to the new runtime. For users this would be totally transparent - they would simply get the new runtime installed during an app update once an apps starts requiring it. The old runtime would presumably be automatically uninstalled once the last applications stops using it,
__________________
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)
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 7 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2019-03-21
, 01:58
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#34
|
Originally Posted by r0kk3rz
IIRC once of the Russian corporate devices running Sailfish OS was also a tablet. But I am not sure how similar it was to the original Jolla Tablet (is it x86 or ARM ?, etc.). 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.
Very few people ever received the Jolla Tablet though, even fewer probably still use it. I understand that sucks if you happen to be one of those exclusive few but I can understand if they don't spend much time on Jolla Tablet only issues.
It is a bit of a hard situation for them, they want to provide new devices for people to use, but it also serves to spread their efforts thinner as they have more devices to maintain. At least with the Sony Xperia stuff the adaptations are all open so you can help fix things yourself
__________________
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)
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 3 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2019-03-21
, 02:54
|
|
Posts: 440 |
Thanked: 2,256 times |
Joined on Jul 2014
|
#35
|
Originally Posted by MartinK
That device was Mediatek based, so very different to the JTab
IIRC once of the Russian corporate devices running Sailfish OS was also a tablet. But I am not sure how similar it was to the original Jolla Tablet (is it x86 or ARM ?, etc.). 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.
| The Following 3 Users Say Thank You to r0kk3rz For This Useful Post: | ||
|
|
2019-03-21
, 09:49
|
|
Posts: 764 |
Thanked: 2,888 times |
Joined on Jun 2014
|
#36
|
Originally Posted by r0kk3rz
That's true, but it feels like a lot of these bugs are stuff they could fix in two minutes. The problem with Alien Dalvik ignoring the locale, for example, is something you can work around yourself by entering 1 (one) line in the terminal. Besides, I presume the problems would happen on all devices that are similar in design to the tablet. If there's ever a Sailfish X for an Xperia tablet, they'll probably have to fix those bugs anyway.
Very few people ever received the Jolla Tablet though, even fewer probably still use it. I understand that sucks if you happen to be one of those exclusive few but I can understand if they don't spend much time on Jolla Tablet only issues.
Originally Posted by MartinK
I don't think supporting both past and future Sailfish OS releases should ever be a goal, though. As a mobile operating system, Sailfish is not developed to have multiple versions available at the same time. There's only one version and that's the latest version. There are some people missing a couple or even an entire bucket full of screws, who stay on long outdated versions for the most inane reasons (not too long ago I came across someone on TJC who hadn't updated past 1.1.7, by now almost four years old, because he didn't like the UI of what came after - apparently security, a plethora of minor and major bug fixes, much better performance, more features and overall more available applications weren't as important as whether you swipe up or right to view your notifications), but I don't think it's reasonable or even right to support these people in their neophobia.
I'm afraid that's the only way to go if you want to support both past and future Sailfish OS releases - there is either just libpython 3.4 in SFOS <3.0.2 and only libpython 3.7 in SFOS >= 3.0.2.
There's one situation where I think it's okay to explicitly support older versions, and that's when community ports are temporarily stuck on an older version because there's some problems with the new version that still have to be ironed out. Of course, if a community port hasn't received any updates past 1.1.x, it probably doesn't make sense to want to make your application support it.
| The Following 7 Users Say Thank You to nthn For This Useful Post: | ||
|
|
2019-03-21
, 14:25
|
|
Posts: 958 |
Thanked: 3,426 times |
Joined on Apr 2012
|
#37
|
nthn: I sometimes stay on outdated versions, not because of a reason like that, but because they port on whatever device I've been using hasn't been updated to the latest version. (Or because I'm afraid installing an OTA update will break my device again - most recently, updating to 3.0.1.1 on my Xperia X broke all terminal apps, the ability to SSH into the phone, and the ability to install or remove applications, so I think I need to wipe and reinstall yet again - except the Sailfish X image I bought is like six versions back at this point, so I'll then need to spend the next day installing updates...grumble, grumble.)
__________________
Saera: A Siri clone for the N900, N9(50) and Jolla
Follow me on Twitter: twitter.com/taixzo
Saera: A Siri clone for the N900, N9(50) and Jolla
Follow me on Twitter: twitter.com/taixzo
| The Following 4 Users Say Thank You to taixzo For This Useful Post: | ||
|
|
2019-03-21
, 14:59
|
|
Posts: 248 |
Thanked: 1,142 times |
Joined on Dec 2014
@ Earth
|
#38
|
Originally Posted by peterleinchen
He said J[s]1[/s].
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.
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
Jolla tablet as you mention is based on Intel x86 hardware.
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.
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: | ||
 |
|
2019-03-21
, 15:30
|
|
Posts: 4,117 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#39
|
Originally Posted by DrYak
True.
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).
Not using my J1s I commented from JollaC view.
But output problem of 'too less space' is the same either coming from too small free chunks on BTRFS or small rootfs...
__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!
Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257
editsignature, http://talk.maemo.org/profile.php?do=editsignature
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!
Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257
editsignature, http://talk.maemo.org/profile.php?do=editsignature
| The Following 2 Users Say Thank You to peterleinchen For This Useful Post: | ||
 |
|
2019-03-21
, 16:13
|
|
Posts: 394 |
Thanked: 1,341 times |
Joined on Dec 2009
|
#40
|
Originally Posted by taixzo
That does not make much sense to me.
except the Sailfish X image I bought is like six versions back at this point, so I'll then need to spend the next day installing updates...grumble, grumble.)
You didn't buy one specific image version, you bought the "current version as long as the device is supported" AFAIK. While it's fine to hold on to the exact image for, I don't know, perhaps sentimental reasons, I wouldn't use that to reflash.
Please check https://shop.jolla.com/downloads/ for a newer image – and don't waste (as much of) your time. It should have the latest "public" release, so you'll still have to upgrade to EA. Or you wait a bit for 3.0.2 public.
Cheers!
__________________
slumber: sensors enabled sleep timer for SFOS (translations/input/… appreciated if you've got some spare time)
talefish: directory based audiobook player for SFOS
nofono: ofono restart for SFOS
___
list of i486/noarch packages on openrepos (jolla tablet)
slumber: sensors enabled sleep timer for SFOS (translations/input/… appreciated if you've got some spare time)
talefish: directory based audiobook player for SFOS
nofono: ofono restart for SFOS
___
list of i486/noarch packages on openrepos (jolla tablet)
| The Following 8 Users Say Thank You to velox For This Useful Post: | ||