SfOS works great for me (10ii) and there is absolutely no reason to change OS at present.
You should maybe get yourself a newer phone to solve your issues.
2 Likes
Be sure to join low memory workarounds working group thread at Low memory, apps crashing - change zram settings or add swapfile? [4.x] - #53 by lkraav
But long story short is still, SFOS technology is best suited for phones w/ 8G RAM and up.
Not actually screwed. We would have to flash another OS on our phones at some point in time.
Will this one finally be the one of these more or less identical threads about a bunch of otherwise noted bugs, personal annoyances, old hardware and for sure complete celestial insight in the future of mobile operating systems that will once and for all solve it all?
Chances are as high as ever.
6 Likes
Feels very weird to need 8gb ram for this type of OS, but i would gladly get a high end device if jolla supports it and focuses on that device for a few years.
on the jolla it was marketed as lightweight os that only needs 1GB of ram^^
5 Likes
And that would be my expectations too. Maybe now with the focus on android support things are different?
My usage is not that heavy so I cannot verify or deny 
1 Like
i think what slows sfos down is encryption and sailjail (or firejail)
1 Like
Right, and there are so many possibilities for xperia 10 III… Shame official sailfish os is not for fairphone 3 or 4, then there would actually be other options.
2 Likes
Yes. Two, if you own both.
1 Like
I’m thinking the same.
Is there an option to throw these two things away from the phone? Or is this so deeply integrated into the system that it can’t be removed? I really would like to get rid of this.
1 Like
If you have a phone that was aleady around before the encryption was introduced (something like 3.4?) you could flash the older version (if you get it from someone) and upgrade. The encryption was not automaticallx activated, my XA2 Ultra is still unencrypted.
If I think about it that could explain why I don’t have any performance issues.
You can disable encryption after flashing. Instead of booting Sailfish you need to boot into recovery, mount the root file system and delete/rename the file:
/var/lib/sailfish-device-encryption/encrypt-home
and thats it.
8 Likes
It seems like a good idea to check out, especially if you have few XA2 laying around in various conditions
Only question is, where to find images of older SFOS?
If you ask for it on the forum usually someone shows up who has kept old images
1 Like
Filesystem encryption overhead is negligible.
Sailjail I’m not familiar with, nor do I use SELinux or alternatives on desktop. These could have a more significant impact.
But the main killers, way above anything else
- 2 system runtimes: SFOS, Android
- Browser: I can see closing it free 1+G memory just by itself
- memory leaks: it’s highly likely with these complicated systems
I haven’t been able to reach a conclusion on how native Android can appear and render so fast and smooth even on a low end device like Xperia X, vs SFOS containerized Android on let’s say X10II and up 
1 Like
I disable android support when i don’t need it and i still feel performance issues (although this could be subjective) on the other hand I’m surprised then how smooth the os runs with android support running in the background, compared to it being disabled
Very interesting point regarding sailjail. Do you have any evaluations regarding its memory usage?
Having Jolla coordinating, establishing infrastructure is a great asset, indeed! There are things that could be improved though and I think open-sourcing would be one of them. It is also not really helpful to have closed bug tracker.
Open sourcing would help with Qt updates, for example.
7 Likes
I have an X10 II with me, running Sailfish OS 4.5.0 - it has 10 firejail and 5 xdg-dbus-proxy processes running with no apps open at all. Every app you start adds 2 more firejails (apparently one isn’t secure enough) and 1 xdg-dbus-proxy.
In the early days when it was still possible to easily turn sailjail off, I was measuring the overall overhead with a few small native apps open (e.g. clock, notes and such) and it was quite noticeable, like 20% or so. If you start something big, e.g. the browser, the relative memory overhead obviously gets smaller. Memory isn’t the only thing that matters - CPU is a valuable and limited resource too, although firejails don’t seem to be among the top consumers of CPU time. And xdg-dbus-proxy overhead depends on how extensively the app is using D-Bus.
It’s not easy to measure sailjail overhead these days because this thing has been so deeply integrated into the system. And it doesn’t really matter anymore - nobody is going to rip it off at this point, it is what it is, there’s no way around it.
We have to be grateful that it’s still possible to prevent jailing of the apps which don’t have a chance to ever get into Jolla Store, with Sandboxing=Disabled in the desktop file. It could be worse 
8 Likes
The question is: for how long… Because in some aspects it’d make SFOS a dumb OS where certain functionalities are completely beyond developers’ reach.
For example, the otherwise really magnificent BlackBerry 10 OS had so many things protected with permissions inaccessible to 3rd party developers (available to to the OS vendor only) that it was literally preventing development of advanced applications. Even as basic functions as turning WiFi off were behind permissions not available to developers. It was one of the things which directly contributed to BB10’s demise as it directly affected the number of native software available for it.
I hope that SFOS will not drift in that direction because I’m afraid that it’d be the nail in the coffin.
3 Likes