Little offtopic but i’ve been using Debian on my computer since 2005 (Debian gnu linux 3.1 sarge). Now version is Bookwrorm 12.9. Never paid anything. Plus thousands of programs free.
On Sailfish community makes free work very much to keep system working.
I know Jolla is small company and not very much money but but…
Well, for Debian their community does a lot of work for free as well. And obviously this community is much bigger
Mee too, and everything’s working like a charm also on different hardware.
Yes, but never paid anything for Debian. For Sailfish I have paid, still I get not well working software to my device.
I’m a happy linux user and my change from Windows happened about 20 years ago. A comperation between PC and ARM mobile devices are not really good, because the hw addaptaion could be very different. The best way is to use Android layers to redisign a linux os on a mobile phone.
SFOS seems to be a nice system and has a big potential and I think now I don’t see any development.
I tried to use SFOS as a daily driver with two smartphones (community fork) and generell it was nice. The first device had problems with battery and to many RAM and the second was losing sim cards under SFOS - so you can not be sure to have any connection.
I wanted to find a right daily driver. Other mobile systems don’t support dual sim or don’t have an usable interface (lipstick is interessting).
Now I bought Sony Xperia 10 V Dual SIM 9 months ago and hope to get a support - Nothing is happend. And I think soon™ I can not wait. The sony will be blamed and no right alternative - Yes, Reedem could be a nice smartphone but the performance and size are not an alternative to Sony devices.
In my opinion SFOS should accept official community forks - like Lineage or OpenWRT. Everybody could be download an image directly from the one website. The other services could be offered for tested devices (it means - tested by Jolla)
SaaS is not a problem - I pay for something and I want to get a service for my money. Android support and Exchange is not much enough - or Will we have a promise to get a stable and very good intergrated latest Android layer for Sailfish? In this case - why not?
But it’s only a wish or next step. Now we are waiting long time for start to support for deprecated devices (10 IV / 10V)
Jolla came out and said that you won’t have to subscribe to receive updates, and that a one-off fee will be available:
incidentally, they brought up the subscription plan as a response to requests from the community to be able to provide Jolla with more financial contributions
It was an unpleasant surprise that C2 doesn’t have NFC 
Or 5G, or AMOLED Display, or…
Interesting and this is worth to investigate more. I’ve no insight of what collaboration there is between Jolla and Sony, but if it is what you are writing then they certainly are at the under the dependence what they get from Sony. Has Sony become less cooperative towards Jolla?
Is this we see devices like the Jolla C2. It’s quite an odd phone for the time. The HW is underwhelming for 2025 and doesn’t make much sense unless Jolla was forced to get a device out quickly.
Then the question is what is the future for Jolla. I think it is difficult for Jolla to make their own HW which brings the question what alternatives there are if they are going to move away from Sony.
Also, I would pay a yearly subscription for Sailfish updates as long as the price is not unreasonable.
I’m interested in knowing for what this Sony AOSP program is mainly intended. Surely it exists not alone for Jolla. I always thought it is a kind of education sponsoring for future coders or a base system or evaluation kit for special company systems. Am I wrong? What other people and institutions use these AOSP blobs? How do these clients deal with the late outcome of working blobs when devices are outdated or no more available?
For me still remains question why not Volla, since ports work very fine. What’s the background of the ‘licence problems’?
I really wished Jolla would choose Fairphone as their new platform instead of Reeder. It makes more sense from both HW and SW perspective and there are already multiple OS options available out of the box, plus there is already community port done so better support from existing SFOS users. On the other hand Fairphones are quite expensive but at this point all of SFOS users are pretty much here to support “the dream” and would pay any kind of money (me included!) to see SFOS succeed
Yes, but if they are really manufactored in a fair way then it’s worth the money. Also spare parts are available and it’s self-repairable. So why not both Volla and Fairphone? It’s no work for Jolla (so no lack of resources), everything is existing and ports do work fine, only signing the contract necessary. So it would be the constructive way. Also I think, making quiet business is better than making no business.
Yeah, the FP is my favorite as well. Basically the TCO is lower because the repairs offset the purchase of a new phone every 2 years (±6 months). I don’t really care about the whole sustainability angle, that’s only a nice to have for me.
Probably so Sony can say on paper this adds value to the product, when customer knows the device will enter the Xperia Open Device program, when newer model comes out. My guess is, that Sony just wishes more AOSP developers would buy their phones to increase sales, and to show the open source community how good company they are, when they contribute to the AOSP project.
Jolla is just riding on this, for people to get reasonably priced and available phones, and to provide a easy way to install SFOS. I don’t think there is any “real” collaboration between Jolla and Sony, other than Jolla probably having a direct email to the people on the Sony’s end of the program.
What contract is needed between Volla and Jolla for Jolla to be able to use the phones from Volla?
Another question is if Volla wants Jolla Sailfish because it becomes a direct competitor to their VollaOS (which seems to be some kind de-googled Android). Now Volla also offers Ubuntu Touch so it is a bit contradictional.
A licence for installing the original Jolla Appsupport instead of Waydroid, what’s now necessary on Volla Phone running SFOS to execute Android apps. Jolla appsupport is better.
I also wonder. Volla seems to not force their clients to use VollaOS and offers UT alternatively. So why not SFOS? IMHO I don’t think that Volla is the blocker. I darkly remember that I read years ago, that Jolla wanted more money from Volla for licencing than Volla wanted to pay… So Jolla prefers to have no income than have less because they want more and so get nothing. But I don’t know.
Even if we leave the Hardware situation aside (which is a major issue with SFOS) the SW side of things is really problematic due to Jollas lack of (or resistance to) updates in certain areas of the OS that are needed for a functional phone.
Certain areas are out of their control (ie kernel) but others should have been fixed a long time ago. From my POV the compositor fucked up SFOS more than any other component in it and the lack of updates continues to limit it.
Of course jollas direction is to make money and i trully believe that their venture in automotive could have also improved the phone SW (cars in-car entertainment systems now are like big tablets) but that hasn’t happened yet.
Also the limitation on the store and how much the community can get involved in fixing certain areas also make SFOS less good than it can be. (localization is still problematic)
I don’t have any thoughts on the AI stuff jolla is doing lately but i cant see how they can bring more value to a phone OS that is limited already.
hope things get better soon.
What is this? What evil does the compositor?
There is also Storeman and Chum as other option, so what limitation is the Jolla store?
On the compositor:
Doesn’t support the latest wayland protocols and hence we cant use other toolkits apps etc. Also bounded to Qt. Something new and not relying to any toolkit (ie written in rust) would be more than welcome.
As for the store it somehow alienated the devs in my POV. Yes there is chum and storeman but i believe in an one stop shop solution. (unless for experimental stuff that could be handles in a community repo like chum)
Any possibility for Community to take this into own hands, kind of Community version of SFOS with up zo date kernel, QT and all this system parts?