Yes, although Glacier has never really reached a state suitable for daily use, and it’s still far from matching the quality and polish of Silica.
How can one test this nemomobile and glacier?
there you are: https://nemomobile.net/, I’ve never install it because I don’t think it’s usable as a daily driver, but I’ll be glad to know what people think if they test it.
2 Likes
I think it’s also worth mentioning that only 2 devices are currently supported according to the table. So you won’t probably be able to test it unless you have one of them, but I guess you can try it in a virtual machine.
Nice, thank you. But 3 compatible devices, hard to get and v-expensive!!
Make alternative OS’es for cheap mass ware phones. Why is Lineage OS able to support dozens of devices and all this SFOS and it’s anchestors only few?
Actually, there are only two — the third one is a virtual machine. I’m probably not the best person to answer this question; those working on community ports could provide more accurate insights. However, my understanding is that the challenge lies in the lack of direct access to hardware components, requiring the use of an abstraction layer. This adds complexity and increases the cost in terms of both time and resources.
Chatgpt knows it better:
Why Sailfish OS (SFOS) supports only a few devices:
Not Android-native:
- SFOS is a Linux-based OS that runs a different middleware stack (libhybris + Mer/Nemo stack), and although it uses some Android components via compatibility layers, it’s not Android itself. That means it can’t directly reuse all of Android’s existing work without adaptation.
Relies on libhybris and Android base layers:
- SFOS ports run on top of Android kernels and vendor blobs using libhybris, a compatibility layer that allows using Android drivers in a Linux environment. But setting this up is fragile and device-specific — it’s more like reverse-engineering than native support.
Each port is custom and harder to maintain:
- Because there’s no “standardized” device tree approach like Android’s, each SFOS port requires a lot of manual adaptation. Even small differences between phones (e.g. in sensors, cameras, firmware quirks) can break things.
Smaller community & commercial constraints:
- Jolla (the company behind SFOS) is small and focused mostly on business/government clients. They officially support only a few devices. Community ports exist but are harder to maintain without upstream support.
4 Likes
Ok, thank you. May i summarize it as simply ‘nobody wants to do it’?
Actually, a lot of people are actively working on community ports and dedicating their time without any compensation, so I wouldn’t say it’s due to a lack of effort. The real issue is that hardware which fully supports mainstream Linux — and avoids all the problems mentioned above — simply isn’t available. Porting is a complex, time-consuming process that demands a high level of skill. Personally, I’d place the blame on the lack of open, Linux-friendly hardware.
4 Likes
Why on Earth would we want to downgrade it to GTK when we have Qt6 as an upgrade path? 
3 Likes
Perhaps because I am not a developer and am not aware of the differences between GTK and Qt.
But mainly because I look at it as a user and I see that there are several applications written in GTK that are compatible with smartphones.
1 Like
And then there apps developed for Plasma Mobile, Sailfish OS, and Ubuntu Touch (UBPorts) that are all written in some form of Qt (whether that be Qt6 + Kirigami on Plasma Mobile, Qt5 + Silica on Sailfish OS, Qt5 + LomiriUserInterfaceToolkit on Ubuntu Touch). Kirigami ones most notably “are compatible with smartphones” if supported by the developer.
While it is certainly achievable to have a competent progressive app that scales across form factors, in my experience most apps end up having a watered down experience as a result. You either end up with the app on desktop not taking advantage of its form factor (larger resolution screens, mouse & keyboard, shortcuts, not shoving everything under the sun under a hamburger menu, etc.) or an app on mobile that just isn’t well thought-out in terms of daily ergonomics. Ideally, you have the business logic separated as much as possible from the UX layer, use some shared componentry, and have effectively two dedicated apps that best target their respective form factor).
With GTK3 → GTK4, more widgets you would have liked to use (that ideally should’ve been base Gtk4 widgets) were instead put in in platform libraries (libadwaita), forcing a given user style across all form factors regardless of (desktop) environment. The expectation is more will shift to platform libs in GTK5 and beyond.
Expanding on that, Gdk and Gtk just don’t have the same set of APIs as Qt does. You will need to integrate directly with more with third-party libraries, see for example GStreamer vs just using QtMultimedia. This makes portability harder across devices and architectures.
Practically speaking, the biggest thing stopping one from developing an app that’s Qt with say different targets for desktop and various mobile devices (see abovementioned examples) is their usage of different Qt major versions (Kirigami using Qt6). Getting Silica over to Qt6 is almost certainly less work than moving it to GTK, seeing as Silica is literally a QML module. I imagine the harder problems are licensing (there was talks during the community event about the notion – hypothethically speaking – of having a Silica in Qt6 for open source and one in Qt5 for business) and all the patches that have been applied to Qt in Sailfish over the years.
6 Likes
Thank you, I stand corrected!
1 Like
Since some linux phones (purism) went with GTK, the question makes sense, of course as you put it in next post it is questionable on many fronts, but in theory, since some gtk apps are made to be ‘usable on phones’ having access to those on sfos would make sense, maybe running them through XWayland would be a better approach, not requiring silica rewrite, but yeah, it’s linux, there are X, Y and Z apps for linux phones, why not have a choice even if they suck is totally normal and expected question, the fact 10+ years since J1 launched and xwayland is still nowhere to be seen (or usable) is also an interesting question
Edit: also interesting is how ppl claimed Jolla is dead because purism/pinephone, and they’re fully FOSS and through power of friendship jolla is finished, in 2019, here we are 2025 and they are still not usable as daily drivers
1 Like
Silica lags support for the wayland text input protocol used by GTK so currently you wouldn’t be able to type into GTK apps. Also none of the gtk libs are currently packaged so this would require some patience
2 Likes
No; this is still not correct. I thought we had this discussion a couple of times already.
Basically no parts of Qt changed LGPL->GPL. They changed LGPL2->LGPL3 and GPL2->GPL3.
I.e. almost all still have the same link-ability; basically only tivolization clauses have changed. I really cannot stress this enough.
This is much more likely to be about that locking a bootloader on preinstalled phones may run afoul of “being able to swap out the software”.
Yes, the compositor was rug-pulled; but how much actually links to it? Lipstick has always been open.
Jolla have gone out of their way to not include any other components that are GPL3 in the base image (and include plenty that are GPL2 - not least of which the kernel). If this wasn’t the problem, why would they bother?
Until this guesswork is backed by something resembling a motivation, i will continue calling it out wherever it appears.
2 Likes
Don’t expect people –even enthusiasts, devs, linux users at first- to start using it unless it reaches a level where it does the same things a normal linux distro does.
So far it can’t.
One of the biggest problems is the compositor that cripples the whole thing. Most likely a toolkit independant solution -ie. one written in Rust- is needed. This will open the road for more apps and toolkits.
Aren’t community ports like mister magisters oneplus 6 already “open”?
Btw. One of the best working device for sfos. And how about the Fairphones (4/5)?
To me what has to be improved asap on Sfos are these issues: compatibilty with banking apps: to resolve having the possibility of locking the bootloader is essential. The other big issue is relied to bluetooth pairing problems: al lot of smart devices cannot be connected (i.e. Smart Garmin/Suunto smartwatches and lots of else).
On the other side big advantages: no google on it, gestures to manage programs are the best found 'til now, apps are really light, community development, Linux based of course and, and, and …
2 Likes
There is simply no way Android apps running in a container can see the real bootloader locking status. Stop making stuff up.
5 Likes
Just curious, what is the bl status that the apps see in the AppSupport container? The logical answer should be unlocked, right?