View Single Post
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#13
Originally Posted by marmistrz View Post
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?
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.

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 View Post
The current repository state is a nightmare, with everything as old as the current CentOS release.
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.

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 View Post
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.
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:
  • 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)
 

The Following 14 Users Say Thank You to MartinK For This Useful Post: