The slow updates of SFOS

…and i don’t mean releases. Each time you update, either by the interface in the OS or through the command like (zypper whatever zyppeer whatever version etc), it seems like its taking a lifetime to update.
Coming from a distro like arch which a pacman -Syu gets you up to date in a few minutes even for huge updates this has been bugging me for ages.

So. What gives? Is it the servers that are slow or something in the package management? And can this be fixed/improved?


You have to remember that even in the best condition, say the Gemini PDA with a deca-core processor, there are limitations in ARM performance. Unless your Arch experience was on a Raspberry Pi 4, it isn’t a fair comparison between x86-64 and ARM. You have much more memory and swap space you can donate to a PC, while on mobile, we have the CPU we have, the binary blobs that remain fairly locked between devices, and storage is never close to the full capacity. On the XA2, which I will bet is a majority device at this stage, we’re getting only 19 of the 29~ GB we should get from the device. There’s no space to spare for swap.

My experience running Manjaro on a small Intel Atom-based tablet is tremendously slow and frustrating, as if I do anything more than run Discord, I’ll start getting hardcore freezing and chugging, potentially it will hardlock and it will be faster to restart the device than it would be to wait it out. And updates? If I attempt to use the AUR at all, it’s almost guaranteed to freeze because there’s not enough memory and definitely not enough swap or speed to swap memory quickly enough.

Sailfish is working within the confines of the device, and as far as I’ve experienced between Sotre and OpenRepos, everything is fast enough that I don’t have any complaints personally.


I get that but even downloading the packages doesn’t seem to utilize my connection speed. :thinking:

Just checked, but over wifi it downloads a package just as fast on the phone as on my desktop, with full download speed. That suggests it is not capped or throttled in any way.

I can imagine that if there is a new update it will be very busy and there might be a bottleneck in speed.

$ curl --output “”
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7721k 100 7721k 0 0 11.6M 0 --:–:-- --:–:-- --:–:-- 11.6M

$curl --output “”
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7721k 100 7721k 0 0 11.0M 0 --:–:-- --:–:-- --:–:-- 11.0M

No idea whats going on. For update sizes in the 300MB range it was taking like half an hour or more to update. The download time should have been around 5min at worst and the rest of the update process a few minutes long.

It just feels super slow.

The strangest thing is that if you factory reset one of the older devices (with a minimum version before 3.0), the updates before Sailfish 2.3.0 or so download super fast the way you’d expect, but every update after that just crawls along at a snail’s pace and makes me feel like I’m back in 2008 when Belgian internet was capped at 0,5 MB/s.

I’m seeing the same issue. For some reason the sailfishos updates download very slowly, even with a gigabit connection… definitely something on the server/cdn side, maybe some bandwidth throttling per connection or something?

The actual installation of the update is fast for me, but yes, the download is very slow for me every time and it is not because of my network bandwidth at home.

Could it be, that Jolla introduced a throttle for that because they have a bandwidth limitation on there side after SFOS 2.x?

Also, keep in mind that Arch is a rolling distro (just as another favourite of mine: openSUSE Tumbleweed. I run both on different laptops), so the situation is hard to compare.

Rolling distros release tons of very small update very regularily. At worse, if you’ve forgotten your weekly update, the week after that you might be looking at ~100 packages to upgrade (real-life example based on the logs of the Manjaro ARM derivated of Arch running on my PineBook Pro).

Sailfish OS uses full-blown complete releases, and is in a phase where there are trying to catch-up the versions of most software, including core stuff like the gcc compiler and libc. Which means that the whole 1.5 GB of your root patition get completely replaced on each major upgrade.

That’s a quite significant amount of packages and data that need to be upgraded.

Also, regarding network, keep in mind that you’re not alone, all the other SFOS users are hitting the CDN similarly hard, everyone of them trying to pull this 1.5 GB worth of updates at the same time, because you all got the same giant update (Whereas, in my example above, probably the other Aarch64 users got some of their updates last week already and by now probably only had a couple of dozens of new package to upgrade).

Note that this also happens every now and then on rolling distro: a few core elements changed last week in Tumbleweed, meaning that I had >6000 RPMs to download and update on my work Dell laptop. Whith every body need to update significant portions of their system the same week, the download servers were similarly crawling and the connection was dropping regularily.

So yeah, some efforts could be done on the CDN side to try to aleviate the situation, but part of this is also due to Sailfish OS not being a rolling distro.

Though once Jolla’s devs they finish their catchup and are running more recent versions of everything, one could expect less dramatic change between version (only a subset of all the packages needing to be replaced each two-month), that still won’t be the “couple of dozens package per week” that we’re used with our rolling distros, but certainly Jolla’s roughly bi-monthly upgrade cycle is going to be less massive compared to Ubuntu’s semi-annual releases.

1 Like

I wasn’t comparing rolling vs standard. Even at 700MB update size it takes a lot of time for it to download and update. I don’t expect it to be as fast as normal desktop but it still seems to take too much time.