Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 6 hrs, 53 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 10 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 23 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 22 hrs ago - more...
|
2018-02-04
, 18:19
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#12
|
Originally Posted by MartinK
Is there any reason why SailfishOS couldn't be built on top of, say, Fedora, just like Linux Mint is built on top of Ubuntu? The current repository state is a nightmare, with everything as old as the current CentOS release.
The thing is that by lacking an upstream community distribution being developed in the open (a tried and tested model used in Fedora/RHEL, OpenSUSE/SLES, Debian/Ubuntu) Sailfish OS is in a pretty bad position.
Community can't help with testing and integration of new components, so it all falls back to internal Jolla developers, delaying library and toolchain updates further and further. This also effectively mean most components don't have a stable maintainer, so even if community members want to contribute improvements an fixes to open parts of Sailfish OS, it takes ages to get them merged.
So while the community + stable/enterprise distro model is definitely not without overhead, I think Jolla is seriously risking it's future without using it - and without enabling more community involvement overall. It's pretty apparent at this point that both single-handedly maintaining it's own distro in a reasonably current & safe state without community help and also adding new features and hardware support is not really working out.
Originally Posted by mosen
There's one thing most of people out there are missing, I guess. It's a really, really big problem that we have absolutely no app compatibility between Nemo and Sailfish.
It comes to mind, the comparison Jolla/Apple also has some substance. The good part of apples success is presenting a consistant experience to the user. The propriatary bits of sailfish are mostly those that have direct influence to this red-line/UX. Imho jolla planned a trade-off between control over ux and not having the advantage of foss contributions in those areas.
How this plan turned out with decreasing inhouse dev-force and community is another matter. Good intentions, crippled by (market) reality.
I mean, if you want your application work on both Nemo and Sailfish, you need to maintain two trees of your QML sources. That's a big maintenance burden.
The lack of abstraction layer allowing to target both these platforms has a disastrous effect - there are virtually no Nemo applications, which means that those, who would sacrifice the eye-candy for a fully open source stack, well, can't. Even though the platforms are so pretty similar.
|
|
2018-02-04
, 20:16
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#13
|
Originally Posted by marmistrz
That's more or less the point - I don't think there is any good reason anymore. A modern Linux distribution is not really that different from what Jolla is trying to achieve with Mer - some pieces of software (mobile middleware) might have to be packaged for it but that should be it more or less. The important pieces are on top (mobile UI, mobile applications. etc.) but they are not getting enough attention due to the "guts" eating a lot of time just o keep stuff kinda working.
Is there any reason why SailfishOS couldn't be built on top of, say, Fedora, just like Linux Mint is built on top of Ubuntu?
One thing to note is the length of support given distributions provide. For example Fedora supports a release for ~1 year. After that no updates (including security updates) are provided. So Sailfish OS would have to take this into account or else it would be back to the current situation (maintaining it's own thing). Alternatively a distribution with a longer support period could be selected (with the potential downside of slightly older versions of software).
There is also the question of ABI - as long as you want to make it possible for people to submit closed source compiled applications to the Jolla Store that's something to think about. In Fedora, everything just gets rebuild and fixed as necessary due to all software being open source. But that should be something Flatpak should be able to solve as it provides stable application runtimes independent of the distribution underneath.
BTW, as for version of software available in Fedora:
All that maintained and tested for you (including security fixes) by the community and other interested parties, while you can concentrate on your area of expertise (mobile stuff).
Originally Posted by marmistrz
Actually, it's in many cases significantly older than CentOS. CentOS 7 has been released in July 2014 and since then many packages have been rebased (mostly in 7.2 & 7.4) while keeping the promised ABI guarantees. All packages also have a maintainer and are getting prompt security fixes thanks to RHEL7.
The current repository state is a nightmare, with everything as old as the current CentOS release.
In comparison many packages in the Sailfish OS repository have not been touched since ~2013 and many likely have no real maintainer. Also CentOS has no problem with shipping GPLv3 software while SailfishOS still clings to stone-age old GPLv2 versions of many libraries for dubious reasons.
Originally Posted by marmistrz
Actually, I would say the main issue is Sailfish OS not shipping Qt Quick Controls while Nemo had Controls from the start and based their own QML component set on them.
There's one thing most of people out there are missing, I guess. It's a really, really big problem that we have absolutely no app compatibility between Nemo and Sailfish.
I mean, if you want your application work on both Nemo and Sailfish, you need to maintain two trees of your QML sources. That's a big maintenance burden.
The lack of abstraction layer allowing to target both these platforms has a disastrous effect - there are virtually no Nemo applications, which means that those, who would sacrifice the eye-candy for a fully open source stack, well, can't. Even though the platforms are so pretty similar.
If Controls were available on both platforms, application authors could opt for having less native look but supporting both platforms (+ desktop Linux/Android & Windows).
Actually while I can understand the attempt to "feel native" and do your own thing, in my opinion all the distribution specific QML components are causing more bad than good, due to destroying application compatibility and leading to even more fragmentation.
It would be like if you could not run a GTK3 or Qt5 application for Fedora on Ubuntu due to Fedora having Fedora components and Ubuntu having Ubuntu components (well, Ubuntu kinda tried that with Ubuntu Touch components and how it went...). I would rather see any mobile usage shortcomings being fixed in Controls, with possible some platform specific theming of UI element. That seems much more worthwhile to me.
As for potential solutions for the Sailfish OS/Nemo/other compatiblity issues:
- opensource Silica so that it can run on Nemo and elsewhere
- provide Controls on Sailfish OS
- use Universal Components like modRana (makes it possible to have a single application UI code that works with both Silica and Controls)
- use Flatpak to decouple the application runtime from the distribution and have a runtime provide a component set
__________________
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 14 Users Say Thank You to MartinK For This Useful Post: | ||
|
|
2018-02-05
, 08:06
|
|
Posts: 285 |
Thanked: 1,900 times |
Joined on Feb 2010
|
#14
|
Originally Posted by MartinK
Another part is the support for Android applications and the necessity to use Android drivers on mobile devices. This quite effectively prevents being on the bleeding edge. Using some more or less niche hardware that has native driver support for Linux could be an alternative, however, it would severely limit already limited availability of devices to run Sailfish.
That's more or less the point - I don't think there is any good reason anymore. A modern Linux distribution is not really that different from what Jolla is trying to achieve with Mer - some pieces of software (mobile middleware) might have to be packaged for it but that should be it more or less. The important pieces are on top (mobile UI, mobile applications. etc.) but they are not getting enough attention due to the "guts" eating a lot of time just o keep stuff kinda working.
|
|
2018-02-06
, 07:57
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#15
|
Originally Posted by MartinK
There's one more superb thing missing, that was there on Fremantle and disappeared with the advent of Nokia Store for N9 - the extras repository.
There is also the question of ABI - as long as you want to make it possible for people to submit closed source compiled applications to the Jolla Store that's something to think about. In Fedora, everything just gets rebuild and fixed as necessary due to all software being open source. But that should be something Flatpak should be able to solve as it provides stable application runtimes independent of the distribution underneath.
(...)
Actually, I would say the main issue is Sailfish OS not shipping Qt Quick Controls while Nemo had Controls from the start and based their own QML component set on them.
If Controls were available on both platforms, application authors could opt for having less native look but supporting both platforms (+ desktop Linux/Android & Windows).
Actually while I can understand the attempt to "feel native" and do your own thing, in my opinion all the distribution specific QML components are causing more bad than good, due to destroying application compatibility and leading to even more fragmentation.
It would be like if you could not run a GTK3 or Qt5 application for Fedora on Ubuntu due to Fedora having Fedora components and Ubuntu having Ubuntu components (well, Ubuntu kinda tried that with Ubuntu Touch components and how it went...). I would rather see any mobile usage shortcomings being fixed in Controls, with possible some platform specific theming of UI element. That seems much more worthwhile to me.
As for potential solutions for the Sailfish OS/Nemo/other compatiblity issues:
As long as we consider only open-source applications (or even visible-source), this solves all ABI compatibility problems, since the applications can be easily rebuilt. [assuming ideal backwards compat mode in the compilers]
IMHO, a usual, desktop-like repository for the open-source apps and Jolla Store for the closed ones would be a good solution. And the ones in the Jolla Store could use that flatpak/snap/whatever, open source developers shouldn't have to.
Originally Posted by MartinK
I would love to see Silica open source, but seeing how long the community has asked for even smaller open-source-actions with the usual blame on the shareholders as a reply, I don't believe it will happen in the near future.
- opensource Silica so that it can run on Nemo and elsewhere
- provide Controls on Sailfish OS
- use Universal Components like modRana (makes it possible to have a single application UI code that works with both Silica and Controls)
- use Flatpak to decouple the application runtime from the distribution and have a runtime provide a component set
SailfishOS-themed Qt Quick Controls would be a great thing to replace Silica and move the development burden mostly onto the Qt developers. This is more likely than Silica getting open-source but looking at how SailfishOS is trying to get up-to-date with upstream...
MartinK, please, please advertise your Universal Components in the signature. The developers should know that they can develop applications in a portable manner.
People writing apps with Universal Components will have one definitive advantage - as soon as a fully-free-as-in-freedom distribution arises, porting the applications will be pretty easy. Much easier than currently.
Originally Posted by JulmaHerra
I see it as a parallel issue - SailfishOS could make a periodical rebase upon some desktop distribution every n months, just like Linux Mint does with n = 24. All of this is mostly userland, so this shouldn't be so bad.
Another part is the support for Android applications and the necessity to use Android drivers on mobile devices. This quite effectively prevents being on the bleeding edge. Using some more or less niche hardware that has native driver support for Linux could be an alternative, however, it would severely limit already limited availability of devices to run Sailfish.
__________________
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here
Last edited by marmistrz; 2018-02-06 at 08:12.
|
|
2018-02-06
, 09:04
|
|
Posts: 440 |
Thanked: 2,256 times |
Joined on Jul 2014
|
#16
|
Originally Posted by marmistrz
There is nothing stopping anyone from curating an extras-repo on the Mer OBS, we've had this idea a number of times but it comes down to someone spending time curating and reacting to submission requests .etc
IMHO, a usual, desktop-like repository for the open-source apps and Jolla Store for the closed ones would be a good solution. And the ones in the Jolla Store could use that flatpak/snap/whatever, open source developers shouldn't have to.
There is also nothing stopping anyone from building QtControls either, sure from an app developers perspective you don't want to have to build your own stack but jolla is clearly interested in Silica and not interested in maintaining multiple UI component sets. Same thing with GTK3 or whatever you wanted.
QuasarMX and Situations are examples of apps in harbour that do not use Silica, so its not even the case that Jolla forces people to use Silica at all.
| The Following 9 Users Say Thank You to r0kk3rz For This Useful Post: | ||
|
|
2018-02-06
, 10:23
|
|
Posts: 285 |
Thanked: 1,900 times |
Joined on Feb 2010
|
#17
|
Originally Posted by marmistrz
It's not parallel issue as long as Android drivers are needed. You cannot rebase to some desktop distribution that has been built on top of newer kernel version which breaks compatibility with available drivers. Mobile devices still differ from standard desktop/server hardware on that part. At minimum you would either break compatibility with older devices and Sailfish versions, or you end up maintaining many different branches of SailfishOS, which would add strain to already too limited resources. Or, if you tried to rebase and then use older kernel, I'm quite sure it wouldn't happen without some amount of patching - all of which would have most likely to be done by Jolla as we already have seen that open sourcing parts doesn't seem to attract much interest in fixing problems even in cases where problems are loudly touted in the community.
I see it as a parallel issue - SailfishOS could make a periodical rebase upon some desktop distribution every n months, just like Linux Mint does with n = 24. All of this is mostly userland, so this shouldn't be so bad.
I'm also not that convinced that it would benefit SailfishOS to couple it to desktop distribution. What would be the benefit to weight against losing much of control in development?
 |
|
2018-02-06
, 10:43
|
|
Posts: 3,790 |
Thanked: 5,718 times |
Joined on Mar 2006
@ Vienna, Austria
|
#18
|
Originally Posted by JaechenLi
Actually they are fundamentally different.
Now notice the similarities between the Google's and Jolla's approach.
|
|
2018-02-06
, 10:46
|
|
Posts: 440 |
Thanked: 2,256 times |
Joined on Jul 2014
|
#19
|
The 'base distribution' problem is one of those things that sounds really easy but the devil really is in the details. At minimum there's keepalive and iphb handling patches for certain things, and because they're at the bleeding edge for their usecases they need to be able to control their own packages quite carefully.
You really think a small company like Jolla would maintain their own code forks for everything unless there was a real benefit to doing so?
Purism seem intent of building their mobile distro off Debian so I guess we will see how they go.
You really think a small company like Jolla would maintain their own code forks for everything unless there was a real benefit to doing so?
Purism seem intent of building their mobile distro off Debian so I guess we will see how they go.
|
|
2018-02-07
, 07:50
|
|
Posts: 1 |
Thanked: 11 times |
Joined on Feb 2018
|
#20
|
Originally Posted by benny1967
It's great to justify the opinions. Well, maybe the reasons were different, but the outcome is just the same.
Actually they are fundamentally different.
I have the impression that I'm better off using Android. Why?
I'm using LineageOS and take all of my apps from F-Droid, so basically the only proprietary blobs on my device are the drivers, which is something I can't avoid.
I'm using an open-source keyboard, open-source IMs, open-source mail clients, open-source everything. Now see, how much of this is closed or unavailable on SailfishOS.
And I'm concerned about the privacy threats here too, especially when SailfishOS is to be bought by the Russian Rostelkom. Especially when it comes to things like the keyboard.
| The Following 11 Users Say Thank You to Yaltaaaaaaaaaaaaaaaaa For This Useful Post: | ||
Thanks for voicing your concerns and making me reflect the situation once again.
It comes to mind, the comparison Jolla/Apple also has some substance. The good part of apples success is presenting a consistant experience to the user. The propriatary bits of sailfish are mostly those that have direct influence to this red-line/UX. Imho jolla planned a trade-off between control over ux and not having the advantage of foss contributions in those areas.
How this plan turned out with decreasing inhouse dev-force and community is another matter. Good intentions, crippled by (market) reality.
Now we are left with a situation that invites conspiracy theories the one way or the other
Watch our weird watchfaces for mighty AsteroidOS
Performance comparison Video Sailfish 2.0 vs 1.1.9 vs 1.1.7
[MC eV] Maemo Community eV membership application please concider to join!